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 elixira 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 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 producesthe 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:
The generic model describes deliverables and procedures for producing them. You decide how to use them. |