This section introduces the software requirements process, orienting the remaining five topics and showing how the requirements process dovetails with the overall software engineering process.
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 that continues 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. The topic also includes activities that provide input into the requirements process, such as marketing and feasibility studies.
Process Actors
This topic introduces the roles of the people who participate 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 will always include users/operators and customers (who need not be the same).
Typical examples of software stakeholders include (but are not restricted to) the following:
• Users: This group comprises those who will operate the software. It is often a heterogeneous group involving 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 or from 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. Specific requirements, particularly constraints, may have major impact on project cost or delivery because they either fit well or poorly with the skill set of the engineers. Important tradeoffs among such requirements should be identified.
It will not be possible to perfectly satisfy the requirements of every stakeholder, and it is the software engineer’s job to negotiate tradeoffs 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 section introduces the project management resources required and consumed by the requirements process. It establishes the context for the first topic (Initiation and Scope Definition) of the Software Engineering Management KA. Its principal purpose is to make the link between the process activities identified in 2.1 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 is closely related to both the Software Quality KA and Software Engineering Process KA, comprising
• requirements process coverage by process improvement standards and models;
• requirements process measures and benchmarking;
• improvement planning and implementation;
• security/CIA improvement/planning and implementation.
Back - 1 - Software Requirements Fundamentals
Next - 3 - Requirements Elicitation
Home - Software Requirement
Main - The BOK
Published on : 30-May-2018
Ref no : DTC-WPUB-000003
About Author
Comments
Post a Comment