Star Life Cycle

Requirements
Dr. Ann Nosseir

Star Life Cycle (Evaluation-centered) Hix and Hartson, 1993.

by A.Nosseir by A.Nosseir

What is Requirement?
A requirement is something the product must do or a quality that the product must have Benyon et al. Designers collect information and the accuracy is obtained when users review these requirements

Requirements
Qualitative requirements: are concerned with the desired usability goal there should be user satisfaction. They can be subjective and not easy to measure or quantify

Quantitative requirements: may be expressed by in terms of specific performance measures i.e. usability metrics which could be completion time for specified task by specified set of users , the number of error and time spent using documentation. (p 103,104 Stone et.al.)

by A.Nosseir

by A.Nosseir

Example of a Metrics
Usability objective Over all usability Effectiveness Efficiency
% of goal achieved Time complete a task Relative efficiency compared with expert user Relative efficiency while learning to criterion Time spent on correct errors

Types
Functional requirements are what the system must do.
e.g. phone must be accessible while connected to the internet

satisfaction
Rating scale for satisfaction Rating scale for satisfaction with power features Rating scale for ease of learning Rating scale for error handling

Meets need of % of relevant trained users function used learnability Error tolerance
% of users who managed to learn % of errors corrected or reported by the system

Non-functional requirements are a quality the system must have.

e.g. the system must present and up market, business like image

by A.Nosseir

by A.Nosseir

Constrains and Trade-offs

Non-functional requirements refer to
Cost/ budget/timescales Technology available and its interoperability with other hardware and software The agenda of individual stakeholders Contradictory requirements Organizational policy

Constrains and Trade-offs cont.

Each trade off should be evaluated in terms of its impact on users ability to use the system efficiently

by A.Nosseir

by A.Nosseir

Prioritizing Requirements
MoSCoW
Must have Should have Could have Want to have but want not have time

Problems with Requirement Gathering

Not enough users/stakeholders involved -incomplete picture Lack of requirements management-changes are not tracked or efforts are not coordinated- inaccurate Communication problem Capturing relevant information could be difficult because the knowledge exists in various resources People who understand can be either busy or reluctant to change Organization policies Some stakeholders dont know what they want Economic and business environment changes (stone p111-112)

by A.Nosseir

by A.Nosseir

Requirements Specification
Will contain different types of requirements, including, but not limited to, the following: Requirements related to user characteristics. Requirements related to tasks and task characteristics. Requirements related to the various environmental factors. Usability requirements. Statements of constraints and trade-offs and any requirements negotiations.

Requirements Specification cont.

The focus is on what the system should provide, rather than how the system works. The requirements should be expressed in a clear and unambiguous language. This is for the client to review and the developer to use in the design process. (Benyon et.al)

by A.Nosseir

by A.Nosseir

Guidelines

Requirements Gathering
Interviews
unstructured
Scenarios

semi-structured structured

Observation

by A.Nosseir

by A.Nosseir

Scenarios
are stories about people undertaking activities in contexts using technologies. these stories are collected in the interview.

Scenarios
Scenarios can be short or long, abstract or detailed. The process of writing scenarios will help in understanding the users and their tasks. Scenarios are developed and refined over time and become more detailed during requirements gathering. Later in the UI design process, the scenarios and use cases created can be employed for evaluation and usability testing of the system being developed.

by A.Nosseir

by A.Nosseir

Types
Task scenarios Concrete use cases Essential use cases Use scenarios

A Task Scenario
Task scenarios are usually personalized and describe a specific instance and situation of use. They are very detailed and describe, step by step, the procedures that a user followed in order to get a task done, as well as the features and behavior of the system with which the user interacted while performing the task. Any problems and difficulties that the user may have had with the current system will also be included in the description.

by A.Nosseir

by A.Nosseir

Concrete Use Case

is similar to a task scenario in that it is also a detailed description of a task. However, the two differ in that concrete use cases, unlike task scenarios, are not personalized and so describe the use of a system at a slightly more generic level. For example, we would need to remove Emily Adams, Kuala Lumpur Airport, Malaysian, and Ringgit and talk about the currency exchange task in general terms. the interaction in the concrete use case is described in terms of the detailed features and behavior of the user interface (Constantine and Lockwood, 1999).

by A.Nosseir

by A.Nosseir

Essential Use Case

It describes a task at a high level of abstraction. It is a simple and general description of a task that contains no assumptions about the type of UI or technology to be used. It focuses more on what a user would like to do (the users intentions or purpose when using a computer system), and what the systems responsibilities need to be, than on how this will be achieved.

Figure 4.3 Concrete use case for obtaining foreign currency.by

A.Nosseir

by A.Nosseir

Use Scenario
It differs from a task scenario in that it describes the anticipated use of the computer system. Use scenarios are based on the specified requirements, and are used to envision what the future system will be like for the user.

Figure 4.4 Essential use case for currency conversion ATM. by

A.Nosseir

by A.Nosseir

The Purpose of Use Scenarios

is to enable the designer to anticipate the different ways in which the new user interface design may be used and the advantages it could have over the existing user interface or paper-based system. In particular, they help the designer to anticipate how the new design will be able to support the user more effectively in their tasks.

Use Scenarios

Figure 8.3 Use Scenarios for booking an appointment.

by A.Nosseir by A.Nosseir

Scenarios
Task scenarios and concrete use cases are used as part of requirements gathering for examining and modeling tasks. They will help you analyze the issues in a user centered way. Concrete use cases, essential use cases, and use scenarios are used in the design phase.

Documenting Scenarios
Can become very messy. PACT (People, Activities, Contexts, Technologies) is used to get a good description of the scenario

by A.Nosseir

by A.Nosseir