Topic 3 of 9 · Lab IV · open-ended
IEEE Software Requirements Specification (SRS)
Functional and non-functional requirements, what makes a requirement good, how requirements are gathered, and how to write an SRS with the IEEE template, priorities and traceability.
← → move between slides · F full screen · M slide list
Before we start
Why this matters
Ask five students what “a fast, user-friendly library system” means and you will get five different systems.
Requirements turn wishes into statements everyone reads the same way — and that a tester can check. Mistakes here are the most expensive kind: a missing requirement found after release can cost many times more to fix than one found on paper.
This is an open-ended lab: you will write the SRS for your own system using the IEEE structure.
Outline · Lab IV · open-ended
Topics in this chapter
Select a topic to jump to the slide that explains it.
Concept 1 of 15
What a requirement is
A requirement is a statement of something the system must do, or a quality or constraint it must satisfy. The Software Requirements Specification (SRS) collects all of them in one agreed document.
- It is the contract between customer and developers: what will be delivered.
- Designers use it to build the DFD, UML and UI; testers use it to write test cases.
- A requirement says what, not how: “the system shall store each loan” — not “use a MySQL table called loans”.
Concept 1 of 15
What a requirement is (cont.)
Concept 2 of 15
Functional and non-functional requirements
Functional requirements (FR)
What the system does: services, calculations, data it stores, reactions to input.
- The system shall let a customer withdraw cash.
- The system shall print a mini statement.
- The system shall transfer money to another account.
Non-functional requirements (NFR)
How well it does it, or constraints on it: performance, security, usability, reliability…
- The ATM shall respond within 2 seconds.
- All traffic to the bank shall be encrypted.
- The service shall be available 99.5% of each month.
Interactive
Sort the requirements
Functional vs non-functional
Types of non-functional requirement
Functional vs non-functional
Types of non-functional requirement (cont.)
| Group | Examples |
|---|---|
| Product: how the software behaves | usability, efficiency (performance, space), reliability, portability |
| Process / organisational: how it is developed | delivery dates, implementation language, standards to follow |
| External: from outside the project | interoperability with other systems, ethics, law: privacy, safety |
Other names you will meet: availability, maintainability, scalability, security, testability — together called software quality attributes.
Concept 5 of 15
What makes a good requirement
The IEEE recommended practice (IEEE 830) says each requirement, and the SRS as a whole, should be:
| Quality | Meaning | Fails when… |
|---|---|---|
| Correct | it states something the system really must do | nobody actually needs it |
| Unambiguous | it has exactly one interpretation | “fast”, “user-friendly”, “etc.” |
| Complete | every needed behaviour, input and error case is covered | “what if the card cannot be read?” has no answer |
| Consistent | no two requirements conflict | one says 3 PIN tries, another says 5 |
| Ranked | each has a priority (and stability) | everything is “high priority” |
| Verifiable | a test can show it is met | “the system shall be reliable” |
| Modifiable | organised so changes are easy | the same fact is repeated in many places |
| Traceable | each has an ID and a known origin | no IDs, so tests cannot refer to it |
Write each one as “The system shall …”, one requirement per sentence, with an ID such as FR-3 or NFR-PERF-1.
Interactive
Check a requirement
Interactive
Check a requirement (cont.)
Concept 7 of 15
The requirements engineering process
- Elicitation: find out what stakeholders need — interviews, questionnaires, observation, studying existing documents and forms, workshops, prototypes.
- Analysis: remove conflicts and duplicates, find missing cases, set priorities.
- Specification: write the SRS.
- Validation: review it with users; can every requirement be tested?
- Management: control changes after the SRS is approved (change requests, version numbers).
| Technique | Good for |
|---|---|
| Interview | deep understanding of one role (librarian) |
| Questionnaire | many users quickly (200 students) |
| Observation | what people really do, not what they say |
| Document analysis | forms, registers, rules already in use |
| Prototype / wireframe | discovering UI requirements (topic 9) |
Concept 8 of 15
The IEEE SRS structure
The lab manual follows the widely used IEEE-style template (based on IEEE 830-1998, whose successor is ISO/IEC/IEEE 29148). Use these headings for your SRS chapter:
- Introduction — purpose, document conventions, intended audience and reading suggestions, project scope, references.
- Overall description — product perspective, product features, user classes and characteristics, operating environment, design and implementation constraints, user documentation, assumptions and dependencies.
- System features — for each feature: description and priority, stimulus/response sequences, functional requirements.
- External interface requirements — user, hardware, software and communications interfaces.
- Non-functional requirements — performance, safety, security, software quality attributes, business rules.
- Other requirements — database, legal, internationalisation, reuse.
- Appendices — glossary, analysis models (DFD, UML), list of open issues (TBD).
IEEE SRS template
1. Introduction and project scope
- Purpose: identify the product and version this SRS covers, and whether it is the whole system or one subsystem.
- Intended audience: developers, project managers, testers, users, documentation writers — and which sections each should read first.
- Project scope: a short description of the software, its benefits, objectives and goals, related to the organisation’s strategy.
- Conventions and references: fonts, priority rules, other documents this one depends on.
Example: ATM Management System (AMS)
This SRS specifies release 1.0 of the software for an Automated Teller Machine. The AMS lets bank customers withdraw cash, check balances, print mini statements and transfer funds at any time without a bank clerk, reducing branch queues and staff cost. Out of scope: deposit of cash and cheques, and the bank’s central accounting system, which is an external system.
IEEE SRS template
2. Overall description
- Product perspective: is it new, a replacement, or part of a larger system? A block diagram of the main parts and interfaces helps.
- Product features: a high-level list; details come in section 3.
- Operating environment: hardware, OS, other software it must coexist with.
- Constraints: regulations, hardware limits, required language or database, security rules.
- Assumptions and dependencies: e.g. “the bank server offers an API for balance queries”.
| User class | Characteristics | Uses |
|---|---|---|
| Customer | any age, no training, may have poor eyesight | withdraw, balance, statement, transfer |
| Bank operator | trained staff | load cash, view logs, set limits |
| Maintenance technician | technical, rare use | diagnostics, hardware status |
Distinguish the favoured user class (customers) from the less important ones.
IEEE SRS template
3. System features: one feature in detail
3.1 Withdraw cash
Description and priority: A verified customer withdraws cash from a chosen account. Priority: High (benefit 9, penalty 9, cost 5, risk 6 on a 1–9 scale).
Stimulus/response sequences
- Customer selects “Withdraw” → system shows amount choices.
- Customer enters 5,000 Tk → system checks balance and daily limit.
- Check passes → system dispenses cash, prints receipt, returns card.
- Check fails → system shows the reason and offers a smaller amount.
Functional requirements
- FR-3.1.1 The system shall accept amounts in multiples of 500 Tk between 500 and 20,000 Tk.
- FR-3.1.2 The system shall reject a withdrawal larger than the available balance and display “Insufficient funds”.
- FR-3.1.3 The system shall reject a withdrawal that would exceed the daily limit of 50,000 Tk.
- FR-3.1.4 The system shall debit the account only after the cash has been taken.
IEEE SRS template
3. System features: one feature in detail (cont.)
Include how the product responds to errors and invalid input: that is where most real defects hide.
IEEE SRS template
4. External interfaces and 5. non-functional requirements
| Interface | ATM example |
|---|---|
| User | 15" touch screen, keypad, audio jack; every screen has Cancel; error messages in Bangla and English |
| Hardware | card reader, cash dispenser, receipt printer, camera |
| Software | bank core system API v2; logs to the bank’s monitoring server |
| Communications | TLS 1.3 over the bank’s private network; message format ISO 8583 |
| Type | Measurable NFR |
|---|---|
| Performance | Balance shown within 2 s for 95% of requests |
| Safety | If power fails mid-transaction, no account is debited without cash being dispensed |
| Security | Card blocked after 3 wrong PINs; PIN never stored or logged in clear text |
| Availability | 99.5% per month, excluding a 2-hour weekly maintenance window |
| Usability | 90% of first-time users complete a withdrawal without help |
Concept 13 of 15
Prioritising requirements
Not everything can be built first. Two common methods:
| MoSCoW | Meaning |
|---|---|
| Must have | the release fails without it |
| Should have | important, but a workaround exists |
| Could have | nice if time allows |
| Won’t have (this time) | agreed to leave out |
The template also allows rating each feature on a 1–9 scale for benefit, penalty (of leaving it out), cost and risk, then ranking by value.
Priorities and traceability
Traceability
Give every requirement an ID and follow it through the project. A traceability matrix shows where each requirement is designed and tested — and exposes gaps.
| Requirement | Use case (topic 6) | Design (topics 5, 7, 8) | Screen (topic 9) | Test case |
|---|---|---|---|---|
| FR-3.1.1 amounts in multiples of 500 | UC-02 Withdraw cash | DFD 2.0; Account.withdraw() | S-04 Amount | TC-07, TC-08 |
| FR-3.1.2 insufficient funds | UC-02 (alternative flow) | sequence diagram, alt fragment | S-05 Error | TC-09 |
| NFR-SEC-1 block after 3 PINs | UC-01 Authenticate | Card.block() | S-02 PIN | TC-03 |
| FR-5.1 print statement | UC-04 Mini statement | — | — | — |
The last row has no design, screen or test yet: the matrix makes that visible before the deadline does.
Concept 15 of 15
Open-ended SRS: writing one for your own project
- List the stakeholders and interview at least two real users.
- Name the user classes; for each, list what they need to do (these become features).
- For each feature write the description, priority, stimulus/response and numbered FRs, including error cases.
- Write measurable NFRs for at least performance, security, usability and availability.
- Describe the interfaces and constraints.
- Review: run each requirement through the quality checklist and the requirement checker earlier in this topic.
- Get the SRS approved and freeze it; later changes go through a change log.
Worked example 1 of 3
Worked example 1
Show the solution
Worked example 2 of 3
Worked example 2
Show the solution
Worked example 3 of 3
Worked example 3
Show the solution
Practice
Practice (1 of 2)
Try each one on paper first, then check your answer.
Show the answer
Show the answer
Show the answer
Practice
Practice (2 of 2)
Try each one on paper first, then check your answer.
Show the answer
Show the answer
Show the answer
Check yourself
Quiz
Resources
Further learning
Hand-picked material to go deeper. Links open in a new tab.
Resources
Further learning (cont.)
Summary
Summary
- An SRS is the agreed list of what the system must do (FR) and how well or under what constraints (NFR).
- NFRs: product (usability, efficiency, reliability, portability), process and external (legal, ethical).
- Good requirements are correct, unambiguous, complete, consistent, ranked, verifiable, modifiable and traceable.
- Write “The system shall …”, one idea per sentence, with an ID and a number wherever quality is involved.
- IEEE sections: introduction, overall description, system features, external interfaces, NFRs, other.
- Prioritise (MoSCoW or 1–9 ratings) and trace each requirement to design and tests.