REVISION AND PRACTICE
Week 2 quick revision
| Topic | Lecture summary |
|---|---|
| Importance of requirements | Developers understand what customers want; customers agree the developers’ understanding matches their expectations. |
| Stakeholders | Users from your own organisation, other organisations or end users, with different roles and profiles, influenced by the software. |
| Primary users | Frequent users of the system. |
| Secondary users | Do not directly use the system; use it through an intermediary. |
| Tertiary users | Do not use the software at all, but are affected by its introduction or influence the purchase. |
| Analysis problems | Ambiguous / inconsistent / incomplete requirements. |
| 5 gathering techniques | Questionnaires: answering specific questions; Interviews: exploring issues; Focus groups and workshops: collecting multiple viewpoints; Naturalistic observations: understanding context; Documentation: procedures, regulations, standards. |
| Functional vs non-functional | What the system should do (f: I → O) vs how the system should behave. |
| Reliability | Reliability is the extent to which a program behaves the same way over time in the same operating environment. |
| Robustness | Robustness is the extent to which a program can recover from errors or unexpected input. |
| SRS | System analyst organises user requirements into a structured Software Requirements Specification document. |
| SRS advantages and drawback | Agreement between customers and developers; reduces future reworks; basis for estimating costs and schedules; facilitates future extensions. Drawback: a lot of documentation is required; fine if requirements are fixed. |
| BDD | Behaviour Driven Design: ask about behaviour before and during development; continuously refine requirements through user stories. |
| User story | Short, informal, plain-language description of something of value to a user; 3×5 index cards; one sprint. The role-feature-benefit pattern: As a [type of user], I want [an action], so that [a benefit/value]. |
| SMART | Specific: Know exactly what to implement; Measurable: Each story is testable: known expected results for some inputs; Achievable: Ideally implementable in one agile iteration (1–2 weeks), otherwise subdivide; Relevant: Business value to one or more stakeholders; Timeboxed: Stop implementing a feature once the time budget is exceeded |
| User story drawbacks | 1. Continuous contact with customers may be difficult or too expensive — customers may not want to participate or may not be available at all times. 2. May not scale to very large projects or safety-critical applications — these need extensive planning and documentation before implementation, and safety-critical applications have no room for errors or refinement. |