Difference between revisions of "Chapter 1: Software Requirements"

From SWEBOK
Jump to: navigation, search
(Emergent Properties)
(Quantifiable Requirements)
Line 110: Line 110:
  
 
=== Quantifiable Requirements ===
 
=== Quantifiable Requirements ===
 +
 +
{{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 par-
 +
ticularly important for nonfunctional require-
 +
ments. 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:01, 19 August 2015

Acronyms
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
Introduction

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.

Breakdown of Topics for Software Requirements

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 par- ticularly important for nonfunctional require- ments. 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.

1.6 System Requirements and Software Requirements

2 Requirements Process

2.1 Process Models

2.2 Process Actors

2.3 Process Support and Management

2.4 Process Quality and Improvement

3 Requirements Elicitation

3.1 Requirements Sources

3.2 Elicitation Techniques

4 Requirements Analysis

4.1 Requirements Classification

4.2 Conceptual Modeling

4.3 Architectural Design and Requirements Allocation

4.4 Requirements Negotiation

4.5 Formal Analysis

5 Requirements Specification

5.1 System Definition Document

5.2 System Requirements Specification

5.3 Software Requirements Specification

6 Requirements Validation

6.1 Requirements Reviews

6.2 Prototyping

6.3 Model Validation

6.4 Acceptance Tests

7 Practical Considerations

7.1 Iterative Nature of the Requirements Process

7.2 Change Management

7.3 Requirements Attributes

7.4 Requirements Tracing

7.5 Measuring Requirements

8 Software Requirements Tools