Transcript Chapter 6
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 domainrelated 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?