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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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