Requirements

Learning Objectives

Understand what software requirements are
Understand the benefit of creating requirements
Be capable of creating effective requirements

Requirements

What are Requirements?

The IEEE Standard Glossary of Software Engineering Terminology defines a requirement as a condition or capability needed by a user to solve a problem or achieve an objective.

Why are Requirements important?

Requirements are hugely important as they form the basis of all your design decisions. By making requirements explicit and validating them with the project stakeholders, you can be confident that their business needs will be satisfied by the product you create.

How are Requirements gathered?

"Requirements are not just waiting to be picked from people like apples from a tree. They have to be mined like tin or iron" Developing Information Systems by James Cadle

Requirements are typically gathered by a Business Analyst through communication with project stakeholders. Communication can take a number of forms, for example:

Interviews
Focus groups
Workshops
Observations
Questionnaires

Functional vs Non-functional Requirements

Functional requirements describe how a system should work, for example:

ID	Priority	Description
FR1	MUST	Menu options include vegetarian, vegan and calorie controlled choices
FR2	MUST	Allergen information is displayed against each ingredient
FR3	MUST	The password reset email contains a unique link which expires after one hour
FR4	SHOULD	Payment options include ApplePay

Non-functional requirements describe the constraints on the system such as system availability, conformance to security standards etc. Some examples are listed below but take time to study a more complete list on Wikipedia

ID	Priority	Description
NFR1	MUST	The home page loads in less than 2 seconds
NFR2	MUST	The system supports up to 1000 concurrent users
NFR3	MUST	Data is held in a Postgres database

There is quite an art to form a good requirement. Below are the main qualities your requirement must have:

Unique and atomic (focusses on one thing)
Complete
Consistent and unambiguous
Traceable
Prioritised
Testable

Let's look at some examples of good and poor requirements in terms of how "complete" and "unambiguous" they are:

Poor	Good
The system must be useable	The system must conform to the Nielson Top 10 Usability Heuristics
The system must be well tested	All code must have 80% test coverage

Functional requirements can be expressed in a number of different forms including:

UML Use Case diagrams which show the interactions between the Actors and the system

UML Activity diagrams which show how activities are co-ordinated

Personas - we discussed these in the previous lesson. Personas are ficticious characters who represent the different types of actors that will use a product
User Stories - which describe a feature from the perspective of the end user

Assignment

In your groups, document a set of requirements (each labelled as functional or non-functional) based on your chosen opportunity.

Additional resources

Bernard explains Use Case diagrams