Chapter 7 - Requirements Specification

01

Where Does Specification Fit in the RE Process?

Specification is the 4th step in Requirements Development — after Inception, Elicitation, and Analysis. It comes before Validation and is followed by Requirements Management.

✔
Inception

→

✔
Elicitation

→

✔
Analysis

→

📄
Specification

→

Validation

→

Management

📌 What is Requirements Specification?

The result of requirements development is a documented agreement among stakeholders about the product to be built. The three main documents produced across RE are:

Document	Contains	Audience
Vision & Scope Document	Business requirements, high-level scope	Executives, sponsors
Use Cases / User Stories	User requirements	Developers, users
SRS	Functional + Non-functional requirements	All stakeholders

Requirements can be represented in three ways:

📝 Natural Language

Well-structured and carefully written sentences. Most common and accessible to all stakeholders, but prone to ambiguity without care.

📈 Visual Models

Diagrams such as UML Use Case, Class, Activity, Sequence diagrams. Complement written requirements and aid understanding.

🔢 Formal Specifications

Use mathematically precise specification languages. Provide the greatest rigor and precision, but few developers — and even fewer customers — are familiar with them. Rarely used in practice.

02

The Software Requirements Specification (SRS)

🏷

Many Names, One Document

The SRS is also called: Business Requirements Document (BRD), functional specification, product specification, system specification, or simply "requirements document." All are the same artifact.

✓ What the SRS DOES contain

Functions and capabilities the system must provide
System characteristics and constraints it must respect
System behaviors under various conditions
Desired qualities: performance, security, usability
Known design and implementation constraints
Basis for planning, design, coding, testing, and user documentation

✗ What the SRS does NOT contain

Design decisions — how the system will be built
Construction or implementation details
Testing procedures or test scripts
Project management details

🔑 The SRS says WHAT the system should do, never HOW.

💡

SRS as a Foundation

The SRS is the basis for subsequent project planning, design, and coding, as well as the foundation for system testing and user documentation.

03

SRS Audience 8 TYPES

❗

Critical Rule to Memorize

If a desired capability or quality doesn't-appear-somewhere-in-the-requirements-agreement,-no-one-should-expect-it-to-appear-in-the-product.-If-it's not written, it won't be built.

💻

Developers

Need to know what to build

📋

Project Managers

Need it for schedule & resource estimations

🛒

Customers, Marketing & Sales

Know what product they expect to be delivered

🧪

Testers

Develop requirements-based tests & test plans

🔧

Maintenance & Support

Understand what each part of the product should do

📖

Documentation Writers & Trainers

Develop user manuals and educational material

⚖

Legal Staff

Ensure requirements comply with laws & regulations

🏗

Subcontractors

Base their work on — and can be legally held to — the specified requirements

💡

Why Different Models Exist

A single requirements deliverable often cannot meet the needs of all audiences. Some need only business objectives, others need the big picture, and some need all the details. This is why we create different models (use cases, class diagrams, etc.) alongside the SRS.

04

Labeling Requirements KEY TOPIC

Every requirement needs a unique and persistent identifier. Simple numbered or bulleted lists are not adequate.

Why Unique Labels Matter

Helps refer to specific requirements in change requests and modification history
Enables requirements to be reused across multiple projects
Facilitates collaboration between team members
Enables a proper requirements traceability matrix
A number is never reused if a requirement is deleted — prevents confusion

The 3 Labeling Methods — compared:

Method 1 — Sequence Number e.g. FR-26 · UC-9

Simplest approach. Gives every requirement a unique number. The prefix indicates the type (FR = Functional Req, UC = Use Case). Numbers are never reused. Used by commercial RM tools.

✔ Pros

Easy to retain unique ID when moving requirements around
Supported by commercial requirements management tools

✘ Cons

No logical or hierarchical grouping of related requirements
Numeric labels tell you nothing about the intent of a requirement

Method 2 — Hierarchical Numbering e.g. 3.2.4.3

If functional requirements appear in section 3.2 of your SRS, all their labels begin with "3.2". More digits = lower-level requirement. 3.2.4.3 is a child of 3.2.4.

✔ Pros

Simple, compact, and familiar to most people
Word processor can assign numbers automatically
Supported in requirements management tools

✘ Cons

Labels can grow to many digits in a medium-sized SRS
Numeric labels tell you nothing about intent

⚠️

TRAP — Word Processor Labels Are Not Persistent!

Insert, move, merge, or delete a requirement and all section labels will change automatically. Mitigation: Number sections hierarchically but use a short text code + sequence number within each section. e.g., Section 3.5 "Editor Functions" → ED-1, ED-2, etc.

Method 3 — Hierarchical Textual Tags e.g. Product.Cart.Error

Unique ID = Parent label.Child label. Tags are structured, meaningful, and unaffected by adding, deleting, or moving other requirements.

Product: — Ordering products from the website

.Cart — The website shall use a shopping cart to contain products a Customer selects.

.Discount — The shopping cart shall provide one discount code field.

.Error — If an invalid code is entered, display an error message.

.Shipping — The cart shall add a shipping charge for physical products to be mailed.

✔ Pros

Avoids maintenance problems of hierarchical numbers
Tags are meaningful — label shows the intent
Unaffected by inserting, deleting, or moving requirements

✘ Cons

Tags are longer and harder to create
Harder to maintain uniqueness in large projects

Mitigation: Combine hierarchical naming + sequence number: Product.Cart.01

Method	Example	Strength	Weakness
Sequence Number	FR-26	Simple, persistent, tool-friendly	No hierarchy, no meaning in label
Hierarchical Number	3.2.4.3	Familiar, auto-generated	Not persistent in word processors
Hierarchical Text Tag	Product.Cart.01	Meaningful, persistent, structured	Longer, harder to maintain

🏆

Past Exam — Quiz 2 (Term 201), Q2B PAST EXAM

"Based on the Volere shell, which prioritization technique is it adopting or closest to?"

The Volere shell uses Customer Satisfaction (1–5) and Customer Dissatisfaction (1–5) scores. This maps to Prioritization based on Value, Cost, and Risk — the analytical method that uses measurable scores rather than subjective grouping (like MoSCoW or 3-level scales).

05

Dealing with Incompleteness — TBD

No requirements document will be 100% complete on the first draft. The TBD (To Be Determined) notation is the systematic way to handle gaps.

📋 The 4 TBD Rules

Use TBD to flag any missing information
Plan to resolve all TBDs before implementing a set of requirements
If you must proceed, defer implementing unresolved requirements OR design those portions to be easily modifiable
Record TBDs and other issues in an issues list

⚠️ TBDs Won't Resolve Themselves!

Number each TBD item
Record who is responsible for resolving it
Record by when it must be resolved
Review their status at regular checkpoints
Track them to closure — never let them linger

💡

Memory Trick

Think of TBD items exactly like open software bugs: assign an owner, set a deadline, and track to closure. A TBD with no owner is a TBD that will never be resolved.

06

User Interfaces and the SRS

Including UI designs in the SRS is a double-edged sword. Here is the full balanced view:

👍 Benefits of Including UI in SRS

Paper prototypes, wireframes, and mock-ups make requirements tangible to both users and developers
Helps set accurate user expectations about the look & feel of the product
Easier for non-technical stakeholders to validate requirements

👎 Drawbacks of Including UI in SRS

Screen images make the SRS much larger — big documents scare people away
Delaying baselining until UI design is complete slows development
UI design can start driving requirements → leads to functional gaps

❗

Golden Rule — Screen Layouts Never Replace Functional Requirements

Don't expect developers to derive underlying functionality and data relationships from screenshots alone. If a functionality must be implemented with specific UI controls, you must explicitly state it in the SRS as a written functional requirement.

📚 SRS Readability Tips

Use an appropriate template to organize all necessary information
Label and style sections, subsections, and individual requirements consistently
Use visual emphasis (bold, underline, italics, color) consistently — remember: color may be invisible to colorblind readers or when printed in grayscale
Create a table of contents so readers can find information quickly
Number all figures and tables, give them captions, and refer to them by number
Use cross-references (not hard-coded page numbers) to link within the document
Define hyperlinks to let readers jump to related sections
Include visual representations of information whenever possible to aid understanding

07

Requirements Specification Best Practices MEMORIZE

There are 5 core best practices for requirements specification. Memorize them:

📄

Adopt requirement document templates

🔎

Identify requirement origins

🏷

Uniquely label each requirement

📜

Record business rules

⚙

Specify non-functional requirements

🧠

Memory Trick — Acronym "AILRS"

Adopt templates → Identify origins → Label uniquely → Record business rules → Specify NFRs

08

The Requirement Shell (Volere Shell) PAST EXAM

The Volere Shell is a structured template for documenting a single requirement. It captures everything needed to understand, prioritize, trace, and verify that requirement. Think of it as a "business card" for one requirement.

Requirement #

Unique identifier (e.g. FR-26)

Requirement Type

The type from the template (functional, NFR, constraint, etc.)

Event / Use Case #

List of events or use cases that need this requirement

Description

A one sentence statement of the intention of the requirement

Rationale

A justification of the requirement — why is it needed?

Source

Who raised this requirement?

Fit Criterion

A measurement of the requirement such that it is possible to test whether the solution matches the original requirement (makes it verifiable)

Customer Satisfaction

Degree of stakeholder happiness if this requirement is successfully implemented.
Scale: 1 (uninterested) → 5 (extremely pleased)

Customer Dissatisfaction

Measure of stakeholder unhappiness if this requirement is NOT in the product.
Scale: 1 (hardly matters) → 5 (extremely displeased)

Dependencies

A list of other requirements that have some dependency on this one

Conflicts

Other requirements that cannot be implemented if this one is included

Supporting Materials

Pointer to documents that illustrate and explain this requirement

History

Creation date, changes, and who made them

🏆

Past Exam — Quiz 2 (Term 201), Q2A & Q2B PAST EXAM

Q2A: "How can the information in this Volere shell be used to prioritize requirement #75?"

Use the Customer Satisfaction and Customer Dissatisfaction scores. A requirement with Satisfaction = 5 AND Dissatisfaction = 5 has the highest priority — stakeholders care deeply both ways. Also check Dependencies: if a lower-priority requirement blocks this one, it must be reconsidered. The Source tells who raised it (executive vs. user), which can also weight priority.

Q2B: "Which prioritization technique is the Volere shell closest to?"
Prioritization based on Value, Cost, and Risk — because it uses a measurable, analytical satisfaction/dissatisfaction scale (1–5) rather than subjective groupings like MoSCoW or 3-level scales.

09

Study Tips & Memorization Tricks 🧠

💡 WHAT not HOW

If a requirement says HOW something will be built, it doesn't belong in the SRS — that's design. The SRS only describes behavior and desired qualities.

💡 SRS Document Map

Vision & Scope = Business reqs. Use Cases = User reqs. SRS = Functional + Non-functional reqs. Know which document holds which type — it comes up in exams.

💡 3 Labeling Methods — S-H-T

Sequence (FR-26) → Hierarchical number (3.2.4) → Textual tag (Product.Cart.01). Each adds more meaning but also more maintenance cost.

💡 Volere = Requirement Card

Think of each Volere shell as a "business card" for one requirement. It has the ID, description, rationale, source, fit criterion, satisfaction scores, dependencies, conflicts, and history.

💡 TBD = Open Bug Ticket

Treat TBDs like software bugs: assign an owner, set a deadline, track to closure. A TBD with no owner is a TBD that will never be resolved.

💡 UI in SRS = Double Edge

UI in SRS makes things tangible (+) but bloats the doc and lets design drive requirements (−). Screen layouts NEVER replace written functional requirements.

💡 Best Practices = AILRS

Adopt templates → Identify origins → Label uniquely → Record business rules → Specify NFRs. Five items only.

💡 8 Audiences — Key Rule

Dev, PM, Customer/Mktg, Testers, Maintenance, Docs Writers, Legal, Subcontractors. If it's not in the SRS — nobody can expect it in the product!

🎯 Exam-Likely Questions for Chapter 7

What is the SRS and what does it contain / NOT contain?
Name 3 ways to represent requirements in the SRS (natural language, visual, formal).
List and compare the 3 requirements labeling methods with pros and cons.
Why does every requirement need a unique label?
How should TBDs be handled? Why can't you ignore them?
What are the pros and cons of including UI designs in the SRS?
What are the 5 requirements specification best practices?
What is a Volere Shell and what are its main fields?
How do satisfaction/dissatisfaction scores in the Volere shell help prioritization?
Name 4 audiences of the SRS and what they use it for.
What is the TRAP with hierarchical numbering in word processors, and what is the mitigation?
What is the difference between the Vision & Scope document and the SRS?