CS302: Software Engineering

Process Models 

The objective of this topic is to provide an understanding that the requirements process

• Is not a discrete front-end activity of the software life cycle, but rather a process initiated at the beginning of a project and continuing to be refined throughout the life cycle
• Identifies software requirements as configuration items, and manages them using the same software configuration management practices as other products of the software life cycle processes
• Needs to be adapted to the organization and project context

In particular, the topic is concerned with how the activities of elicitation, analysis, specification, and validation are configured for different types of projects and constraints.

Process Actors

This topic introduces the roles of the people participating in the requirements process. This process is fundamentally interdisciplinary, and the requirements specialist needs to mediate between the domain of the stakeholder and that of software engineering. There are often many people involved besides the requirements specialist, each of whom has a stake in the software. The stakeholders will vary across projects but always include users/operators and customers (who need not be the same).

Typical examples of software stakeholders include (but are not restricted to)

• Users: This group comprises those who will operate the software. It is often a heterogeneous group comprising people with different roles and requirements.
• Customers: This group comprises those who have commissioned the software or who represent the software's target market.
• Market analysts: A mass-market product will not have a commissioning customer, so marketing people are often needed to establish what the market needs and to act as proxy customers.
• Regulators: Many application domains, such as banking and public transport, are regulated. Software in these domains must comply with the requirements of the regulatory authorities.
• Software engineers: These individuals have a legitimate interest in profiting from developing the software by, for example, reusing components in other products. If, in this scenario, a customer of a particular product has specific requirements that compromise the potential for component reuse, the software engineers must carefully weigh their own stake against those of the customer.

It will not be possible to perfectly satisfy the requirements of every stakeholder, and it is the software engineer's job to negotiate trade-offs that are both acceptable to the principal stakeholders and within budgetary, technical, regulatory, and other constraints. A prerequisite for this is that all the stakeholders be identified, the nature of their "stake" analyzed, and their requirements elicited.

Process Support and Management

This topic introduces the project management resources required and consumed by the requirements process. It establishes the context for the first subarea (Initiation and scope definition) of the Software Engineering Management KA. Its principal purpose is to make the link between the process activities identified and the issues of cost, human resources, training, and tools.

Process Quality and Improvement

This topic is concerned with the assessment of the quality and improvement of the requirements process. Its purpose is to emphasize the key role the requirements process plays in terms of the cost and timeliness of a software product and of the customer's satisfaction with it. It will help to orient the requirements process with quality standards and process improvement models for software and systems. Process quality and improvement are closely related to both the Software Quality KA and the Software Engineering Process KA. Of particular interest are issues of software quality attributes and measurement and software process definition. This topic covers

• Requirements process coverage by process improvement standards and models
• Requirements process measures and benchmarking
• Improvement planning and implementation

Source: Hung Vo, https://cnx.org/contents/zx4yYVWR@1.1:Zvb38l8_@6/Requirements-analysis
This work is licensed under a Creative Commons Attribution 4.0 License.