Requirement engineering and specification

Requirement engineering

Requirements engineering (RE) is the process of finding out, analysing, documenting and checking the services that a customer needs from a system and the constraints under which it must operate. It is the first and one of the most important activities in software engineering, because every later activity (design, coding, testing) depends on it.

Main activities (Sommerville):

 Feasibility study ---------> Feasibility report
        |
        v
 Elicitation and analysis --> System models
        |
        v
 Specification -------------> User and system reqs
        |
        v
 Validation ----------------> Requirements document
 (Requirements management runs throughout)

1. Feasibility study: decides whether the system is worth building (technically, economically, operationally) and whether it supports business goals.
2. Elicitation and analysis: working with stakeholders to discover requirements using interviews, questionnaires, observation (ethnography), workshops, scenarios, use cases and prototypes. Requirements are then classified, organised, prioritised and negotiated to resolve conflicts.
3. Specification: writing the requirements down in a requirements document.
4. Validation: checking that the requirements define the system the customer really wants, using reviews, prototyping and test-case generation. Checks include validity, consistency, completeness, realism and verifiability.
5. Requirements management: managing changes to requirements throughout the project, keeping traceability between requirements, design and code.

In practice, RE is an iterative process (Sommerville's spiral view): elicitation, specification and validation are repeated with increasing detail.

My views on RE:

• Most project failures are due to poor requirements, not poor coding. Errors found in requirements are cheapest to fix; the same error found after delivery may cost 100 times more.
• RE is as much about communication and negotiation among stakeholders as about technical work.
• Requirements will change; RE must expect and manage change instead of trying to freeze everything.

Requirement specification

Requirements specification is the activity of writing user and system requirements into a requirements document, the Software Requirements Specification (SRS). The SRS is the official statement of what the developers must implement.

Levels of requirements:

• User requirements: high-level statements in natural language plus diagrams, for customers and managers.
• System requirements: detailed descriptions of functions, services and constraints, for developers; may be part of the contract.

Ways of writing specifications:

Typical SRS structure (based on IEEE 830): introduction (purpose, scope, definitions, references, overview), overall description (product perspective, functions, user characteristics, constraints, assumptions), and specific requirements (functional, external interfaces, performance, design constraints, quality attributes), plus appendices and index.

A good SRS should be correct, unambiguous, complete, consistent, ranked for importance, verifiable, modifiable and traceable. It should state what the system does, not how it is implemented.

My views on specification:

• The SRS acts as a contract, the basis for design, cost estimation, test planning and acceptance.
• It should be readable by both users and developers; using diagrams and examples alongside text helps.
• It should be kept up to date; an out-of-date SRS is worse than none.
• For agile projects, lightweight forms (user stories with acceptance criteria) can replace a large document, but the purpose, a shared understanding of what to build, remains the same.