1. Chapter 6: Thinking about requirements and describing them

2. Introduction Process of compromise between constraints and tradeoffs How to get them and typical problems End result: requirements specification

3. 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

4. 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

5. 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.

6. 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.

7. 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.

8. 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.

9. 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.

10. 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.

11. 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.

12. 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

13. Low-Fidelity Paper Prototype

14. 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.

15. High-Fidelity Prototype

16. Questions?