10 ESTABLISHING REQUIREMENTS

10 ESTABLISHING REQUIREMENTS

1. Introduction

   • Given the iterative nature of interaction design, isolating requirements activities from design activities and from evaluation activities is a little artificial, since in practice they are all intertwined: some design will take place while requirements are being established, and the design will evolve through a series of evaluation– redesign cycles

2. What, How, and Why?

   • There are two aims. One aim is 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. Building on this, our second aim is to produce a set of stable requirements that form a sound basis to start designing.
   • Why ‘Establish’ Requirements
     • We chose the term establishing requirements to represent the fact that requirements have been established from a sound understanding of the users’ needs and that they can be justified by and related back to the data collected. Current concerns with crosscultural design have highlighted the importance of understanding who you are designing for, their specific circumstances, and how to enrich their lifestyles
   • 3 Why Bother? The Importance of Getting it Right
     • Much has been written about the significant cost of fixing errors late in the software development cycle rather than early , during the requirements activity . For example, Davis (1995) identifies insufficient user communication, poor specifications, and insufficient analysis as contributors to poor cost estimation. Boehm and Basili (2001) present a top ten list of software defect reduction findings, the first of which states that “finding and fixing a software problem after delivery is often 100 times more expensive than finding and fixing it during the requirements and design phase.”
   • How Can We Achieve This?
     • Establishing requirements is itself an iterative activity in which the subactivities inform and refine one another. It does not last for a set number of weeks or months and then finish. In practice, requirements evolve and develop as the stakeholders interact with designs and see what is possible and how certain facilities can help them

3. What Are Requirements

   • A requirement is a statement about an intended product that specifies what it should do or how it should perform. One of the aims of the requirements activity is to make the requirements as specific, unambiguous, and clear as possible.

4. PROJECT DRIVERS 1. The Purpose of the Product 2. The Stakeholders PROJECT CONSTRAINTS 3. Mandated Constraints 4. Naming Conventions and Definitions 5. Relevant Facts and Assumptions FUNCTIONAL REQUIREMENTS

   • 6. The Scope of the Work 7. Business Data Model and Data Dictionary 8. The Scope of the Product 9. Functional and Data Requirements NON-FUNCTIONAL REQUIREMENTS 10. Look and Feel Requirements 11. Usability and Humanity Requirements 12. Performance Requirements 13. Operational and Environmental Requirements
     • 14. Maintainability and Support Requirements 15. Security Requirements 16. Cultural and Political Requirements 17. Legal Requirements PROJECT ISSUES 18. Open Issues 19. Off-the-Shelf Solutions 20. New Problems 21. Tasks 22. Migration to the New Product 23. Risks 24. Costs 25. User Documentation and Training 26. Waiting Room 27. Ideas for Solutions

5. Data Gathering for Requirements

   • Indirect observation. Diaries and interaction logging are used less often within the requirements activity where a new product is under development. However, if a product is being developed iteratively or is evolving from an existing product, indirect observation and experience sampling are very valuable. Interaction logging together with sophisticated web analytics are particularly useful for improving websites.
   • The overall purpose of data gathering in the requirements activity is to collect sufficient, relevant, and appropriate data so that a set of stable requirements can be produced.