---
title: "Requirement engineering and specification"
subject: "Software Engineering"
chapter: 1
key: "semester_5/software_engineering:requirement-engineering-views"
source: https://www.bctengineer.com/q/semester_5/software_engineering/requirement-engineering-views
site: BCT Engineering
---

# Requirement engineering and specification

Software Engineering · Chapter 1: Software Process and requirements

- Asked in: year not given, 10 marks
- Video: [Software Requirements | Requirement Engineering | Feasibility Study, Elicitation, SRS, Validation](https://www.youtube.com/watch?v=JNLRXczA9Y0) — Gate Smashers
- Answer checked by Claude Sonnet 5.5 on 2026-10-14
- Page: https://www.bctengineer.com/q/semester_5/software_engineering/requirement-engineering-views
- Whole chapter: https://www.bctengineer.com/md/semester_5/software_engineering/chapter-1

## Question

Give your views on requirement engineering and requirement specification.

## Short answer

Requirements engineering (RE) is the process of eliciting, analyzing, specifying, and validating customer needs. It is iterative and critical because most project failures stem from poor requirements. Requirements specification produces the SRS document detailing user and system requirements.

## Answer

#### 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):

```text
 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:
| Notation | Description |
|---|---|
| Natural language | Numbered sentences; easy but can be ambiguous |
| Structured natural language | Standard forms/templates for each requirement |
| Design description language | Program-like language (PDL) |
| Graphical notations | Use case, sequence, DFD diagrams |
| Mathematical (formal) | Z, finite state machines; precise but hard |

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.

## Check yourself

The answer's key points as multiple-choice questions, with the correct option and why.

1. What is requirements engineering (RE)?
   A. Writing code for the services the customer needs
   B. Finding out, analysing, documenting and checking the services a customer needs and the constraints on the system
   C. Testing the finished system against the customer's needs
   D. Estimating cost and schedule of the project
   Answer: B. RE is the process of discovering, analysing, documenting and validating services and constraints; it comes before design, coding and testing. (Key point: Definition of RE)

2. Which set lists the main RE activities in order?
   A. Specification, feasibility study, validation, elicitation
   B. Elicitation, feasibility study, validation, specification
   C. Feasibility study, elicitation and analysis, specification, validation
   D. Validation, specification, elicitation, feasibility study
   Answer: C. The flow is feasibility study, then elicitation and analysis, then specification, then validation, with requirements management throughout. (Key point: RE activities)

3. Why is poor requirements work considered so costly?
   A. Error cost is the same in every phase
   B. An error found after delivery may cost about 100 times more than one found in requirements
   C. Requirement errors never affect design
   D. Errors are cheaper to fix after delivery because users report them
   Answer: B. Errors found early are cheapest; a requirement error found after delivery may cost around 100 times as much to fix. (Key point: Cost of requirement errors)

4. How do user requirements differ from system requirements?
   A. User requirements are detailed and for developers; system requirements are high-level
   B. User requirements are high-level natural-language statements for customers; system requirements are detailed descriptions for developers
   C. They are identical, only named differently
   D. User requirements are always written in formal mathematics
   Answer: B. User requirements are high-level for customers and managers; system requirements are detailed and may be part of the contract. (Key point: Levels of requirements)

5. Which statement about a good SRS is correct?
   A. It should describe how the system is implemented
   B. It should state what the system does, not how it is implemented
   C. It should be written only in formal notation
   D. It should be left unchanged once signed, even if out of date
   Answer: B. An SRS states what the system must do; and it should also be kept up to date because an out-of-date SRS is worse than none. (Key point: Qualities of a good SRS)

## Related in Software Engineering

- [Importance of requirement engineering; elicitation techniques](https://www.bctengineer.com/question.md?key=semester_5%2Fsoftware_engineering%3Arequirement-engineering-importance) — Software Engineering, chapter 1
- [Requirement management process](https://www.bctengineer.com/question.md?key=semester_5%2Fsoftware_engineering%3Arequirement-management) — Software Engineering, chapter 1
- [Requirement gathering and analysis techniques](https://www.bctengineer.com/question.md?key=semester_5%2Fsoftware_engineering%3Arequirement-gathering-techniques) — Software Engineering, chapter 1
- [Requirement gathering processes compared](https://www.bctengineer.com/question.md?key=semester_5%2Fsoftware_engineering%3Arequirement-gathering-processes) — Software Engineering, chapter 1
- [Architecture before specification; client-server](https://www.bctengineer.com/question.md?key=semester_5%2Fsoftware_engineering%3Aarchitecture-before-specification) — Software Engineering, chapter 3

## Related in other subjects

- [Steps for rice irrigation requirement](https://www.bctengineer.com/question.md?key=semester_6%2Firrigation_and_drainage_engineering%3Arice-irrigation-requirement-steps) — Irrigation and Drainage Engineering, chapter 2, asked 4×
- [Steps of crop water requirement calculation](https://www.bctengineer.com/question.md?key=semester_6%2Firrigation_and_drainage_engineering%3Acrop-water-requirement-steps) — Irrigation and Drainage Engineering, chapter 2, asked 2×
- [BPT requirement; residual head at stand post](https://www.bctengineer.com/question.md?key=semester_5%2Fwater_supply_engineering%3Abpt-requirement-residual-head) — Water Supply Engineering, chapter 9
- [Crop water requirement and its factors](https://www.bctengineer.com/question.md?key=semester_6%2Firrigation_and_drainage_engineering%3Acrop-water-requirement-factors) — Irrigation and Drainage Engineering, chapter 2