A Comprehensive Guide to Software Requirements Development and Management
A requirement is an expression of desired behavior that focuses on customer needs, not on the solution or implementation. Requirements designate what behavior is needed, without specifying how that behavior will be realized.
The process of establishing the services that a customer requires from a system and the constraints under which it operates and is developed. The system requirements are the descriptions of the system services and constraints that are generated during the requirements engineering process.
Fixing a requirements error after delivery may cost up to 100 times the cost of fixing an implementation error. Early validation is crucial.
Clear, well-documented requirements are fundamental to project success and serve as the foundation for design and development.
Requirements ensure all stakeholders have a shared understanding of what the system should do and how it should perform.
Audience: Customers and end-users
Format: Natural language plus diagrams
Purpose: Describe the services the system provides and its operational constraints in terms understandable by non-technical stakeholders
Audience: Developers and technical team
Format: Structured document with detailed descriptions
Purpose: Define what should be implemented; may be part of a contract between client and contractor
User Requirement:
"The Mentcare system shall generate monthly management reports showing the cost of drugs prescribed by each clinic during that month."
System Requirements Specification:
Functional Requirements are statements of services the system should provide, how the system should react to particular inputs, and how the system should behave in particular situations. They may also state what the system should not do.
Non-Functional Requirements define system properties and constraints such as reliability, response time, and storage requirements. They may be more critical than functional requirements—if not met, the system may be useless.
| Category | Description | Examples |
|---|---|---|
| Product Requirements | Specify or constrain the runtime behavior of the software | Execution speed, reliability, security, usability |
| Organizational Requirements | Consequence of organizational policies and procedures | Development process requirements, programming languages, operational standards |
| External Requirements | Arise from factors external to the system and its development | Regulatory requirements, legislative requirements, ethical requirements |
Product Requirement:
"The Mentcare system shall be available to all clinics during normal working hours (Mon–Fri, 08:30–17:30). Downtime within normal working hours shall not exceed five seconds in any one day."
Organizational Requirement:
"Users of the Mentcare system shall authenticate themselves using their health authority identity card."
External Requirement:
"The system shall implement patient privacy provisions as set out in HStan-03-2006-priv."
Domain Requirements are constraints on the system from the domain of operation. They reflect the characteristics and constraints of the application domain.
Any person or organization who is affected by the system in some way and who has a legitimate interest in it.
People who will directly interact with and use the system
Those responsible for managing the system's operation
Organizations or individuals who own and fund the system
Regulatory bodies, partners, and other affected parties
The processes used for requirements engineering vary widely depending on the application domain, the people involved, and the organization. However, there are generic activities common to all processes. In practice, RE is an iterative activity in which these processes are interleaved.
Working with stakeholders to discover and understand their requirements. This involves gathering information about the application domain, work activities, desired services and features, performance requirements, and hardware constraints.
Examining, classifying, and organizing requirements. This includes grouping related requirements into coherent clusters, prioritizing requirements, and resolving conflicts between different stakeholder needs.
Checking that the requirements actually define the system that the customer really wants. This involves demonstrating validity, consistency, completeness, and realism of requirements.
Managing changing requirements during the RE process and system development. This includes tracking individual requirements and maintaining links between dependent requirements to assess the impact of changes.
The process of gathering information about the required and existing systems and distilling the user and system requirements from this information. Involves interaction with system stakeholders from managers to external regulators.
Interacting with stakeholders to discover their requirements. Domain requirements are also discovered at this stage.
Grouping related requirements and organizing them into coherent clusters.
Prioritizing requirements and resolving requirements conflicts between stakeholders.
Requirements are documented and prepared as input for the next phase of development.
Talking to people about what they do. This is the most common elicitation technique where requirements engineers conduct structured or unstructured interviews with stakeholders to understand their needs, workflows, and expectations.
Best for: Understanding individual perspectives, exploring specific concerns, and gathering detailed information about work processes.
Watching people doing their job to see what artifacts they use, how they use them, and understanding the context of their work. This technique helps uncover implicit requirements that stakeholders might not articulate in interviews.
Best for: Understanding actual work practices, identifying unstated requirements, and recognizing the social and organizational context of system use.
Real-life examples of how a system can be used. Stories and scenarios describe how a system may be used for particular tasks. Because they're based on practical situations, stakeholders can relate to them and provide meaningful feedback.
Best for: Making requirements concrete, facilitating discussion with stakeholders, and ensuring shared understanding of system use cases.
Context: Salah is a primary school teacher planning a class project about the fishing industry.
"Pupils should gather and share old memories from relatives, use newspaper archives and collect old photographs related to fishing and fishing communities in the area. Pupils use a wiki to gather fishing stories and use SCRAN (a history resources site) to access newspaper archives and photographs. I also need a photo sharing site as I want pupils to take and comment on each others' photos and to upload scans of old photographs that they may have in their families."
A user or group of users have one or more digital photographs saved on a tablet or laptop computer. They have successfully logged on to the system.
The user chooses "upload photos" and is prompted to select photos from their computer and the project name. Users can input keywords for each photo. Uploaded photos are named by combining username with the filename. On completion, the system sends an email to the project moderator and displays a confirmation message to the user.
The moderator may be logged on and may approve photos as they are uploaded.
User is logged on. Selected photos have been uploaded and assigned status "awaiting moderation". Photos are visible to the moderator and the uploading user.
The process of writing down the user and system requirements in a requirements document. User requirements must be understandable by end-users and customers without technical backgrounds. System requirements are more detailed and may include technical information. Requirements may be part of a contract for system development, so completeness is crucial.
| Notation | Description | Best Use Cases |
|---|---|---|
| Natural Language | Requirements written using numbered sentences in natural language. Each sentence expresses one requirement. | User requirements, general documentation |
| Structured Natural Language | Requirements written on a standard form or template. Each field provides information about an aspect of the requirement. | System requirements with consistent format |
| Design Description Languages | Programming-like language with abstract features to specify requirements by defining an operational model. | Interface specifications (rarely used now) |
| Graphical Notations | Graphical models supplemented by text annotations (e.g., UML use case and sequence diagrams). | Functional requirements visualization |
| Mathematical Specifications | Based on mathematical concepts such as finite-state machines or sets. Unambiguous but may not be understood by customers. | Critical systems requiring formal verification |
Requirements are often written in natural language because it is expressive, intuitive, and universal. This ensures requirements can be understood by users and customers who may not have technical backgrounds.
Requirement 3.2:
"The system shall measure the blood sugar and deliver insulin, if required, every 10 minutes."
Rationale: Changes in blood sugar are relatively slow, so more frequent measurement is unnecessary; less frequent measurement could lead to unnecessarily high sugar levels.
Requirement 3.6:
"The system shall run a self-test routine every minute with the conditions to be tested and the associated actions defined in Table 1."
Rationale: A self-test routine can discover hardware and software problems and alert the user to the fact that normal operation may be impossible.
The software requirements document is the official statement of what is required of the system developers. It should include both a definition of user requirements and a specification of the system requirements.
Important: It is NOT a design document. As far as possible, it should set out WHAT the system should do rather than HOW it should do it.
Many agile methods argue that producing detailed system requirements is a waste of time because requirements change so quickly, making the requirements document always out of date.
Agile Approach: Use incremental requirements engineering and express requirements as "user stories"
Practical for: Business systems with rapidly changing requirements
Problematic for:
Concerned with demonstrating that the requirements define the system that the customer really wants. Requirements error costs are high, so validation is very important—fixing a requirements error after delivery may cost up to 100 times the cost of fixing an implementation error.
Does the requirement really describe the functions which best support the customer's needs?
Is the requirement properly understood by all stakeholders?
Are there any requirements conflicts or contradictions?
Are all functions required by the customer included?
Can the requirements be implemented given available budget and technology?
Can the requirements be checked? Is the requirement realistically testable?
Is the origin of the requirement clearly stated?
Can the requirement be changed without large impact on other requirements?
Systematic manual analysis of requirements. Regular reviews should be held while requirements are being formulated. Both client and contractor staff should be involved. Reviews may be formal (with completed documents) or informal. Good communication between developers, customers, and users can resolve problems at an early stage.
Using an executable model of the system to check requirements. Prototypes help stakeholders visualize the system and identify missing or incorrect requirements early in the development process.
Developing tests for requirements to check testability. If it's difficult to design tests for a requirement, the requirement may be incomplete or too vague and should be revised.
The process of managing changing requirements during the requirements engineering process and system development. New requirements emerge as a system is being developed and after it has gone into use.
Keep track of individual requirements throughout the development lifecycle, maintaining clear identification and status information.
Maintain links between dependent requirements to assess the impact of requirements changes across the system.
Establish a formal process for making change proposals and linking these to system requirements, ensuring controlled evolution.