Difference between revisions of "Chapter 1: Software Requirements"
(Undo revision 237 by Daniel Robbins (talk)) |
|||
| Line 9: | Line 9: | ||
{{IntroSection|title=Introduction|body= | {{IntroSection|title=Introduction|body= | ||
| + | {{NoIndent|The Software Requirements knowledge area (KA) is concerned with the elicitation, analysis, specification, and validation of software requirements as well as the management of requirements during the whole life cycle of the software product. It is widely acknowledged amongst researchers and industry practitioners that software projects | ||
| + | are critically vulnerable when the requirements-related activities are poorly performed.}} | ||
| − | + | Software requirements express the needs and | |
| − | + | ||
| − | + | ||
| − | + | ||
constraints placed on a software product that | constraints placed on a software product that | ||
contribute to the solution of some real-world | contribute to the solution of some real-world | ||
problem. | problem. | ||
| − | + | The term “requirements engineering” is widely | |
used in the field to denote the systematic handling | used in the field to denote the systematic handling | ||
of requirements. For reasons of consistency, the | of requirements. For reasons of consistency, the | ||
| Line 32: | Line 31: | ||
could not perform the function. | could not perform the function. | ||
| − | + | A risk inherent in the proposed breakdown is | |
that a waterfall-like process may be inferred. To | that a waterfall-like process may be inferred. To | ||
guard against this, topic 2, Requirements Process, | guard against this, topic 2, Requirements Process, | ||
| Line 40: | Line 39: | ||
and which act to configure it. | and which act to configure it. | ||
| − | + | An alternate decomposition could use a product-based structure (system requirements, software requirements, prototypes, use cases, and | |
so on). The process-based breakdown reflects | so on). The process-based breakdown reflects | ||
the fact that the requirements process, if it is to | the fact that the requirements process, if it is to | ||
| Line 49: | Line 48: | ||
of a software development project. | of a software development project. | ||
| − | + | The Software Requirements KA is related | |
closely to the Software Design, Software Testing, | closely to the Software Design, Software Testing, | ||
Software Maintenance, Software Configuration | Software Maintenance, Software Configuration | ||
| Line 64: | Line 63: | ||
=== Definition of a Software Requirement === | === Definition of a Software Requirement === | ||
| − | At its most basic, a software requirement is a property that must be exhibited by something in order to solve some problem in the real world. It may aim to automate part of a task for someone to support the business processes of an organization, to correct shortcomings of existing software, or to control a device—to name just a few of the many problems for which software solutions are possible. The ways in which users, business processes, and devices function are typically complex. By extension, therefore, the requirements on particular software are typically a complex combination from various people at different levels of an organization, and who are in one way or another involved or connected with this feature from the environment in which the software will operate. | + | {{NoIndent|At its most basic, a software requirement is a property that must be exhibited by something in order to solve some problem in the real world. It may aim to automate part of a task for someone to support the business processes of an organization, to correct shortcomings of existing software, or to control a device—to name just a few of the many problems for which software solutions are possible. The ways in which users, business processes, and devices function are typically complex. By extension, therefore, the requirements on particular software are typically a complex combination from various people at different levels of an organization, and who are in one way or another involved or connected with this feature from the environment in which the software will operate.}} |
| − | + | An essential property of all software requirements is that they be verifiable as an individual | |
feature as a functional requirement or at the | feature as a functional requirement or at the | ||
system level as a nonfunctional requirement. It | system level as a nonfunctional requirement. It | ||
| Line 78: | Line 77: | ||
=== Product and Process Requirements === | === Product and Process Requirements === | ||
| − | A product requirement is a need or constraint on the software to be developed (for example, “The software shall verify that a student meets all prerequisites before he or she registers for a course”). | + | {{NoIndent|A product requirement is a need or constraint on the software to be developed (for example, “The software shall verify that a student meets all prerequisites before he or she registers for a course”).}} |
| − | + | A process requirement is essentially a constraint on the development of the software (for | |
example, “The software shall be developed using | example, “The software shall be developed using | ||
a RUP process”). | a RUP process”). | ||
| − | + | Some software requirements generate implicit | |
process requirements. The choice of verification | process requirements. The choice of verification | ||
technique is one example. Another might be the | technique is one example. Another might be the | ||
| Line 95: | Line 94: | ||
=== Functional and Nonfunctional Requirements === | === Functional and Nonfunctional Requirements === | ||
| − | ''Functional'' requirements describe the functions that the software is to execute; for example, formatting some text or modulating a signal. They are sometimes known as capabilities or features. A functional requirement can also be described as one for which a finite set of test steps can be written to validate its behavior. | + | {{NoIndent|''Functional'' requirements describe the functions that the software is to execute; for example, formatting some text or modulating a signal. They are sometimes known as capabilities or features. A functional requirement can also be described as one for which a finite set of test steps can be written to validate its behavior.}} |
| − | + | ''Nonfunctional'' requirements are the ones that | |
act to constrain the solution. Nonfunctional | act to constrain the solution. Nonfunctional | ||
requirements are sometimes known as constraints | requirements are sometimes known as constraints | ||
| Line 108: | Line 107: | ||
=== Emergent Properties === | === Emergent Properties === | ||
| − | Some requirements represent emergent properties of software—that is, requirements that cannot be addressed by a single component but that depend on how all the software components interoperate. The throughput requirement for a call center would, for example, depend on how the telephone system, information system, and the operators all interacted under actual operating conditions. Emergent properties are crucially dependent on the system architecture. | + | {{NoIndent|Some requirements represent emergent properties of software—that is, requirements that cannot be addressed by a single component but that depend on how all the software components interoperate. The throughput requirement for a call center would, for example, depend on how the telephone system, information system, and the operators all interacted under actual operating conditions. Emergent properties are crucially dependent on the system architecture.}} |
=== Quantifiable Requirements === | === Quantifiable Requirements === | ||
| − | Software requirements should be stated as clearly and as unambiguously as possible, and, where appropriate, quantitatively. It is important to avoid vague and unverifiable requirements that depend for their interpretation on subjective judgment (“the software shall be reliable”; “the software shall be user-friendly”). This is particularly important for nonfunctional requirements. Two examples of quantified requirements are the following: a call center’s software must increase the center’s throughput by 20%; and a system shall have a probability of generating a fatal error during any hour of operation of less than 1 * 10 −8 . The throughput requirement is at a very high level and will need to be used to derive a number of detailed requirements. The reliability requirement will tightly constrain the system architecture. | + | {{NoIndent|1=Software requirements should be stated as clearly and as unambiguously as possible, and, where appropriate, quantitatively. It is important to avoid vague and unverifiable requirements that depend for their interpretation on subjective judgment (“the software shall be reliable”; “the software shall be user-friendly”). This is particularly important for nonfunctional requirements. Two examples of quantified requirements are the following: a call center’s software must increase the center’s throughput by 20%; and a system shall have a probability of generating a fatal error during any hour of operation of less than 1 * 10 −8 . The throughput requirement is at a very high level and will need to be used to derive a number of detailed requirements. The reliability requirement will tightly constrain the system architecture.}} |
=== System Requirements and Software Requirements === | === System Requirements and Software Requirements === | ||
Revision as of 20:21, 19 August 2015
Contents
- CIA
- Confidentiality, Integrity, and Availability
- DAG
- Directed Acyclic Graph
- FSM
- Functional Size Measurement
- INCOSE
- International Council on Systems Engineering
- UML
- Unified Modeling Language
- SysML
- Systems Modeling Language
The Software Requirements knowledge area (KA) is concerned with the elicitation, analysis, specification, and validation of software requirements as well as the management of requirements during the whole life cycle of the software product. It is widely acknowledged amongst researchers and industry practitioners that software projects are critically vulnerable when the requirements-related activities are poorly performed.
Software requirements express the needs and constraints placed on a software product that contribute to the solution of some real-world problem.
The term “requirements engineering” is widely used in the field to denote the systematic handling of requirements. For reasons of consistency, the term “engineering” will not be used in this KA other than for software engineering per se. For the same reason, “requirements engineer,” a term which appears in some of the literature, will not be used either. Instead, the term “software engineer” or, in some specific cases, “requirements specialist” will be used, the latter where the role in question is usually performed by an individual other than a software engineer. This does not imply, however, that a software engineer could not perform the function.
A risk inherent in the proposed breakdown is that a waterfall-like process may be inferred. To guard against this, topic 2, Requirements Process, is designed to provide a high-level overview of the requirements process by setting out the resources and constraints under which the process operates and which act to configure it.
An alternate decomposition could use a product-based structure (system requirements, software requirements, prototypes, use cases, and so on). The process-based breakdown reflects the fact that the requirements process, if it is to be successful, must be considered as a process involving complex, tightly coupled activities (both sequential and concurrent), rather than as a discrete, one-off activity performed at the outset of a software development project.
The Software Requirements KA is related closely to the Software Design, Software Testing, Software Maintenance, Software Configuration Management, Software Engineering Management, Software Engineering Process, Software Engineering Models and Methods, and Software Quality KAs.
The breakdown of topics for the Software Requirements KA is shown in Figure 1.1.
1 Software Requirements Fundamentals
1.1 Definition of a Software Requirement
At its most basic, a software requirement is a property that must be exhibited by something in order to solve some problem in the real world. It may aim to automate part of a task for someone to support the business processes of an organization, to correct shortcomings of existing software, or to control a device—to name just a few of the many problems for which software solutions are possible. The ways in which users, business processes, and devices function are typically complex. By extension, therefore, the requirements on particular software are typically a complex combination from various people at different levels of an organization, and who are in one way or another involved or connected with this feature from the environment in which the software will operate.
An essential property of all software requirements is that they be verifiable as an individual feature as a functional requirement or at the system level as a nonfunctional requirement. It may be difficult or costly to verify certain software requirements. For example, verification of the throughput requirement on a call center may necessitate the development of simulation software. Software requirements, software testing, and quality personnel must ensure that the requirements can be verified within available resource constraints.
1.2 Product and Process Requirements
A product requirement is a need or constraint on the software to be developed (for example, “The software shall verify that a student meets all prerequisites before he or she registers for a course”).
A process requirement is essentially a constraint on the development of the software (for example, “The software shall be developed using a RUP process”).
Some software requirements generate implicit process requirements. The choice of verification technique is one example. Another might be the use of particularly rigorous analysis techniques (such as formal specification methods) to reduce faults that can lead to inadequate reliability. Process requirements may also be imposed directly by the development organization, their customer, or a third party such as a safety regulator.
1.3 Functional and Nonfunctional Requirements
Functional requirements describe the functions that the software is to execute; for example, formatting some text or modulating a signal. They are sometimes known as capabilities or features. A functional requirement can also be described as one for which a finite set of test steps can be written to validate its behavior.
Nonfunctional requirements are the ones that act to constrain the solution. Nonfunctional requirements are sometimes known as constraints or quality requirements. They can be further classified according to whether they are performance requirements, maintainability requirements, safety requirements, reliability requirements, security requirements, interoperability requirements or one of many other types of software requirements (see Models and Quality Characteristics in the Software Quality KA).
1.4 Emergent Properties
Some requirements represent emergent properties of software—that is, requirements that cannot be addressed by a single component but that depend on how all the software components interoperate. The throughput requirement for a call center would, for example, depend on how the telephone system, information system, and the operators all interacted under actual operating conditions. Emergent properties are crucially dependent on the system architecture.
1.5 Quantifiable Requirements
Software requirements should be stated as clearly and as unambiguously as possible, and, where appropriate, quantitatively. It is important to avoid vague and unverifiable requirements that depend for their interpretation on subjective judgment (“the software shall be reliable”; “the software shall be user-friendly”). This is particularly important for nonfunctional requirements. Two examples of quantified requirements are the following: a call center’s software must increase the center’s throughput by 20%; and a system shall have a probability of generating a fatal error during any hour of operation of less than 1 * 10 −8 . The throughput requirement is at a very high level and will need to be used to derive a number of detailed requirements. The reliability requirement will tightly constrain the system architecture.
