Requirements elicitation and specification

What this guide covers

This guide provides a general introduction to, and overview of, how to elicit, specify and prioritise requirements for the coursework.

Read the coursework specification to identify what you must produce, and what is optional.

The contents of this guide are:

What is a requirement?

A requirement is some capability needed by a stakeholder to solve a particular problem or achieve an objective. The requirements define a capability that the solution (web app) you will design and deliver has to have for it to be considered by the stakeholders as meeting their needs.

In the context of the coursework project, the stakeholders are the imagined people who will be using the web app.

Requirements are often discussed in two broad categories:

  1. Functional requirements are those that specify what the system should do; that is a behaviour, feature or function of a system. For example:

    • "Create a new customer account"

  2. Non-functional requirements are those that specify how the system should. These often have implications for the system architecture and sometimes sub categorised by performance, availability, reliability, usability, flexibility, configurability, integration, maintainability, portability, and testability. For example:

    • "The application must support devices running OS verions 3.4, 3.5 and 3.6"
    • "The error rate of users submitting their payment details at the checkout page must not exceed 10%."

1. Consider what you already know

By this stage of your coursework project you will have some understanding of what the project, or product, is about. You may have one or more of:

For example, you may be able to identify groups of functionality that the system should achieve from the product vision or goals.

The questions to be answered using the dataset may help to guide the requirements for visualisations in a dashboard.

The persona might inform the requirements if there is information on current frustrations or goals. Its main use in requirements is likely to be in trying to consider from the persona's perspective what the web app needs to do.

The persona may represent the main user base of your application, yet consider if there are others who will use the app as they may have different needs.

While not essential, a context diagram may be useful as a next step as can help you to consider:

2. Gather (elicit) requirements

The Business Analysis Body of Knowledge (BABOK) lists numerous techniques that can be used in a real world project to elicit requirements. You would gather requirements (user stories) by talking to the real users of an intended application, using one or more of these techniques:

In this course, since there are no users for you to talk to, and you are not allowed to involve others outside the course, then your options will be limited.

Useful techniques for the coursework include brainstorming, low fidelity prototyping (e.g. wireframes), looking at similar existing web apps.

IMPORTANT: Do not involve anyone outside this course in the requirements' elicitation. You must not carry out questionnaires, surveys, interview etc. even if they are anonymous. This would require ethics approval which is not possible to gain in the timescales of the course.

Whichever technique(s) you choose, use the persona to help you try and consider from the user's perspective what the web application need to be able to (functionality) and how it needs to be/perform (non-functional).

3. Specify (document) the requirements

Select a structure to formally record the requirements and apply it. The two options likely to be of most use for this course are:

Consider if there is a format that better suite the nature of your project/product. For example, User Stories would be expected if you are following an overall Agile approach to the project.

User story format

Most agile methods use the user story format.

The basic user story template is:

As a _role_, I want _goal_ so that _benefit_.

Acceptance criteria, or tests, are often added to the user story to clarify the definition. This is one way of adding non-functional requirements (or 'constraints') to user stories.

For example:

As a website user, I want search functionality to be available on all pages so that I can search for books using keywords.

Acceptance criteria:

  1. Search box should accept alphanumeric values
  2. Search results should display 10 items per page
  3. System responds to all search requests within 2 seconds of receiving the request

User stories are not typically classified as functional/non-functional. In some cases the non-functional requirements may be covered by the acceptance criteria; other times you will see user stories written for the non-functional needs such as:

"As a customer, I want to be able to run your product on all versions of Windows from Windows 95 on."

Functional and non-functional requirements using natural language

Natural language specification

Each requirement should focus on a single distinct feature or behaviour and should be written in the same uniform sentence structure. They should not be too vague or abstract; too general or imprecise; or include implementation information. e.g. “32 The ATM system shall validate the pin number”

You will typically see these listed in a table format, and they may be grouped in some way e.g.

Functional requirements

Non functional requirements

4. Prioritise the documented requirements

Once you have your initial list of documented requirements, decide how to prioritise them.

There are numerous techniques for prioritising techniques such as:

This guide covers MoSCoW since it is widely used, though other techniques may be more relevant for user stories such as forced pair.

MoSCoW prioritisation

The MoSCoW technique uses a simple categorisation for requirements:

Must have: These requirements that are absolutely critical to the product/project's success.

Should have: These requirements are also important, but may not be as time-sensitive or vital as the “must have” requirements.

Could have: These requirements are nice to have and would make a great addition to the project, but are not critical. If there’s time, consider adding these in.

Won't have for now: The value of these requirements is sufficiently low compared to the time, energy, or budget needed. They could be considered at a later time.

Consider each of your requirements and assign the most appropriate categorisation. Use your own judgement, there isn't a "correct" solution as to what the priorities are for the coursework!

Further information

There are materials the 'Further resources' section of week 5 on Moodle that you may wish to investigate. These include, but are not limited to:

Not covered in the course, however you could consider writing scenarios or user journeys. As with the persona, these are techniques drawn from interaction design/UX. They provide descriptions of how a user might interact with your product and might be a useful before trying to define detailed requirements or user stories.

There are links in the Reading list to requirements elicitation, specification and prioritisation; and UML resources.