SQA Advanced Higher Computing Science

What analysis produces

Analysis is the first stage of development, and it happens before anything is designed. Its job is to decide what problem is being solved and what a solution has to do, so that design, implementation and testing all have something fixed to be checked against. The same analysis applies whether the solution is a program, a database or a website, and at Advanced Higher a project usually joins two or all three of these together.

A problem is first described by its purpose, a short statement of why the system exists and who it is for. The purpose is then broken down by asking three questions about the system.

Listing inputs, processes and outputs does not say how anything will be done. It says what the system has to handle, and a missing item at this stage is cheap to fix whereas the same omission found during testing means redesign.

The requirements specification

A requirements specification is the document that records the outcome of analysis. It is agreed with the client or end users before design starts, and later it is the standard that the finished solution is evaluated against. It contains several parts.

End-user requirements

End-user requirements describe what the people who will use the system need from it, in their own terms. They come from talking to users, from observing the current way of working and from user surveys. A requirement such as "staff must be able to find a member's record without knowing their member number" belongs here. These are not yet technical, and two users may disagree, so part of the analyst's work is deciding which requirements are worth meeting.

Scope, boundaries and constraints

These three say where the project starts and stops and what limits it.

• The scope is everything the solution will do. A scope statement might say that the loan system records loans and returns and produces overdue notices.
• The boundaries mark what is outside the scope, or the edges of the system where it meets other things. The loan system might not handle fines or payments, which stay with the finance office, and it might read the member list from another system without changing it.
• The constraints are limits on how the solution can be built, such as a fixed budget, a deadline, a required programming language, the hardware that will run it, or a legal duty such as protecting personal data.

Scope is easy to let grow, so writing the boundaries down is what allows a developer to refuse a late request or to price it as a separate piece of work.

Functional requirements

Functional requirements state exactly what the system must do, in a form that can be tested. Each one normally names an input, a process and an output, and is written precisely enough that someone could later check whether it was met.

The system must accept a member number and a book barcode and, if the member has fewer than five items on loan, record the loan and display the return date.

A statement like "the system should be easy to use" is not a functional requirement, because there is nothing in it that can be marked as passed or failed. It might instead become a usability aim that is evaluated later by asking users to perform given tasks.

Use case diagrams

A use case diagram is a UML diagram that shows, at a high level, who uses a system and what they can do with it. It does not show the order of steps or how anything is implemented. Because it fits on one page and uses few symbols it is useful for agreeing the scope with a client, and each use case can be turned into one or more functional requirements.

Parts of the diagram

• Actors are the people or other systems outside the system that interact with it. An actor is drawn as a stick figure (or a labelled box for another system) and is named by role, such as Librarian or Member, rather than by an individual's name. A single person can play more than one role, and several people can share one.
• Use cases are the things an actor wants to achieve, drawn as ovals and named with a verb phrase: Issue loan, Return book, Search catalogue.
• The system boundary is a rectangle drawn around the use cases, with the system's name at the top. Actors sit outside it, and use cases sit inside.
• Relationships are lines. An actor is joined to each use case they take part in by a plain line, called an association.

Relationships between use cases

Two labelled relationships between use cases are common. An arrow labelled <<include>> shows that one use case always uses another as part of it, so Issue loan includes Check member status, and the same included use case can be shared by several others. An arrow labelled <<extend>> shows an optional addition that happens only in some circumstances, such as Charge fine extending Return book for a late return.

Actors can also be related. If a Senior librarian can do everything a Librarian can and more, the Senior librarian is drawn with an inheritance arrow to Librarian, and the extra use cases are attached only to the Senior librarian.

Reading and drawing one

To draw a use case diagram for a problem, work through these steps.

1. List the people and external systems that interact with the system. Each becomes an actor.
2. For each actor, list what they need to achieve. Each goal becomes a use case with a verb-phrase name.
3. Draw the system boundary, place the use cases inside it and the actors outside.
4. Join each actor to their use cases.
5. Add include or extend relationships where one use case depends on or optionally adds to another.

A sample diagram described in words: a rectangle titled "Library loans" contains the ovals Issue loan, Return book, Search catalogue, Check member status and Charge fine. A Librarian actor is joined to Issue loan and Return book, and a Member actor is joined to Search catalogue. Issue loan has an include arrow to Check member status, and Charge fine has an extend arrow to Return book.

Each actor should be joined to at least one use case, and each use case should be reached by at least one actor or by an include or extend arrow. An actor with no lines, or an oval nobody starts, means the analysis is incomplete.

Turning analysis into a specification

Once the inputs, processes and outputs are listed and the use cases drawn, the requirements specification is assembled. A typical order is the purpose, the end-user requirements, the scope, boundaries and constraints, and then the functional requirements grouped by use case. Every later stage refers back to it: design shows how each functional requirement will be met, testing checks each one, and evaluation asks whether the finished solution is fit for purpose against the same list.