Chapter 6:

Thinking about requirements and describing them

Introduction

• Process of compromise between constraints and tradeoffs

• How to get them and typical problems

• End result: requirements specification

Usability Requirements Defined

• Focus on the users and not just technical specifications.

• Early work-based areas of focus (Bennett, 1984):– Learnability: ease of learning; time and

effort required to reach certain level of performance

– Throughput: ease of use; tasks accomplished by users; speed of task execution; errors made

– Flexibility: accommodation to changes in task and environment beyond original specifications

– Attitude: positive attitude engendered in users by the application

Usability Requirements Defined (cont’d)

• A newer approach to focus areas (Quesenbery, 2003):– Effective– Efficient– Engaging– Error tolerant– Easy to learn

• Consider all together; interdependent

• Focus on each dimension in balance

Usability Requirements Defined (cont’d)

• Qualitative: – Subjective and not always easy to

measure or quantify– Example: “The system should be easy to

use.”

• Quantitative:– Expressed in terms of specific

performance measures (usability metrics)– Examples: completion times, number of

errors on a task, and number of commands used.

Example: Laser bar code scanning system

• Possible usability requirements:– Learnable by cashiers with ≤ 1 hour

of training.– Relearning period of ≤ 10 min. after

not using for up to 1 year.– Feedback in less than 2 seconds.– Sensitivity to barcodes without

perfect scanner to barcode alignment.

Constraints / Trade-offs

• Examples:– Costs / budget / timescales– Technology available; interoperability

with other hardware and software– Agenda of individual stakeholders– Contradictory requirements– Organizational policies

• Evaluate each trade-off in terms of its impact on the users’ ability to use the system effectively.

• Document all constraints and trade-offs in requirements specifications and any negotiations or decisions made for dealing with them.

Problems with Requirements Gathering

• Not enough user/stakeholder involvement in the process.

• Lack of requirements management due to poor record keeping.

• Shared understanding between all involved groups.

• Capturing relevant application domain-related information existing in a variety of places.

• Cooperation from users and stakeholders.• Organizational and political factors may

influence the specifications.• Getting balanced views.• Change of stakeholders over the duration of

the design and development of the application.

Requirements Specifications

• Produced by analyzing info gathered from:– Stated requirements– Observations of users, task, and

environments

• Conclusions translated into precise and comprehensive requirements for the design of the system.

Requirements Specifications (cont’d)

• Tips:– Use language simply, consistently,

and concisely.– Use diagrams appropriately.– Supplement natural language with

other descriptions of requirements.– Specify requirements quantitatively.

• Errors in specifying requirements will result in errors in the design and the design will not meet the users’ needs.

• This document will reflect compromise.

What Next?

• Prototyping– Saves time, money, and headaches.– Ensure that you have interpreted

needs accurately.

• What is prototyping?– An experimental, rough, incomplete

design.– Used early to communicate and share

ideas with users and stakeholders.– Used later for exploring and

demonstrating.

Prototyping Methods

• Low-fidelity prototypes:– Generally paper based but can be

created in programs like Paint or PowerPoint

– Useful for requirements-gathering – Cheap, fast to produce, and easily

changed– Examples:

•Sketching•Screen mockups•Storyboards

Low-Fidelity Paper Prototype

Prototyping Methods (cont’d)

• High-fidelity prototyping– Provide a functional version of the system for

user to interact with– Advantages:

•Show complete functionality.•Show look, feel, layout, and behavior of final

product.•Fully interactive and can be used as a

marketing tool.– Disadvantages:

•Time consuming•Not as effective for requirements gathering

because not as easily changed during testing.•Look so finished and professional that users

are less willing to comment.

High-Fidelity Prototype

Questions?