Gathering requirements
Requirements are what the system must do and the qualities it must have. The analyst gathers them from stakeholders: everyone the system affects. At the café: students, baristas, the manager and the university administration.
| Interviews | Deep detail from a few people, such as the café manager. |
| Questionnaires | Many opinions quickly, such as students'. |
| Observation | See real work with your own eyes, like the break-time queue. |
| Document analysis | Existing invoices, reports and procedures. |
| Workshops (JAD) | All parties agree requirements together. |
| Prototyping | Screens users try and comment on. |
Requirements come in two kinds:
Functional: what the system does, e.g. “a student can cancel an order before it's prepared”.
Non-functional: how well it does it, e.g. “the app opens within two seconds” or “card data is encrypted”.
Watch outA good requirement is measurable and testable: “the system is fast” is weak; “it shows the menu within two seconds” is clear and testable.