Requirements, their six types and MoSCoW prioritisation

Requirements state what the product does or how well it does it

Intuition

If the team and the client picture different products, you only find out after building one. Requirements are the written statements that catch that gap early, when fixing it is cheap.

A requirement is a statement about an intended product that specifies what it is expected to do or how it will perform. Example for a smartwatch GPS app: the time to load a map is less than half a second. Requirements take different forms and levels of abstraction. In agile contexts the most prevalent is the user story: “As a role, I want behaviour so that benefit”. Example: as a traveller, I want to save my favourite airline for all my flights so that I will be able to collect air miles.

Requirements matter because this is where miscommunication occurs most commonly, and fixing errors in a later phase is very costly. They come from several sources (users, business, application of technology), may evolve as stakeholders interact with designs, and may be represented in different formats. Supplement them with supporting evidence so the reasoning behind each is clear.

Six types, each answering a different question

The running example is a product that helps a family plan a balanced diet from weekly grocery promotions, considering lifestyle, food preferences and allergies.

Type	Question	Meal planner example
Functional	What should the system do?	Generate a weekly meal plan from promotions, preferences and allergies
Data	What data is stored and how? Type, volatility, size, persistence, accuracy, value	Securely store dietary preferences, allergy information, family size
Environment	Where and how does it run? Physical, social, organisational, technical	Integrate with grocery store APIs weekly. Run on desktop and mobile with internet
User	Who are the users? Characteristics and system use	Easily filter out foods I am allergic to, to follow the plan safely
Usability	How easy is it to use?	Clear error messages for invalid data such as a non-numeric age
User experience	How does it make users feel?	Positive reinforcement such as badges and encouraging messages to improve adherence

Environment requirements (context of use) have four parts: physical (dusty, noisy, vibration, light, heat, humidity), social (collaboration and coordination, data sharing, distributed, synchronous or asynchronous, privacy), organisational (user support, communications structure, training) and technical (technologies it runs on or must be compatible with).

User requirements cover characteristics (background, language, educational background, preferences, personal circumstances, physical or mental disabilities) and system use. Novices need clear step-by-step guidance and constraint, experts need flexibility and access to advanced features, frequent users need shortcuts, and casual users need clear menu paths. Together these form a user profile.

Pitfall

The slides show a car-factory robot and a personal banking application as “irrelevant example” under functional and data requirements. They are there as contrast with the meal planner, not as material to learn. The slide also says usability and UX requirements come from the “Week 2” goals, which this site covers in Week 1.

MoSCoW sorts requirements when resources are limited

Design projects have limited resources, so requirements must be prioritised. MoSCoW has four levels.

Mechanism

• Must have: fundamental requirements, the minimum usable subset.
• Should have: essential if there is more time, and the system is still usable without it.
• Could have: can be left out of the current development.
• Want to have but will not have this time round: can wait until a later development.

Other models named: Kano model, relative weighting method, opportunity scoring, stack ranking, priority poker, cost of delay, and the 100 dollar test. The lecture lists them without explaining them, so the names are what you need.

Exam detail

Lecture 4 summary of types: functional is what it does, data is what it needs, environment is where and how it runs, user is what users need, usability is how easy it is to use, and user experience is how it makes users feel.

Recall

List the six requirement types and the four MoSCoW levels.

Functional, data, environment, user, usability, user experience. Must, should, could, will not this time (want to have).