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

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

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

4. Map of the Volere Requirements Process

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

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

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

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

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

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

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

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

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

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

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

16. Software Specification: R&R Chapter 2
Requirement Shell
Software Specification: R&R Chapter 2

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

18. Quality Gateway Process
Software Specification: R&R Chapter 2

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

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

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

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

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