Requirements

After you gathered user needs and performed your first ideation sessions its time to determine scoop of your project. Gathering requirements is about what your intended interactive product should do to satisfy user needs and business requirements.

What

A (functional) requirement is a statement about an intended interactive product, what it should do and how it should perform to satisfy user needs and business requirements.

The distinction between functional and non functional requirements\ In software engineering a distinction is made between functional and non functional requirements.\ Functional requirements describe what a system should do, meaning literally what functionality a system should have to fulfill business requirements and user needs.\ Non functional requirements describe the constraints and (technical) specifications of a system that are necessary to make it operate properly. Non functional requirements describe how a system operates.

Use when

Your first aim as an interaction designer is to understand as much as possible about the user, their activities and the context of use, so you can develop a system that can support users in achieving their goals. Your second aim is to produce a set of stable requirements that form a sound basis to start designing.

Nonetheless requirements are not a set of rigid prescriptions. Establishing requirements is iterative activity. In practice, requirements evolve and develop as the stakeholders interact with designers and prototypes during the design process.

Why

Clear requirements prevent problems to occur after the delivery of a product. This cartoon below illustrates very well what can go wrong if requirements are not clearly articulated.

Source: 'Interaction Design, Beyond human - computer interaction', Yvonne Rogers & Jenny Preece 2015.

How

Requirements, that refer to specific functions of the application you intend to design, should be specific, unambiguous and as clear as possible.

How to formulate functional requirements:

  • Be positive: Not ‘the system will not allow the user to purchase a kite without kite string’, but ‘the system will direct the user to the kite string page if the user tries to buy a kite without string’
  • Be specific: ‘The site will be accessible to disabled people’ is unclear. ‘The site will comply with section 508 of the rehabilitation act’ is better. ‘The act’ is a clear statement about the rules concerning accessibility.
  • Avoid subjective language: ‘The site will have a hip, flashy style’ is vague. ‘The look of the site will conform to the company branding guidelines document’ refers to the official style guide of the company you are designing for.

Source: 'The Elements of User Experience' , Jessie James Garett 2010

Prioritize your requirements with the “Moscow” method

  • Must have > without these requirements the system is worthless
  • Should have > essential if sufficient time is available
  • Could have > less important, can be left out
  • Want to/Won’t have > can wait till an update of the system

Use the user story table (week 2 userneeds) to establish an connection between userneeds and business goals (I Want) an requirements (required)

Examples

Functional requirements

Functional requirements describe what a system should do.

“The system provides a way to search people by their last name”

Non functional requirements

Non functional requirements describe how a system operates.

  • Efficiency and speed: "The system should carry out a search in 1 sec."
  • Visual design: "The visual style of the system should match all qualifications described in the official style guide"
  • Effectiveness and accuracy: "The system allows 120 people working simultaneously with the cms" "The system allows only people who are logged in to submit content"
  • Implementation in an organisation: "The system should be maintained by a team with the following qualifications"
  • Technical: "The system should run on Firefox, Safari and Chrome"
  • Content: "All news items should expire after two days"

Assignment

The Concrete Scenario and Use Case Descriptions have already inspired some of the first requirements. Look at your user story table and see which user stories fit with these requirements. Then check which user stories are not yet concretized in requirements and add requirements to those user stories as well.
You can do this by adding a column to your user story table to register the requirements.

Be aware: 1 user story might need more than 1 requirement, and also 1 requirement might fulfill multiple user stories.

The requirements inspired by you Concrete Scenario and Use Case Descriptions are prioroty since they are connected to your value proposition. But not all the requirements that are connecter to the User Stories are crucial for your system. Therefore, it is relevant to prioritize the requirements to your User Stories my using the MosCow method.

Therefore, add another column to your User Story Table to prioritize your requirements using the MosCow method.

After these steps, check the user story list. Add and/or adjust stories if necessary.

Tutorials and Talks

Further Reading

Must read before class: 'Interaction Design, Beyond human - computer interaction', Yvonne Rogers & Jenny Preece 2015: Page 350 - 386

Must read before class: Goodman: Page 299 - 307

Must read before class: 'Designing Interactive Systems', David R. Benyon 2013: Page 147 - 150

Additional knowledge : http://www.usability.gov/how-to-and-tools/methods/requirements.html