Unit 1: Identify Requirements#

Identifying the Solution Requirements#

The solution requirements specify the capabilities that are critically required for the solution to effectively meet the needs of the users and deliver value.

At this stage of the investigation, it is important to note that we are identifying the requirements that have been asked of us, we are not identifying everything we want to do. These requirements might be explicitly listed under a requirements heading, or they may be implied throughout the criteria sheet and stimulus.

Solution requirements can generally be broken down into two different categories: functional requirements and non-functional requirements.

Functional requirements#

These are concerned with what the system needs to do.

These can include:

  • User interface criteria concerning:

    • Hardware or software that are required to be used.

    • The way that a user is to interact with the system.

    • The specific UI components that you might use.

  • Coded components presented as a list of specific code modules that need to be developed in order to:

    • Process user input

    • Calculate results using data

    • Store or display data

    • Also address the quality of the code:

      • Effective - can solve the identified problem

      • Efficient - uses minimal resources to solve identified problem

      • Maintainable - code that is easy to read and modify

      • Reliable - operate without producing errors or fail at a task

  • Data criteria concerning:

    • Specific datasets that must be considered or used

    • File formats to be used

    • Data structures to be implemented and created

    • Any potential requirements to clean the data (remove errors), restructure or filter existing data or methods that are to be used to collect new data

Non-functional requirements#

Non-functional requirements specify the manner or the environment in which a solution is intended to operate.

They are concern with such matters as:

  • Usability principles:

    • Accessibility: the ability to be used by many different people, even people with disabilities.

    • Effectiveness: the ability of users to use the system to do the work they need to do. Effectiveness includes reliability, which means the solution needs to be constant, dependable, consistent and repeatable.

    • Safety: the ability for users to make errors and recover from the mistake.

    • Utility: the ability of the system to provide all the functionality that users need.

    • Learnability: how easy the system is to learn

  • Performance: How quickly and efficiently the solution works and how it responds to commands and requests for action

  • Security: The level of protection the system and its data are expected to have in place

  • Design: The visual elements expected from the solution

  • Documentation: The type and extent of written documentation expected or needed

  • Economic: The financial component of the project. Is there a budget? Can it have a running cost?

  • Legal: The legal frameworks that the project must work within. The most common are privacy and intellectual property laws.

Recording the Solution Requirements#

When you identify a solution requirements from the criteria sheet or documentation, record it in the mind map under the appropriate node.

requirements mind map

Note: it is possible, depending on the project, that some of the nodes could be empty.

Creating the Requirements Table#

Now that we have fully explored the problem and identified all the requirements, we need to prioritise them. Looking at the needs and wants and the mind map, take the identified requirements and add them to the table below.

Requirements Table

How to fill the table out:

  • Must: This column contains all the requirements that are explicitly expressed in the criteria sheet or stimulus material.

  • Should: This column contains requirements that you think are important. It might include functional and non-functional requirements not mentioned in the criteria sheet or stimulus (eg. the Usability Principle of Safety).

  • Could: This column is for really good ideas that you do not have the time, skills or resources to implement (eg. making it post on social media).

  • Won’t This column contains ideas that other might like, but you are not interested in. Don’t simply put the negative of a requirement (eg. if you have mentioned the Usability Principle of Effectiveness, don’t add “Won’t crash” to this column).