Establishing Requirements

Establishing Requirements

1. An interaction design project may aim to replace or update an established system, or it may aim to develop a totally innovative product with no obvious precedent

   • This requires an understanding of, among other things, the users and their capabilities, their current tasks and goals, the conditions under which the product will be used, and constraints on the product's performance.

2. What Are We Trying to Achieve

   • To understand as much as possible about the users, their activities, and the context of that activity , so the system under development can support them in achieving their goals
   • To produce a set of stable requirements that form a sound basis to start designing
     • How
       • First gather some data, then analyze and interpret it, and then extract some requirements from it
         • Why
           • The significant cost of fixing errors late in the software development cycle rather than early , during the requirements activity
         • The purpose is to collect sufficient, relevant, and appropriate data so that a set of stable requirements can be produced
           • Even if a set of initial requirements exists, data gathering will be required to expand, clarify , and confirm those initial requirements
         • Forms
           • Interviews, questionnaires, direct/indirect observation, studying documentation, and researching similar products

3. A requirement is a statement about an intended product that specifies what it should do or how it should perform

   • They come in many different forms and at many different levels of abstraction, but we need to make sure that the requirements are as clear as possible and that we understand how to tell when they have been fulfilled
     • Functional Requirements
       • what the system should do
     • Non-functional requirements
       • what constraints there are on the system and its development

4. Contextual Inquiry

   • Popular technique for uncovering requirements

5. Task Description

   • Scenarios
     • It describes human activities or tasks in a story that allows exploration and discussion of contexts, needs, and requirements
   • Use Cases
     • The emphasis here is on a user–system interaction
   • Essential Use Cases
     • Represent abstractions from scenarios, a more general case than a scenario embodies, and try to avoid the assumptions of a traditional use case
       • Name that expresses the overall user intention
       • Stepped description of user actions
       • Stepped description of system responsibilities