Robertson Robertson Chapter 2 Software Specification Lecture 10

Robertson & Robertson: Chapter 2 Software Specification Lecture 10 Prepared by Stephen M. Thebaut, Ph. D. University of Florida

Volere Tour Visit www. volere. co. uk for a current overview of the Volere method Resources available include: – document templates – lists of books, articles, etc. – various “freeware” downloads – lists of services

The “Volere” Requirements Process A generic but detailed requirements gathering and specification process. Core set of activities based on an iterative process of Trawling, Writing, and Quality Gateway activities. Software Specification: R&R Chapter 2

Map of the Volere Requirements Process

Project Blastoff Get the astronauts on-board! A meeting to prepare for the project and ensure its feasibility. Principal stakeholders: client (sponsor), main users, lead developers, technical AND business experts, other key people. Software Specification: R&R Chapter 2

Blastoff Objectives Ensure that the project has a worthwhile (and clearly understood) purpose; Is feasible; and Has commitment from the stakeholders. Software Specification: R&R Chapter 2

Blastoff Tools/Activities Brainstorm to identify all the stakeholders. Develop Context Model to help determine the scope of work to be studied (the product will do part of this work). Produce a statement of purpose. Develop a preliminary cost estimate and assessment of risks. Arrive at a consensus based Go/No-Go decision. Software Specification: R&R Chapter 2

Trawling For Knowledge/Requirements Work that needs to be studied (from context model) is divided into business use cases and assigned to analysts. Favored techniques are apprenticing and use-case workshops. Focus is on working with users as they describe work they do now and work they hope to do. As context knowledge grows, focus of trawling shifts towards gathering requirements for the product. Software Specification: R&R Chapter 2

What is the “essence” of the system? “Perhaps the most difficult part of requirements investigation is uncovering the essence of the system…the underlying business reason for having the product. ’’ Software Specification: R&R Chapter 2

Other Trawling Techniques Interviews with non-user stakeholders. Brainstorming sessions to generate ideas for particular aspects of the product. Surveys of (other) potential users. Scenarios of work activities are developed to understand context and product roles. Quick and Dirty Modeling (e. g. , using Post-it notes to model functionality, paper or white-board based prototypes) Software Specification: R&R Chapter 2

Scenarios User-led stories constructed to show steps needed to complete some piece of work in the current environment. – Facilitates context understanding. Stories showing role of product in completing some piece of work in the envisioned environment. – Facilitates product requirements understanding. Software Specification: R&R Chapter 2

Writing the Requirements Written for the client, using the client’s language, in a consistent format. A “fit criterion” is also provided to quantify the requirement for designers and to ensure testability. Tools: Requirements Specification Template (ala IEEE Guideline) and Shells (template for individual requirements) Software Specification: R&R Chapter 2

Capturing Requirements in Written Form Software Specification: R&R Chapter 2

Requirements Specification Template Table of Contents 1. Purpose of Project 9. Functional Reqmts 2. Stakeholders 10. Look & Feel Reqmts 3. Mandated Constraints 4. Naming Conventions & Terminology 5. Relevant Facts & Assumptions 11. Usability & Humanity Reqmts 12. Performance Reqmts 13. Operational & Environ. Reqmts 7. Business Data Model & Data 14. Maintainability & Dictionary Support Reqmts 8. Scope of the Work 15. Security Reqmts 6. Scope of Product 16. Cultural Reqmts Software Specification: R&R Chapter 2

Requirements Specification Template Table of Contents (cont’d) 17. Legal Reqmts 23. Risks 18. Open Issues 24. Costs 19. Off-the-Shelf Solutions 25. User Documentation & Training 20. New Problems 26. Waiting Room (reqmts for future releases) 21. Tasks 22. Migration to New Product 27. Ideas for Solutions Software Specification: R&R Chapter 2

Requirement Shell Software Specification: R&R Chapter 2

Quality Gateway (Initial Review Process) Every requirement must pass through to become part of the specification. An analyst and senior user serve as gate keepers. Every requirement is checked for completeness, relevance, coherency, traceability, etc. Prevents requirements leakage. (What is that? ) Software Specification: R&R Chapter 2

Quality Gateway Process Software Specification: R&R Chapter 2

Other Important Ideas Reusing requirements from similar products. Specification “Stock-take”: a final review for consistency and completeness, and an opportunity to reassess costs and risks. Iterative and Incremental processes – doing requirements does not mean you must employ a traditional waterfall process. (cont’d) Software Specification: R&R Chapter 2

Other Important Ideas (cont’d) Requirements evolve as development of the product progresses. Tailoring the process: every project needs a different process… Requirements Retrospectives (Post Mortems)… Software Specification: R&R Chapter 2

Requirements Retrospective Series of interviews with stakeholders, developers, and all others involved in the requirements process. Questions: – What did we do right? – What did we do wrong? – How would we do it differently? (cont’d) Software Specification: R&R Chapter 2

Retrospectives (cont’d) “The most notable feature of retrospectives is this: Companies that…make (them) part of their process consistently report significant improvement in their (RE) process. (They) are probably the cheapest investment you can make in your own process. ” Software Specification: R&R Chapter 2

Robertson & Robertson: Chapter 2 Software Specification Lecture 10 Prepared by Stephen M. Thebaut, Ph. D. University of Florida