Software Requirements Engineering for Senior System Architect in Software Examination

Overview

A complete software life cycle starts with requirements. Software requirements refer to users’ expectations for the system in terms of functions, behavior, performance, design constraints, etc.

Requirements development:

• Requirements acquisition
• demand analysis
• Requirements definition (requirements specification)
• Requirements verification

Demand management:

• change control
• version control
• Requirements tracking
• Requirement status tracking

Demand development and demand management are complementary to each other. Demand development is the main line and goal, and demand management is support and guarantee.

Classification

Requirements classification: There are different classification methods from different perspectives, and each classification method provides a perspective for understanding requirements.

Software requirements include three different levels (classifications): business requirements, user requirements, and functional and non-functional requirements.

• Business requirements: Indicates high-level goals of the organization or customers, usually coming from project investors, customers who purchase products, managers of actual users, marketing departments, or product planning departments. Business requirements describe why an organization should develop a system, that is, what the organization hopes to achieve. Document business requirements using a vision and scope document, sometimes called a project outline or market requirements document

• User requirements: describe the user's goals, or the tasks that the user requires the system to complete

• Functional requirements: stipulates the software functions that developers must implement in the product, and users use these functions to complete tasks and meet business needs.

• Business needs (overall)

• User needs (user perspective)

• System Requirements (Computerized)

Another way to classify:

• Basic needs (stated, regular needs)
• Expected demand (implied)
• Excitement needs (unexpected needs)

Another saying: Software requirements include three main parts: functional requirements, non-functional requirements, and design constraints.

demand characteristics

Basic characteristics of software requirements: verifiability.

Ideally, every user, business need, and functional requirement should have the following properties:

• Completeness: Each requirement must completely describe the functionality to be delivered
• Correctness: Each requirement must correctly describe the functionality to be developed
• Feasibility: The requirement must be achievable within the known capabilities and constraints of the system and its operating environment
• Necessity: Each function recorded in the requirements must be a real need of the user
• No ambiguity: Each requirement statement should have only one consistent interpretation for all readers
• Verifiability: If a requirement is not verifiable, then determining whether its implementation is correct or not becomes subjective.

Requirements development

The requirements development process has four main activities:

• Requirements acquisition: Actively communicate with users, capture, analyze and modify users' needs for the target system, and extract user needs that are suitable for solving problems, and produce a "User Requirements Specification"
• Requirements analysis: The purpose is to analyze and abstractly describe various requirements information and establish a conceptual model for the target system.
• Requirements definition: The goal is to further define accurate product requirements based on the results of demand surveys and demand analysis, and produce a "Requirements Specification". System designers will carry out system design work based on the "Requirements Specification"
• Requirements verification: This refers to the developer and the user jointly reviewing the requirements document, and making a written commitment after both parties reach a consensus on the requirements, so that the requirements document has the effect of a commercial contract.

Requirements acquisition

There are many ways to obtain requirements:

User interviews: User interviews are the most basic means of obtaining requirements, and their forms include structured and unstructured. User interviews are face-to-face communication with users in the form of 1-to-1 (or 1-to-2, 1-to-3) to obtain user needs. User interviews have good flexibility and a wide range of applications. However, there are also many difficulties. For example, users are often busy and have difficulty arranging time; the amount of information during interviews is large and recording is difficult; communication requires many skills and system analysts must have sufficient domain knowledge, etc. In addition, during the interview, you may also encounter some confidential and sensitive topics for the company. Therefore, this seemingly simple technology also requires system analysts to have rich experience and strong communication skills.

Sampling: refers to the process of systematically selecting a representative sample set from a population. Through careful study of the selected sample set, useful information about the population can be revealed as a whole. For the development of information systems, the documentation (files) of the existing system is the sampling population. When starting to do a requirements analysis on a system, reviewing the documentation of the existing system is the best way to get a preliminary understanding of the system. However, what types of documents should system analysts look at? When the data in the documents is huge, it is necessary to use sampling techniques to select representative data. Sampling technology can not only be used to collect data, but can also be used to collect interviews with users or collect and observe users. The same sampling techniques described above apply when sampling people. Through sampling technology, selecting part rather than the entire population not only speeds up the data collection process, but also improves efficiency and reduces development costs. Sampling techniques use the principles of mathematical statistics to reduce bias in data collection. However, since the sampling technology is based on statistical principles, the determination of the sample size depends on the expected credibility and existing prior knowledge, and largely depends on the system analyst's subjective factors, personal experience and experience of the system analyst. The ability is highly dependent and requires system analysts to have a high level and rich experience.

Joint demand planning: In order to improve the efficiency of demand acquisition, more and more companies tend to use group working meetings to replace a large number of independent interviews. Joint Requirement Planning (JRP) is a process of analyzing problems within an enterprise and obtaining requirements through highly organized group meetings. It is part of Joint Application Development (JAD).

demand analysis

Requirements analysis is a software engineering activity that serves as a bridge between system-level software allocation and software design. Requirements analysis enables system engineers to characterize the functions and performance of the software, specify the interfaces between the software and other system elements, and establish Constraints that the software must satisfy.

Requirements analysis allows systems analysts to refine the decomposition of software and build models of the data, functionality, and behavior that will be processed by the software. Finally, the requirements specification provides developers and customers with a basis for quality evaluation after software development is completed. Requirements analysis provides software designers with models that can be translated into data, architecture, interface, and process designs.

The task of requirements analysis is the process of discovery, refinement, modeling and specification, including the detailed refinement of the software scope established by the system engineer and specified in the software project plan, and the creation of required data, information, control flow and operational behavior. The model, in addition, analyzes alternative solutions and assigns them to software elements.

It is impossible to obtain detailed specifications during the requirements analysis stage. Customers may not be sure exactly what is needed, and developers may not be sure what specific methods can be used to appropriately accomplish functionality and performance.

The process of requirements extraction and analysis

1. Discover needs
2. Requirements classification and organization
3. Requirements prioritization and negotiation
4. Requirements Specification

DFD

Data flow diagram is an important tool in the SA method. It is a method to express the flow of data within the system and describe system functions through data flow.
DFD can also be considered as a system model. In information system development, if a structured approach is adopted, DFD is generally used as an integral part of the requirements specification. A use case model describes a set of use cases, actors, and the relationships between them.

A data dictionary is often used as a supplement to this tool:

• DFD is a tool for understanding and expressing user needs and a means of demand analysis. Because DFD is concise and easy to understand and does not require any computer expertise to understand it, system analysts can communicate with users through DFD
• DFD briefly describes the internal logical process of the system. It is an expression tool for requirements analysis results, an important reference for system design, and the starting point of system design.
• DFD, as an archived text material, is the basis for further revising and enriching the development plan.

Data flow-oriented analysis methods: structured analysis methods.

YES

Object-oriented analysis, main activities

• Establish requirements model, i.e. use case diagram
  • Determine system boundaries
  • Discover participants
  • Define use cases
• Build a basic model, i.e. class diagram
  • Discover objects and the classes that define them
  • Define the internal characteristics of the object - properties and operations
  • Define the external relationships of objects - general-specific structure, whole-part structure, associations and messages
• Build auxiliary models
  • Divide packages and create package diagrams
  • Create sequence diagram
  • Create activity diagram
  • Create component diagram
  • Create deployment diagram
  • Create other model diagrams
• Establish a model specification: provide standardized definitions and textual descriptions of the components in the model
• Prototype development: optional, repeated in conjunction with other activities

The above OOA processes are generally an iterative and continuous improvement process, centered on the establishment of basic models, and the establishment, repair and improvement of demand models, basic models, and auxiliary models.

Requirements definition

The process of requirements definition is the process of forming requirements specifications. There are usually two methods of requirement definition: strict definition method and prototype method.

The rigorous definition approach, also known as pre-definition, rigorous definition of requirements is based on the following basic assumptions:

• All requirements can be predefined. This means that all system requirements can be derived through logical inference without actual system operating experience. But this assumption cannot be established in many cases.
• Ability to communicate accurately and clearly between developers and users.
• Use graphics (or text) to fully represent the final system. In the development process that uses strictly defined requirements, the main tool for communication between developers and users is definition reports, including technical tools such as text, graphics, logical rules, and data dictionaries.

The prototyping requirements definition process is an iterative process in which developers and users work together. Starting from a prototype system that can meet the basic needs of users, it allows better requirements to be put forward during the development process, and the system is continuously improved according to user requirements. It is essentially an iterative and cyclic development method.
There are several issues to note when using the prototype method:

• Not all requirements can be accurately stated before system development
• There are often communication difficulties among project stakeholders
• Requires actual, user-participable system models
• Have a suitable system development environment
• Repetition is completely necessary and worth advocating. Once requirements are identified, a strictly defined approach should be followed

Requirements verification

The four basic methods of requirements verification are inspection, demonstration, testing and analysis. These four methods are inherently layered in that each method verifies the requirements of a product or system with increasing rigor:

• Checking: When checking requirements, the requirements document is proofread to ensure that no elicitation instructions are missed and the level of traceability between all requirements is also checked. To do this, a traceability matrix needs to be created that ensures that all requirements are properly considered and that everything specified is justified. The format of the requirements will also be checked to see if the requirements are clear.
• Prototyping: This is a method of building a model or simulation of a system that a developer will build. This is a very popular requirements validation technique among stakeholders and users as it helps them easily identify problems, detect missing requirements and understand how the technology can help them. You can contact users and stakeholders and get their feedback.
• Test Design: During test design, a small procedure is followed for the test team to build some test scenarios. Tests must be derived from the requirements specification. The purpose of this process is to find errors or missing details in the specification that make it difficult to define test scenarios.
• Requirements Review: During a requirements review, a group of knowledgeable people analyze the requirements and identify potential issues in a structured and detailed manner. Then get together to discuss the problem and find ways to solve it. Prepare a checklist for reviewers to complete to provide the formal output of the review. Finalize with final approval signature.

Requirements verification principles
According to the IREB syllabus, considering the following four requirements verification principles can improve the quality of verification results:

• Engage the right stakeholders
• Separate identification and correction of errors
• Validate from different angles
• Repeated verification

Demand management

Requirements management is a process of changing, understanding, and controlling system requirements, which usually includes defining requirements baselines, handling required changes, and requirements tracking. The requirements management process and the requirements development process are interrelated. The requirements management plan is started when the initial requirements are derived. Once the first draft of the requirements document is formed, the requirements management activities begin.

Requirements management emphasizes: controlling changes to the demand baseline; maintaining consistency between project plans and requirements; controlling the versions of individual requirements and requirements documents; managing requirements and contact chains, or managing dependencies between individual requirements and other project deliverables ;Track the status of requirements in the baseline.

Regarding the principles and policies in the requirements management process area, you can refer to:

• The key process area of ​​requirements management does not involve collecting and analyzing project requirements. Instead, it is assumed that software requirements have been collected or have been given by a higher-level system.
• Before developers commit to certain requirements to customers and relevant departments, they should confirm the requirements and constraints, risks, contingencies, assumptions, etc.
• Key processing areas also recommend managing requirements documents through version control and change control.

Requirements management activities include:

• change control
• version control
• Requirements tracking
• Requirement status tracking

requirements change control

The requirements of a large software system are always changing. For many projects, system software always needs to be constantly improved. Improvements in some requirements are reasonable and inevitable. It may be impossible to keep the software requirements from changing at all, but uncontrolled changes will plunge the project into chaos and make it impossible. One of the main reasons why software quality cannot be guaranteed is to complete it on schedule. A good change control process provides project stakeholders with a formal mechanism for proposed changes to requirements. The status of proposed changes can be tracked through the change control process to ensure that proposed changes will not be lost or ignored. Requirements change management process:

• Problem analysis and change description. This is the identification and analysis of a requirements issue or a clear change proposal to check its validity, resulting in a clearer requirements change proposal
• Change analysis and costing. Perform impact analysis and evaluation of requirements change proposals using traceability information and general knowledge of system requirements. Change cost calculations should include the costs of modifications to the requirements document, design and implementation of system modifications. Once the analysis is complete and confirmed, a decision should be made whether to implement the change
• Change implementation. This requires that both the requirements document and the system design and implementation be modified simultaneously. If you first make changes to the system program and then modify the requirements document, it is almost inevitable that there will be inconsistencies between the requirements document and the program. Automation tools can help the change control process operate more efficiently. Many teams use business issue tracking tools to collect, store, and manage requirements changes. A list of recently submitted change proposals created with such a tool can be used as an agenda for CCB meetings. The issue tracking tool can also report the number of change requests classified by change status at any time. Because available tools, vendors, and features change frequently, specific recommendations about tools cannot be given here.

But the tool should have the following features to support the requirements change process:

• Data items in change requests can be defined;
• A state transition model that can define the change request life cycle;
• The state transition model can be enforced so that only authorized users can make permitted state changes;
• The date of each status change and the person who made the change can be recorded;
• You can define who can automatically receive email notifications when a proposer submits a new request or when a request status is updated;
• Standard and customized reports and charts can be generated.

Some business requirements management tools have simple change proposal systems built into them. These systems can tie proposed changes to a specific requirement so that whenever someone submits a related change request, everyone responsible for the requirement receives an email notification.

The requirements of a large software system often change. When making demand changes, you can refer to the following demand change strategies:

• All requirements changes must follow the change control process;
• Design and implementation work should not be done for unapproved changes;
• Changes should be made by the project change control board to decide which changes to implement;
• Project stakeholders should be able to understand the contents of the change database;
• The original document of the change request must never be deleted from the database or modified;
• Every integrated requirement change must be traceable to an approved change request

version control

Requirements tracking

Requirements tracking includes documenting the relationship between each requirement and system elements, including other requirements, architecture, other design components, source code modules, tests, help files, and documentation. Tracking capability information facilitates change impact analysis to identify and evaluate the work necessary to implement a proposed requirement change. The requirements traceability link can be used to track the entire process of using a requirement, that is, the life cycle from initial requirement to implementation. Traceability is a feature of a good requirements specification. In order to achieve traceability, each requirement must be uniformly identified so that it can be clearly reviewed.

Customer requirements are traced back to software requirements. In this way, software requirements that are affected by changes in customer requirements during or after development can be distinguished, and this can ensure that the software requirements specification includes all customer requirements.

Respond to customer requirements back from software requirements. This is the source of identifying every software requirement. If customer requirements are described in the form of examples, the tracking between customer requirements and software requirements is the use of examples and functional requirements. Work backwards from software requirements to the next level of work products. As system requirements are transformed into software requirements, design, coding, etc. during the development process, it is possible to trace the requirements forward to the next level of work products by defining the (connection) chain between individual requirements and specific product elements. This chain of connections tells us which product parts correspond to each requirement, thereby ensuring that the product parts meet each requirement. Trace back from product parts to software requirements. Explain why each component exists. If design elements, code snippets, or tests cannot be traced back to a requirement, there may be a process that is superfluous. However, if these isolated elements indicate a legitimate functionality, then the requirements specification is missing a requirement.

Requirements Tracking Matrix RTM

Requirement status tracking

reference