Gathering requirements and choosing a development approach: HSC Enterprise Computing Enterprise Project
“Apply tools to inform the requirements and limitations of an enterprise system, including interviews, surveys, analytical reports, prototypes and presentations of research results; explore and apply the most suitable development approach to develop, modify and implement an enterprise system, including waterfall (structured), agile, prototyping, end-user and outsourcing”
Interviews, surveys, analytical reports, prototypes and presentations of research results reveal a system's requirements and limitations. Waterfall suits stable requirements, agile suits changing needs, prototyping clarifies unclear requirements, end-user development suits simple systems built by users, and outsourcing brings external expertise at higher cost and less control. Choose based on clarity of requirements, complexity, skills, budget and risk.
Jump to a section
What this dot point is asking
Before building, you must find out what the system needs to do and what limits it faces. Then you choose how to build it. NESA names five tools for requirements and five development approaches. You need to apply them to scenarios and to your own project.
The answer
Tools to inform requirements and limitations
| Tool | Best for | Limitations |
|---|---|---|
| Interviews | Deep understanding from the client and key users, follow-up questions | Time-consuming, small number of views, can be influenced by the interviewer |
| Surveys | Views from many users quickly, easy to summarise | Shallow answers, low response rates, poorly worded questions |
| Analytical reports | Analysing existing data, systems and processes (usage statistics, error logs, current workflow) to find problems and constraints | Only shows what current data captures |
| Prototypes | Letting users try a model to clarify what they really want and uncover usability issues | Users may mistake a prototype for a finished product |
| Presentations of research results | Sharing findings with the client to confirm requirements and get sign-off | Needs clear communication to a non-technical audience |
Requirements include functional requirements (what the system does) and non-functional requirements (performance, security, usability, accessibility). Limitations include budget, time, skills, hardware, legal requirements and existing systems.
Development approaches
- Waterfall (structured): sequential stages, each completed and documented before the next. Predictable and well documented; inflexible and risky if requirements change, because users see the result late.
- Agile: short iterations delivering working features, with continuous client involvement and adaptation. Flexible and responsive; needs committed clients and can make budgets and timelines less predictable.
- Prototyping: build models of the system (throwaway prototypes to clarify requirements, or evolutionary prototypes refined into the final system). Excellent for unclear requirements and user interfaces.
- End-user: the users build it themselves with spreadsheets, databases or no-code tools. Cheap, fast and well matched to needs; limited in scale, security and documentation.
- Outsourcing: an external developer or product provides the system. Access to expertise and support; higher cost, less control and dependence on the provider.
Ask: How clear and stable are the requirements? How big and complex is the system? What skills, time and budget are available? How involved can users be? What are the risks if it fails?
A student's enterprise project: an event ticketing system for the school formal.
- Requirements tools: interview the formal committee; survey Year 12 students on how they want to pay and receive tickets; analyse last year's paper ticket records (analytical report); build a clickable prototype; present results to the committee for sign-off.
- Findings: students want phone tickets with QR codes; the committee needs a guest list and dietary requirements report; limitation: no budget for paid software.
- Approach: agile with prototyping. Iteration 1 is the ticket order form, iteration 2 the QR codes and check-in, iteration 3 reports. Each is reviewed by the committee.
- Recommending agile for everything
- Waterfall suits stable, well-defined or highly regulated projects.
- Confusing prototyping with testing
- Prototypes help discover requirements and designs; testing checks the built system.
- Ignoring limitations
- Requirements gathering must also identify constraints.
Practice questions
Original practice questions graded from foundation to exam level, each with a full worked solution. Try them before revealing the solution.
foundation3 marksA gym wants a new class booking app. Recommend one tool for gathering requirements from the gym manager and one from its 800 members, and justify each.Show worked solution →
Manager: an interview. The manager has detailed knowledge of current problems and business rules; an interview allows follow-up questions and discussion.
Members: an online survey. It reaches hundreds of members quickly and produces data that can be summarised (for example, 70% want to book from their phone).
Marking guide: 1 mark per suitable tool, 1 mark for justification of at least one choice (with the other justified for full marks).
core4 marksCompare the waterfall and agile development approaches.Show worked solution →
- Similarities
- both cover defining requirements, designing, building, testing and implementing.
- Differences
- waterfall is sequential, with each stage completed and documented before the next, so requirements are fixed early and the client sees the finished system near the end. Agile works in short iterations that each produce working features, with the client involved throughout and requirements allowed to change.
- Suitability
- waterfall suits projects with clear, stable requirements and strict documentation needs (a payroll system required by law). Agile suits projects where needs are uncertain or will evolve (a new customer app).
Marking guide: 1 mark for a similarity, 2 marks for differences, 1 mark for suitability.
exam6 marksA small regional council wants a system for residents to report potholes and broken streetlights. It has no in-house developers and a limited budget. Evaluate prototyping, end-user development and outsourcing as approaches, and recommend the most suitable.Show worked solution →
- Prototyping
- Building quick mock-ups of the reporting form and map lets residents and staff try the design before full development, clarifying requirements and reducing costly changes. But the council still needs someone with the skills to build the prototype and the final system.
- End-user development
- Council staff could build a simple solution with no-code tools (an online form feeding a spreadsheet and map). It is cheap and fast and staff understand the needs, but it may lack security, scalability, integration with works systems and documentation, and depends on a few staff members.
- Outsourcing
- A specialist company (or an existing software-as-a-service product for councils) brings expertise, testing and support, and could deliver a robust mobile-friendly system. It costs more, and the council must specify requirements carefully and manage the contract, data ownership and privacy.
- Recommendation
- Outsource, preferably by adopting an existing configurable reporting service, and use prototyping during configuration to test the forms and map with residents. This fits the lack of in-house developers while keeping costs lower than fully custom development and ensuring reliability and security.
Marking guide: 1 mark each for evaluating prototyping, end-user and outsourcing (3 marks), 2 marks for linking to the council's constraints, 1 mark for a justified recommendation.