- The Requirements Process in Context
- A Case Study
- Project Blastoff
- Trawling for Requirements
- Quick and Dirty Modeling
- Scenarios
- Writing the Requirements
- Quality Gateway
- Reusing Requirements
- Reviewing the Requirements
- Iterative and Incremental Processes
- Requirements Retrospective
- Evolution of Requirements
- The Template
- The Snow Card
- Your Own Requirements Process
- Formality Guide
- The Rest of This Book
This chapter is from the book
This chapter is from the book
This chapter is from the book
The Template
It is easier to write requirements, and far more convenient, if you have a guide to writing them. Appendix A of this book provides The Volere Requirements Specification Template, which is a complete blueprint for describing your product’s functionality and capabilities. This template, which is a distillation of literally hundreds of requirements specifications, is in use by thousands of organizations all over the world.
It is convenient to categorize requirements into several types—each of the template’s sections describes a type of requirement and its variations. Thus, as you discover the requirements with your stakeholders, you add them to your specification, using the template as a guide to necessary content.
The template is designed to serve as a sophisticated checklist, providing you with a list of what to write about, and suggestions on how to write about them. The table of contents for the template is reproduced here, and we will discuss each section in detail later in the book.
The complete Volere Requirements Specification Template is found in Appendix A.
Our associate, Stephen Mellor, suggests using the template by going directly to the most pressing sections—the ones that seem to you to be most useful—and then revisiting the template as needed. You will probably use most of it, but it is not—really not—a template that you fill by starting on page one and working through to the bitter end. Like any good tool, when used wisely the template provides a significant advantage to your requirements discovery.
Here, then, is the content of the template.
Project Drivers—reasons and motivators for the project
- The Purpose of the Project—the reason for making the investment in building the product and the business advantage that you want to achieve by doing so
- The Client, the Customer, and Other Stakeholders—the people with an interest in or an influence on the product
- Users of the Product—the intended end users, and how they affect the product’s usability
Project Constraints—the restrictions on the project and the product
- Requirements Constraints—the limitations on the project, and the restrictions on the design of the product
- Naming Conventions and Definitions—the vocabulary of the project
- Relevant Facts and Assumptions—outside influences that make some difference to this product, or assumptions that the developers are making
Functional Requirements—the functionality of the product
- The Scope of the Work—the business area or domain under study
- The Scope of the Product—a definition of the intended product boundaries and the product’s connections to adjacent systems
- Functional and Data Requirements—the things the product must do and the data manipulated by the functions
Non-functional Requirements—the product’s qualities
- Look and Feel Requirements—the intended appearance
- Usability and Humanity Requirements—what the product has to be if it is to be successfully used by its intended audience
- Performance Requirements—how fast, big, accurate, safe, reliable, robust, scalable, and long-lasting, and what capacity
- Operational and Environmental Requirements—the product’s intended operating environment
- Maintainability and Support Requirements—how changeable the product must be and what support is needed
- Security Requirements—the security, confidentiality, and integrity of the product
- Cultural Requirements—human and sociological factors
- Legal Requirements—conformance to applicable laws
Project Issues—issues relevant to the project that builds the product
- Open Issues—as yet unresolved issues with a possible bearing on the success of the product
- Off-the-Shelf Solutions—ready-made components that might be used instead of building something from scratch
- New Problems—problems caused by the introduction of the new product
- Tasks—things to be done to bring the product into production
- Migration to the New Product—tasks to convert from existing systems
- Risks—the risks that the project is most likely to incur
- Costs—early estimates of the cost or effort needed to build the product
- User Documentation—the plan for building the user instructions and documentation
- Waiting Room—requirements that might be included in future releases of the product
- Ideas for Solutions—design ideas that we do not want to lose
Browse through the template in Appendix A before you go too much further in this book. You will find a lot of information about writing requirements, plus much food for thought about the kinds of requirements you are looking for.
Throughout this book, we will refer to requirements by their type—that is, one of the types as shown in the template’s table of contents.