8. The Scope of the Product
For each of these items, look at the guidance in the template for a description of what you need to determine. Then ask:
- What knowledge do I have about this item?
- Where is this knowledge and what form is it in?
- Who can help me with this item?
Record your answers separately for each section. In some cases, especially for 7 — Scope of the work and 8 — Scope of the product, it might be useful to sketch some kind of model. There are also models that help determine the stakeholders (anyone who has an interest in the product, and therefore has requirements for it). Also, there is an article about Stakeholders, Goals and Scope that will give you some guidance on capturing this knowledge.
4. Go or NoGo?
Review what you have recorded about each of the eight sections. Is your knowledge of that item is sufficient for you to be able to start working on the detailed requirements?
- Is the purpose of the project defined by measurable goals?
- Do I know who all the stakeholders are?
- Are the stakeholders prepared to participate in the project?
- Do I know the scope of your investigation?
- Do I know the ambitions for the scope of product to be built?
If you have items that are vague or ambiguous (or just plain vacuous), then it is a signal that you need to spend more time on the first 8 items on the list before starting to discover detailed requirements. Keep in mind that nothing that follows can be good unless this part of the specification forms a solid foundation.
We call this process a project blastoff Ð you are checking that everything is in place and ready before launching the detailed requirements discovery.
5. Identify Events and Use Cases
When you have decided that your blastoff knowledge is sufficient to proceed with detailed requirements work, the next task is partitioning the investigation. The work context in section 7 defines the scope of your study. Each of the input and output flows potentially represents a business event. Make an event list that summarises each of your business events: the event name, the input and the outputs, and a summary of the business use case that will respond to the event.
Keep in mind when you are doing this that the business events happen outside the scope when the adjacent system wants the work to do something, or when it is time for the work to do something for an adjacent system. The reason for taking this view is to see the work as your customers see it.
The business use case is the processing and accessing of stored data that the work does in response to the business event. Later, when you are more familiar with the work, you decide the product use cases.
This summarises the connections between the product use cases, business use cases and business events.
5. Choose a Key Event
There will be a business event, sometimes several, on your event list that is related to the core reason for doing the project. For example:
- Traveller wants to buy a ticket would be a key event in a ticket selling project
- Pilot wants to enter the airspace would be a key event in an air traffic control project
- Viewer wants to choose programme would be a key event in a domestic TV project
We suggest that you start your requirements elicitation by gathering the requirements for the key event(s).
6. Simulate the Key Event
Build a simulation of the business use case. You can do this in a variety of ways: scenario models, low-fi prototypes, models, sketches, playthroughs, or any technique that helps you to quickly make the business use case seem real to the people you want to communicate with. The stakeholders participate with work knowledge and confirmation that your simulation is a fair representation of the desired business use case.
7. Event Driven Product Use Cases
Given your knowledge of the business use case, do you know enough about it to be able to decide the product boundary for that event? You are taking into account:
- your knowledge of the business use case
- the constraints that apply (section 4)
- your ambition for the product (section 8)
- your stakeholders (sections 2 and 3)
- the purpose of the project (section 1)
Based on that knowledge you (along with the help of other stakeholders) are making a decision about your ambition for that part of the product. This might mean pushing the product boundary further in or further out into the world to define the most appropriate boundary for that product use case.
Bear in mind that there could be a number of stakeholders with an interest in what this part of the product is to do, and thus your decision on the product boundary. Go back to your stakeholder listing or models, and use them to ensure that all the relevant (business and technical) people make their contribution here.
8. Gathering the Atomic Requirements
Each product use case represents something that you want the product to do, so it has a number of associated functional requirements. The product use case also has a number of non-functional requirements and a number of constraints.
This illustrates how a product use case has a number of associated requirements. Your next step is to discover all the atomic requirements for your product use case.
Use a combination of the Volere trawling techniques to gather the requirements. The combination that you use depends on your project sociology, geography and the experience of your stakeholders. This pdf article on trawling techniques could be useful.
Use sections 4 and 9 to 17 on the requirements template as a checklist to make sure that you discover all the different types of atomic requirements that relate to the product use case that you are focusing on.
9. Defining the Atomic Requirements
Each of the requirements you gather whether they are functional, non-functional or constraint have multiple attributes. One attribute is the unique identifier for the requirement. Another is a connection to each of the product use cases that has this requirement. The description, rationale and fit criterion together specify the meaning of the requirement and make it measurable and testable.
The Volere Snow Card (you will find full details in the template) is a guide for collecting the attributes for your atomic requirements.
10. Quality Gateway
The purpose of the quality gateway is to test the atomic requirements before they become part of the specification. The quality gateway provides the following requirements testpoints:
- Completeness
- Measurability
- Traceability
- Consistency
- Relevancy
- Correctness
- Ambiguity
- Viability
- Solution-bound
- Gold Plated
- Scope Creep
For more on the quality gateway, download the pdf article Requirements Fundamentals: the basis for effective testing.
11. The Rest of the Requirements
When you have recorded the requirements for the key product use cases, go back to step 5 and choose the next most important business events. Trawl for requirements as we have described in steps 5 through 10.
Keep in mind that some of the atomic requirements relate to more than one product use case. In this case tag the requirement with each of the relevant product use case numbers so that you can trace all the connections.
Of course if you have a collaborative group of stakeholders then you can implement incrementally. Once you have the requirements for the first few product use cases they can be being implemented while you gather the requirements for the following use cases. There will be an overhead for managing changes, but this is lessened if you have defined the dependencies between the business events, business use cases, and product use cases.
12. Frequently Asked Questions
We are often asked questions, and the answers contain more information on getting started with requirements.
12.1 How do we get more information about applying Volere in our environment?
Mastering the Requirements Process by James and Suzanne Robertson. Addison-Wesley, 1999
Requirements-led Project Management: discovering David's slingshot
To be published by Addison-Wesley during 2004
The web page of The Atlantic Systems Guild and the Volere site you are reading.
12.2 What training is available?
The Atlantic Systems Guild regularly run requirements workshops in Australia, England, Germany, Italy, Netherlands, United States. See the Guild site for details and schedules. We also run tailored in house courses.
12.3 Does Volere depend on a particular methodology?
Volere practices are independent of any particular methodology, process or modelling technique. The practices are designed to be tailored to your own environment and are used by projects in a wide range of industries.
12.4 Does Volere work with automated tools?
Our clients use many different combinations of automated tools, Caliber, DOORS and Requisite are currently the most popular. You can find reviews of most tools here. Volere provides the basis for defining which requirements deliverables are applicable to your project. Once you have agreed on these deliverables then you are in a position to take advantage of automated technology. You could say that Volere helps you to define your requirements for managing requirements.
12.5 Should the documents I publish look the same as the Volere template?
The intention of the template is to provide you with a container for gathering your requirements knowledge. When you publish documents you will choose to publish different subsets and arrangements of that knowledge depending on the audience for the document.
12.6 Can we get some help to review our progress?
The Atlantic Systems Guild provides requirements audits and guidance. This is a periodic review of your requirements deliverables and your process, with recommendations on how you can take more advantage of opportunities, avoid wastage and accelerate your path to a successful result.
This article is copyright © 2004 the Atlantic Systems Guild Limited, but may be
adapted for your internal use provided copyright is acknowledged. Please
let us know what you
are using it for.
top of page
