- Agility Guide
- Requirements Process in Context
- The Process
- A Case Study
- Trawling for Requirements
- Prototyping the Requirements
- Scenarios
- Writing the Requirements
- The Quality Gateway
- Reusing Requirements
- Reviewing the Specification
- Iterative and Incremental Processes
- Requirements Retrospective
- Your Own Requirements Process
- In Conclusion
This chapter is from the book
This chapter is from the book
This chapter is from the book
Your Own Requirements Process
The itinerant peddler of quack potions, Doctor Dulcamara, sings the praises of his elixir, which is guaranteed to cure toothache, make you potent, eliminate wrinkles and give you smooth beautiful skin, destroy mice and bugs, and make the object of your affections fall in love with you. The rather fanciful libretto from Donizetti's opera L'Elisir d'Amore points out something that, although very obvious, is often disregarded: There is no such thing as the universal cure.
We really would like to be able to present you with a requirements process that has all the attributes of Doctor Dulcamara's elixir—a process that suits all projects for all applications in all organizations. But we know from experience that every project has different needs. At the same time, we have learned that some fundamental principles hold good for any project. Thus, instead of attempting to provide you with a one-size-fits-all magic potion, we have distilled our experiences from a wide variety of projects to provide you with a set of foundation activities and deliverables that will apply to any project.
We are using a process here to describe the things that have to be done to successfully gather requirements, and the deliverables that are the foundation for any kind of requirements activity. As you read this book, think of adapting them to your own culture, your own environment, your own organizational structure, and your own chosen way of product development.
For instance, projects using eXtreme Programming are not supposed to produce a requirements specification, but there is still a clear need to understand the requirements. This understanding cannot be achieved effectively by writing code. To invest in writing an individual requirement, complete with its fit criterion, remains the fastest way of understanding that requirement. (Writing code is building a solution to satisfy the requirement, and it does not guarantee that the real requirement is ever discovered.) In the Volere Requirements Process, we provide scenarios as a way of modeling the functionality of the use case. This is almost always a quicker way to discover requirements, particularly when you start to consider the exceptions and alternatives for a use case. For a nonfunctional requirement, writing it down, complete with its fit criterion, remains the fastest way of understanding it.
Defining the scope of the business area affected by the product is still the most effective way of keeping the requirements and the development work focused. Learning about the work, and not just the product, is the best way of building a relevant product. Of course, we do not intend that you use the Volere process straight out of the box. Instead, we urge you to adopt the most beneficial practices, adapting the process as necessary to make it relevant to your project and your organization.
To adapt this process you need to understand each of the deliverables it produces—the rest of this book will discuss these in detail. Once you understand the content and purpose of each deliverable, ask how each one (provided it is relevant) would best be produced within your project environment using your resources:
- What is the deliverable called within your environment? Use the definitions of the terms used in the generic process model and identify the equivalent deliverable in your organization.
- Is this deliverable relevant for this project?
- How much do you already know about this deliverable? Do you know enough to be able to avoid devoting additional time to it?
- Who produces the deliverable? Understand which parts of the deliverable are produced by whom. Also, when several people are involved, you need to define the interfaces between them.
- When is the deliverable produced? Map your project phases to the generic process.
- Where is the deliverable produced? A generic deliverable is often the result of fragments that are produced in a number of geographical locations. Define the interfaces between the different locations and specify how they will work.
- Who needs to review the deliverable? Look for existing cultural checkpoints within your organization. Do you have recognized stages or phases in your projects when peers, users, or managers must review your specification?
The generic model describes deliverables and procedures for producing them. You decide how to use them.