1. Prepared by Stephen M. Thebaut, Ph.D. University of Florida
Robertson & Robertson: Chapter 16, Communicating the Requirements Software Specification Lecture 33
Prepared by
Stephen M. Thebaut, Ph.D.
University of Florida

2. Software Specification: R&R Chapter 16
Formality Guide
Rabbit projects (small, short lifetime, close stakeholder participation, use conversation to elaborate requirements written on story cards) usually don’t write a formal specification, but you should consider how to communicate some of the attributes of the requirements.
Horse projects (medium longevity, more than a dozen stakeholders, often in different locations, the default) likely need written requirements. They should start with the requirements knowledge model. Make sure you know where and how these components are recorded.
Elephant projects (long duration, involving many stakeholders in distributed locations, and a large number of developers) build a complete specification and should use some kind of automated tool to contain it.
Software Specification: R&R Chapter 16

3. Turning Potential Requirements into Written Requirements
You discover the intention of the requirements when you are trawling and prototyping. We refer to these as potential requirements. The writing activity transforms the resulting ideas and half-formed thoughts into precise and testable requirements; we call these formalized potential requirements. Finally, the Quality Gateway tests the requirements before adding them to the requirements specification.
Software Specification: R&R Chapter 16

4. The Requirements Knowledge Model
The requirements knowledge model represents the information you discover during the requirements process. For convenience, we use a UML class diagram to model this information. Each of the classes (shown as rectangles) is a repository of information about the subject (the name of the class). The associations (lines) between the classes are relationships needed to make use of the information. The numbers attached to the classes correspond to the section numbers in the Volere Requirements Specification Template (see Appendix A).
Software Specification: R&R Chapter 16

5. Capturing Requirements in Written Form
Software Specification: R&R Chapter 16

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

7. Volere Shell in its Snow Card Form
The Volere shell in its snow card form. Each 8-inch by 5-inch card is used to record an atomic requirement. The requirements analyst completes each of the items as it is discovered, thereby building a complete, rigorous requirement.
Software Specification: R&R Chapter 16

8. Customer Satisfaction and Dissatisfaction Scales
The customer satisfaction and customer dissatisfaction scales measure the client’s concern about whether requirements are included in the final product. A high score on the satisfaction scale indicates that the client will be happy if a solution to the requirement is successfully delivered; a high score on the dissatisfaction scales indicates that the client will be very unhappy if a solution to the requirement is not included in the product.
Software Specification: R&R Chapter 16

9. A complete (atomic) functional requirement written on a snow card
A complete functional requirement written on a snow card.
Software Specification: R&R Chapter 16

10. A complete (atomic) non-functional requirement written on a snow card
A non-functional requirement; this one is a usability requirement.
Software Specification: R&R Chapter 16

11. Using a snow card as the container for a User Story
Software Specification: R&R Chapter 16

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

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

14. Assembling the Specification
Assembling the specification. The template provides a guide to the types of requirements, and explains how to describe each one. The attributes for each functional requirement and non-functional requirement are compiled using the snow card as a guide. You write the requirements one PUC at a time. You can think of the requirements specification as an assembly of completed snow cards.
Software Specification: R&R Chapter 16

15. Considering the specification as a whole
You have arrived at the point in the process where you want to consider the specification as a whole. The Quality Gateway has tested and accepted individual requirements, and added them to the specification. Now it is time to assess whether you have a complete specification. This review can be done iteratively—ideally for one product use case worth of requirements at a time.
Software Specification: R&R Chapter 17

16. Prepared by Stephen M. Thebaut, Ph.D. University of Florida
Robertson & Robertson: Chapter 16, Communicating the Requirements Software Specification Lecture 33
Prepared by
Stephen M. Thebaut, Ph.D.
University of Florida