Rationale and Requirements Engineering
Many of the decisions that have the greatest impact on the software development process are made during requirements analysis. Software Engineering Rationale(SER)can support this process by providing the ability to capture the decisions and the reasons be
- PDF / 125,565 Bytes
- 15 Pages / 595.276 x 841.89 pts (A4) Page_size
- 82 Downloads / 249 Views
Many of the decisions that have the greatest impact on the software development process are made during requirements analysis. Software Engineering Rationale (SER) can support this process by providing the ability to capture the decisions and reasons behind them, starting at these earliest phases. SER also supports requirements traceability throughout the process by directly mapping the development options chosen to the requirements that provide their rationale and by providing rationale for the requirements, thereby mapping requirements back to their source. In this chapter, we describe how rationale can support requirements engineering.
11.1 Introduction
11.1.1 Requirements Engineering The key to every successful software project is its ability to meet the needs of its intended customer. This means that the software developers must determine what the requirements are for the software system. The process of identifying requirements, analyzing them to obtain additional requirements, documenting them in a specification, and validating that specification to ensure that it meets user needs is known as requirements engineering (Saiedian and Dale 2000). In provisioned systems (systems developed under contract), the requirement specification serves as the basis for the development contract; in product development, requirements are written based on market analysis and are expected to change if necessary (Kuusela and Savolainen 2000). Inadequate or deficient software requirements are considered the leading cause of project failure (Alford and Lawson 1979; Hofmann and Lehner 2001). Lindquist (2005) states that analysts report the percentage of project failures resulting from poor requirements management to be greater than 70%. The management problem is especially difficult on systems where the requirements are not stable. It is well known that the later in the
140
11 Rationale and Requirements Engineering
development process a requirement changes the higher the cost to make the change will be. Agile development methodologies, such as Extreme Programming (Beck 1999), have been created to “flatten the curve” and be more responsive to changing requirements. Requirements are typically broken into two categories: functional requirements that describe what the system should do (functions performed or features implemented) and nonfunctional requirements (NFRs) that describe qualities that the developed system should have. NFRs are often referred to as “ilities” (Filman 1998) since NFRs include qualities such as usability, scalablity, reusability, testability, maintainability, etc. Nonfunctional requirements are difficult to test and verify because they tend to cross-cut functionality of the system and also because they are often difficult to quantify. While they do not describe the functionality desired by the stakeholders they do have a direct impact on how satisfied the stakeholders are likely to be with the final product. Some NFRs involve the development process. Examples of these would be affordability, maintainability,
Data Loading...