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: a list of what the system will do (in scope) and what it will not do (out of scope). Being explicit about what is out of scope is just as important as listing what is in scope. Without a clear boundary, projects suffer from scope creep — new features keep being added, budgets overrun, and deadlines are missed.

Boundaries describe the system's interfaces with the world around it:

• Input boundaries — what data enters the system and from where? (e.g. a user types a search query; a barcode scanner sends a product ID)
• Output boundaries — what does the system produce? (e.g. search results displayed on screen; a confirmation email sent to the user)
• User boundaries — who interacts with the system? (e.g. pupils, librarians, administrators)
• System boundaries — which external systems, if any, does it connect to? (e.g. a payment gateway, a school management system)

Defining boundaries prevents misunderstandings. A librarian might assume the system will also manage overdue fines — but if that's out of scope, it needs to be written down clearly so there are no surprises when the finished software is delivered.

Functional requirements

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.

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