ELEC5618 · Software Quality Engineering
Software Requirement Specification and Use Cases
Week 4 of University of Sydney ELEC5618 Software Quality Engineering builds a Software Requirements Specification (SRS) to the IEEE 830 structure — functional and non-functional requirements, product perspective and quality attributes — and models behaviour with use cases, activity diagrams and state diagrams. A good SRS is the baseline that later verification and validation check against, and this chapter feeds the individual SRS deliverable in the group project.
What this chapter covers
- 01Functional vs non-functional requirements: services for the user vs constraints (reliability, security, performance, usability, portability); requirements state WHAT not HOW
- 02The three SRS models: data model, functional/information-flow model, behavioural model
- 03IEEE 830 SRS structure: 1 Introduction · 2 Overall Description (product perspective, functions, users, constraints) · 3 Specific Requirements · 4 Supporting Information
- 04Characteristics of a good SRS: unambiguous, complete, verifiable, consistent, modifiable, traceable, usable
- 05Benefits of an SRS: baseline for V&V, basis for cost/schedule estimation, prevents mixing functional/non-functional requirements
- 06Use cases: an actor achieving a goal; template slots (goal, scope/level, pre-condition, success/failed end conditions, actors, trigger, steps)
- 07Use-case diagram relationships: association (actor–use case), «include» (always occurs), «extend» (sometimes occurs), generalization
- 08Activity diagrams (action, control flow, decision/merge, fork/join, guards) and state diagrams (Event[Guard]/Action)
Removing ambiguity from a non-functional requirement
- +1Diagnose the ambiguities: 'quickly' is not measurable (violates verifiable/unambiguous); 'their own reports' mixes an access-control rule with a performance idea and is vague; 'be secure' is untestable as written. One sentence also bundles several requirements together (violates modifiable/traceable).
- +1Split into atomic requirements. R1 (functional): 'A user shall be able to retrieve a report they own.' R2 (non-functional, performance): 'A report shall load within 2 seconds for 95% of requests under normal load.' (State the assumed threshold.)
- +1Continue: R3 (functional, access control): 'The system shall reject any request by a user to read a report they do not own, returning an authorization error.' R4 (non-functional, security): 'Report data shall be transmitted over an encrypted channel.'
- +1Map to IEEE 830 characteristics: each rewritten requirement is now unambiguous (measurable terms), verifiable (each has a testable condition), and traceable/modifiable (one requirement per statement, individually identifiable). State any assumption (e.g. the 2-second target) explicitly.
Key terms
- Functional requirement
- A statement of a service the system provides for the user — what the software does in response to inputs. Usually the bulk of an SRS.
- Non-functional requirement (NFR)
- A constraint on the software or the project rather than a service: reliability, security, performance, usability, availability, portability and so on. NFRs need measurable targets to be verifiable.
- IEEE 830 SRS
- The recommended-practice structure for a Software Requirements Specification: Introduction, Overall Description, Specific Requirements and Supporting Information. Its successor is ISO/IEC/IEEE 29148.
- Good-SRS characteristics
- An SRS should be unambiguous, complete, verifiable, consistent, modifiable, traceable and usable through operation and maintenance. These are the qualities V&V later checks the requirements against.
- Use case
- A description of how an actor (a role outside the system) uses the system to achieve a goal, written in natural language with template slots: goal, scope/level, pre-condition, success and failed end conditions, actors, trigger and steps.
- Include vs Extend
- In a use-case diagram, «include» means the sub use case always occurs during the base (arrow base → included); «extend» means it only sometimes occurs (arrow extending → base). Associations link an actor to a use case, never actor–actor or use-case–use-case.
Software Requirement Specification and Use Cases FAQ
What is the difference between functional and non-functional requirements?
Functional requirements describe services the system provides — what it does in response to inputs. Non-functional requirements are constraints on how well it does them — reliability, security, performance, usability, portability and so on. Requirements should say what, not how, and every non-functional requirement needs a measurable target so it can be verified.
What structure should an SRS follow?
The IEEE 830 recommended practice: Section 1 Introduction (purpose, scope, definitions, references, overview), Section 2 Overall Description (product perspective, product functions, user characteristics, constraints, assumptions), Section 3 Specific Requirements (external interfaces, functions, performance, quality attributes), and Section 4 Supporting Information. A good SRS is unambiguous, complete, verifiable, consistent, modifiable and traceable.
How do include and extend differ in a use-case diagram?
«include» means the included use case always runs as part of the base use case (you can't complete the base without it), drawn base → included. «extend» means the extending use case only sometimes runs — it adds optional behaviour — drawn extending → base. Associations connect an actor to a use case only; you never draw an association between two actors or between two use cases.
Can AI help me write a good SRS or use case?
Yes. Sia can critique a requirement against the IEEE 830 characteristics, help you split an ambiguous sentence into atomic verifiable requirements, and check a use-case template or an include/extend diagram for correctness. Use it to learn the structure; it does not complete graded deliverables, and the University of Sydney academic-integrity policy applies.
Exam move
Practise the two moves examiners test: writing testable requirements and structuring them correctly. Take vague sentences and rewrite them into atomic, measurable, verifiable requirements, labelling each functional or non-functional and naming the IEEE 830 characteristic you improved — this is a recurring short-answer and scenario task. Memorise the IEEE 830 section skeleton and the good-SRS characteristics as a checklist you can recite. For modelling, be able to draw a small use-case diagram with a correct association, one «include» and one «extend», and read an activity or state diagram (decision/merge, fork/join, guards; Event[Guard]/Action). Because this feeds the project's SRS deliverable, apply it to your own feature as you revise. Confirm assessment details on Canvas.
Working through Software Requirement Specification and Use Cases in ELEC5618? Sia is AskSia’s AI Software Engineering tutor — ask any ELEC5618 Software Requirement Specification and Use Cases question and get a clear, step-by-step explanation grounded in how ELEC5618 is taught and assessed. Read this chapter free, then take your hardest questions to Sia.
