Software Requirements

Chapter 1: Software Requirements

Acronyms

Acronym	Full Form
ATDD	Acceptance Test Driven Development
BDD	Behavior Driven Development
CIA	Confidentiality, Integrity, and Availability
FSM	Functional Size Measurement
INCOSE	International Council on Systems Engineering
JAD	Joint Application Development
JRP	Joint Requirements Planning
SME	Subject Matter Expert
SysML	Systems Modeling Language
TDD	Test Driven Development
UML	Unified Modeling Language

Introduction

Software requirements can be viewed from two perspectives. The first is as an expression of the needs and constraints on a software product that contribute to solving a real-world problem. The second perspective covers the activities necessary to develop and maintain these requirements.

Poorly defined requirements can lead to increased costs, delays, defects, or even project cancellation. This is because each requirement cascades into numerous design, code, and testing decisions. Errors in requirements, if not caught early, can cause exponentially increasing rework.

Two common problems with software requirements are:

Incompleteness: Necessary stakeholder requirements are not communicated to the software engineers.
Ambiguity: Requirements are open to multiple interpretations, with only one being correct.

Requirements play a crucial long-term role in software maintenance. While an engineer can determine what existing code does through various analysis methods, only the requirements documentation can clarify what the code was intended to do. A defect (or bug) is a difference between the software’s intent and its actual behavior. Requirements documentation captures and communicates this intent for future maintainers.

The Software Requirements Knowledge Area (KA) focuses on developing and managing requirements throughout the software’s service life. It emphasizes that requirements are not a one-time, front-end activity but an ongoing process of refinement. The approach to requirements should be tailored to the specific organization and project context.

The term “requirements engineering” is often used for the systematic handling of requirements. This KA is closely related to Software Architecture, Design, Construction, Testing, and Maintenance. The project’s life cycle (e.g., Waterfall, Iterative, Agile) determines when requirements work is done, but the what and how should be determined by the nature of the software itself. For instance, in a Waterfall model, requirements are finalized upfront, whereas in an Agile model, they are handled incrementally.

Breakdown of Topics for Software Requirements

The Software Requirements KA is broken down into the following major topics:

Software Requirements Fundamentals
Requirements Elicitation
Requirements Analysis
Requirements Specification
Requirements Validation
Requirements Management Activities
Practical Considerations
Software Requirements Tools

1. Software Requirements Fundamentals

1.1 Definition of a Software Requirement

A software requirement is a property that a product must exhibit to solve a real-world problem. Formally, it is defined as:

A condition or capability a user needs to solve a problem or achieve an objective.
A condition or capability that a system must meet to satisfy a contract, standard, or other formal document.
A documented representation of one of the above.

Requirements often arise from a complex mix of needs from various stakeholders, including clients, customers, users, and regulatory bodies.

1.2 Categories of Software Requirements

Software requirements can be categorized to better manage complexity. The main categories are Software Product Requirements and Software Project Requirements.

Software Product Requirements specify the software’s expected form, fit, or function. These are further divided into:
- Functional Requirements: Specify observable behaviors, policies, and processes. For example, “an account’s balance shall never be negative.”
- Nonfunctional Requirements: Constrain the implementation technologies or operational characteristics. These are broken down into:
  - Technology Constraints: Mandate or prohibit specific technologies, such as requiring the use of a particular programming language (e.g., Java, Python) or database engine (e.g., Oracle, MySQL).
  - Quality of Service Constraints: Specify acceptable performance levels without naming specific technologies. Examples include response time, throughput, reliability, security, and safety.
Software Project Requirements (or process requirements) constrain the project that builds the software, such as cost, schedule, and staffing. This KA focuses on product requirements.

Categorizing requirements this way helps manage complexity, isolate expertise, and apply appropriate elicitation and analysis techniques. A helpful way to distinguish functional from nonfunctional requirements is the “Perfect Technology Filter”: functional requirements are those that would still exist even with a perfect computer (infinite speed, memory, etc.). All other product requirements are nonfunctional.

1.3 System Requirements and Software Requirements

A system is an interacting combination of elements (hardware, software, people, etc.) to achieve an objective. System requirements apply to the entire system (e.g., an autonomous vehicle), while software requirements apply only to a software component within that system. Sometimes, software requirements are derived from system requirements.

1.4 Derived Requirements

A derived requirement is not stated by an external stakeholder but is imposed by the development team. For instance, an architect’s decision to use a specific architecture becomes a requirement for the sub-teams building components within that architecture.

1.5 Software Requirements Activities

Requirements activities are divided into two main groups:

Requirements Development: The process of reaching an agreement on what to build. It includes:
- Elicitation
- Analysis
- Specification
- Validation
Requirements Management: The process of maintaining that agreement over time. It includes:
- Scrubbing
- Change Control
- Scope Matching

2. Requirements Elicitation

Requirements elicitation (also called requirements capture or discovery) aims to surface candidate requirements. Well-executed elicitation helps minimize incompleteness.

2.1 Requirements Sources

Requirements can come from various sources. A stakeholder is any person, group, or organization involved in, affected by, or able to influence the project.

Stakeholder sources include clients, customers, users, SMEs, operations staff, regulatory agencies, and developers. A stakeholder analysis helps identify all relevant classes of stakeholders to avoid bias.
Non-person sources include existing documentation, other systems, the business context, and the computing environment.

2.2 Common Requirements Elicitation Techniques

A variety of techniques can be used to elicit requirements, including:

Interviews
Meetings and facilitated workshops (e.g., JAD, JRP)
Brainstorming
Focus groups and surveys
Exploratory prototyping
User story mapping
Observation and apprenticing (where the engineer learns by doing the work)
Analysis of existing systems and documentation
Design thinking

Elicitation is an active process; engineers must work diligently to extract the right information, as many requirements may be tacit or unstated.

3. Requirements Analysis

Elicited requirements often need further investigation to understand their full meaning and implications. Requirements analysis helps establish desirable properties for each requirement and for the overall set.

Properties of individual requirements: Each should be unambiguous, testable, binding, atomic, and use stakeholder vocabulary.
Properties of the requirements collection: The set should be complete, concise, and internally and externally consistent.

The 5-whys technique can help uncover the true problem behind a stated requirement by repeatedly asking “Why?” until the core need is identified.

3.1 Economics of Quality of Service Constraints

Quality of service constraints (e.g., performance, reliability) are best understood from an economic perspective. For any such constraint, there is a value curve that maps performance levels to stakeholder value. This curve typically has:

A Perfection Point: The performance level beyond which there is no additional value.
A Fail Point: The performance level below which the system is essentially useless.

The cost to deliver a certain performance level is usually a step function. The goal is to find the most cost-effective performance level, which provides the maximum positive difference between value and cost.

3.2 Formal Analysis

In high-integrity systems, formal analysis uses specification languages with mathematically defined semantics. This allows requirements to be precise and enables proofs about the specified software’s properties (e.g., absence of deadlock), which helps in static validation.

3.3 Addressing Conflict in Requirements

With diverse stakeholders, conflicts are likely. Key approaches to manage conflict include:

Negotiation: Facilitating a consensus resolution among stakeholders.
Product Family Development: Separating requirements into invariant (agreed-upon) and variant (conflicting) sets. The software is then designed to accommodate the invariants while providing customization points for the variants.

4. Requirements Specification

This concerns recording requirements for communication and memory. The key questions are whether to write requirements down, in what form, and whether to maintain them. The answers depend on project-specific factors like risk, team distribution, and contractual obligations.

The most basic recommendation is to perform an audience analysis to determine who needs what information and how to best present it.

Several specification techniques exist:

4.1 Unstructured Natural Language

Requirements are expressed in ordinary language, such as a collection of “The system shall…” statements or business rules.

4.2 Structured Natural Language

Constraints are imposed on how requirements are expressed to increase precision. Examples include:

Actor-action format: “When , the shall unless .”
Use case templates: Detailing triggers, parameters, courses of action, and exceptions.
User story format: “As a , I want so that .“

4.3 Acceptance Criteria-Based Specification

This approach defines requirements in the form of tests that must pass.

Acceptance Test Driven Development (ATDD): Before code is written, stakeholders agree on acceptance tests for a unit of functionality. Development proceeds until all tests pass.
Behavior Driven Development (BDD): This is a more structured variant of ATDD. A user story leads to defining scenarios in a “Given , When , Then ” format. A comprehensive set of scenarios defines the requirements for the story.

This method directly addresses ambiguity because test case language is precise.

4.4 Model-Based Specification

This uses modeling languages like UML or SysML to precisely specify requirements, much like blueprints in construction.

Structural models (e.g., class models) specify policies.
Behavioral models (e.g., use cases, state models) specify processes.

Models can range in formality from informal Agile sketches to semiformal models with defined semantics, to fully formal models (e.g., Z, VDM) that allow for mechanical analysis.

4.5 Additional Attributes of Requirements

Documenting extra attributes for each requirement can be useful. Attributes can include a unique tag, rationale, source, priority, stability, dependencies, and acceptance criteria.

4.6 Incremental vs. Comprehensive Specification

Incremental Specification: Each new version of the specification only documents the changes (additions, modifications, deletions) from the previous one.
Comprehensive Specification: Each version is a complete document containing all current requirements. A hybrid approach is also common, with incremental updates for minor releases and a comprehensive document for major releases.

5. Requirements Validation

Validation aims to gain confidence that the requirements accurately represent stakeholder needs. This involves checking for completeness, correctness, consistency, and clarity. Common validation methods include:

Requirements Reviews: One or more reviewers inspect the requirements document for errors and omissions from different perspectives (client, user, developer).
Simulation and Execution: If requirements are specified in a formal model, they can be “executed” or simulated to demonstrate behavior to stakeholders.
Prototyping: Building a prototype to demonstrate an interpretation of the requirements. Prototypes can expose incorrect assumptions but can also be costly and may distract from core functionality.

6. Requirements Management Activities

This involves maintaining the agreement on requirements over time.

6.1 Requirements Scrubbing

The goal is to find the smallest, simplest set of requirements that still meets stakeholder needs. This involves eliminating out-of-scope, low-value, or overly complicated requirements to reduce solution complexity, cost, and schedule.

6.2 Requirements Change Control

This is a formal process for managing changes to agreed-upon requirements. It typically includes a change request mechanism, impact analysis, a decision-making body, and a process for notifying stakeholders. In Agile life cycles, change control is implicit; a change request simply becomes another item on the product backlog to be prioritized.

6.3 Scope Matching

This involves ensuring that the scope of the requirements does not exceed project constraints (cost, schedule, staffing). If it does, the scope must be reduced, capacity must be increased, or a combination of both must be negotiated.

7. Practical Considerations

7.1 Iterative Nature of the Requirements Process

Requirements work is rarely a single-pass activity. Teams often iterate between exploring the breadth of requirements and deepening their understanding of specific areas.

7.2 Requirements Prioritization

Prioritization helps focus on delivering the most valuable functionality first and supports trade-off decisions. Factors for prioritization can include business value, cost, risk, and user satisfaction versus dissatisfaction (as in the Kano model). A priority can be calculated using an objective function, for example: $Priority = \frac{(Value * (1-Risk))}{Cost}$ Priorities can be expressed using an enumerated scale (e.g., must have, should have), a numerical scale, or a sorted list.

7.3 Requirements Tracing

Tracing documents the relationships between requirements and other project work products. It helps ensure that every requirement is addressed in the design and that every design element exists for a reason. It is also crucial for performing impact analysis on proposed changes. Requirements can be traced backward to their source and forward to design, code, test cases, and user manuals.

7.4 Requirements Stability and Volatility

It is useful to assess how likely a requirement is to change. Stable requirements are unlikely to change, while volatile ones may change frequently, even during the project. Identifying volatile requirements helps in designing a more change-tolerant system.

7.5 Measuring Requirements

Functional Size Measurement (FSM) and story points are techniques for quantifying the “volume” of requirements. This is useful for estimating effort and cost. Quality indicators can also be derived from the desirable properties of requirements to assess the quality of a specification.

7.6 Requirements Process Quality and Improvement

This involves assessing and improving the requirements process itself to enhance its contribution to product quality, cost-effectiveness, and customer satisfaction, often by aligning with process improvement models and standards.

8. Software Requirements Tools

Tools can be categorized into three groups:

Requirements Management Tools: Support activities like storing requirements and their attributes, tracing, document generation, and change control.
Requirements Modeling Tools: Support the creation and analysis of model-based specifications. Some tools offer static analysis (checking for correctness and consistency) or dynamic simulation.
Functional Test Case Generation Tools: Can mechanically derive test cases from formal or semi-formal requirements specifications (e.g., from BDD scenarios or state models).