Key vocabulary

Why analysis comes first

The first phase of the iterative development process is analysis. Its job is to make sure everyone — the client, the development team, and the end-users — agrees on exactly what the software is supposed to do before a single line of code is written. Skipping or rushing analysis is one of the most common causes of failed software projects: teams end up building the wrong thing, or building things that the client didn't actually need.

During analysis, the development team gathers information by interviewing stakeholders, observing current working practices, and studying any existing systems. They use this to produce a clear written record of requirements. Everything that comes later — design, implementation, testing — depends on getting this right.

Purpose

The purpose of a software system is a short, plain-English statement that answers two questions: what does this software do, and who is it for? A good purpose statement is specific enough to guide decisions throughout the project, but short enough to be understood by someone who isn't a developer.

Examples of well-written purpose statements:

• "The purpose of this system is to allow pupils to borrow and return books from the school library and to let librarians manage the catalogue."
• "The purpose of this app is to allow gym members to book exercise classes online and let staff view and manage all bookings."

Notice that each statement names the who (pupils, librarians, gym members, staff) and the what (borrow/return books, book classes, manage bookings). There is no mention of how the system will work internally — that comes later in the design phase.

Scope and boundaries

Once the purpose is agreed, the team defines the scope: what the project does cover. The scope lists the agreed features, functions, and deliverables that will be developed. For a school library system, searching the catalogue, recording loans, and producing overdue-loan warnings could all be in scope.

The boundaries are the project's explicit limits: what it does not cover. Boundary statements record exclusions such as "The system will not calculate or collect overdue fines" or "The system will not manage pupil attendance." Making these exclusions clear prevents assumptions and scope creep, where extra features are added beyond the agreed scope and cause budgets or deadlines to overrun.

During analysis, the team may also record the system's interfaces: which users or external systems interact with it and where data enters or leaves. Interfaces are useful supporting context, but they are not the definition of scope or boundaries. Inputs and outputs belong in the IPO analysis described below; a boundary is an exclusion or limit on the project.

Functional requirements and IPO

A functional requirement is a statement of something the system must be able to do. Every functional requirement is phrased the same way:

"The system must…"

Using "must" (not "should" or "might") signals that this is a definite requirement, not a wish list. Functional requirements describe what the system does — never how it does it. Describing the how is the job of the design phase.

One way to organise functional requirements is IPO: inputs, processes, and outputs. An input is data that enters the system, such as a pupil ID or a selected book. A process is what the system does with input data to produce a result, such as checking a borrowing limit, searching a catalogue, calculating a total, or recording a loan. The process is the action performed by the system; it is distinct from the input data and from the result produced. An output is information or another result produced by the system, such as search results, a warning message, a receipt, or an order summary.

For example, in a book search the title entered is an input, searching the catalogue for matching records is a process, and displaying the matching books is an output. A complete analysis checks all three categories so that the team knows what data is needed, what the software must do with it, and what result users should receive.

Examples of correctly phrased functional requirements for a school library system:

• ✓The system must allow pupils to search for books by title or author.
• ✓The system must prevent a pupil from borrowing more than 3 books at once.
• ✓The system must display a warning when a book has been on loan for more than 14 days.
• ✓The system must allow librarians to add new books to the catalogue.

These are specific, measurable, and describe behaviour — not technology. Compare them to statements that are not functional requirements:

• ✗"The system should be easy to use." — Too vague. It doesn't describe a specific behaviour.
• ✗"The project must be finished by June." — This is a deadline, not a system behaviour.
• ✗"The system should use a MySQL database." — This describes how, not what.

End-users and stakeholders

Different people have different needs from the same system. A stakeholder is anyone with an interest in the project — this includes end-users (the people who use the software daily), managers, clients who are paying for it, and sometimes even competitors. Part of the analysis phase is identifying all stakeholders and gathering their requirements.

Stakeholders can have conflicting requirements. For example, end-users might want a fast, simple interface, while managers want detailed audit logs of every action. The development team must resolve these conflicts during analysis, before design begins. Discovering a conflict after the system has been built is far more expensive to fix.

Worked examples

Task Set A — Core questions

Task Set B — Extension