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

Software Specification: R&R Chapter 2 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

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

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 Purpose of Project Stakeholders Mandated Constraints Naming Conventions & Terminology Relevant Facts & Assumptions Scope of Product Business Data Model & Data Dictionary Scope of the Work Functional Reqmts Look & Feel Reqmts Usability & Humanity Reqmts Performance Reqmts Operational & Environ. Reqmts Maintainability & Support Reqmts Security Reqmts Cultural Reqmts Software Specification: R&R Chapter 2

Requirements Specification Template Table of Contents (cont’d) Legal Reqmts Open Issues Off-the-Shelf Solutions New Problems Tasks Migration to New Product Risks Costs User Documentation & Training Waiting Room (reqmts for future releases) Ideas for Solutions Software Specification: R&R Chapter 2

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

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