Yes, in fact, we encourage use cases. We find them the most convenient unit for gathering requirements. The difference you will see with Volere is that we have a consistent way of finding the use cases. We also make a distinction between a business use case and a product use case.
Yes, it does not matter whether you have a dedicated requirements tool. You still have to elicit all the requirements. The tool is a convenient way to record and manage your requirements, but you can use Word, Notes, a customised database or anything else that is capable of storing your requirements.
Most likely, whatever tool you have. Our clients are using Caliber RM, IRqA, DOORS, Rational and a host of others. All of them are able, with minimal effort, to make the template work in their tool.
Not at first. Many people use Word, a spreadsheet or an Access database. It all depends on what you have available at your site or in your budget. There are many specialized tools on the market. We have a list of them with short reviews here
The way that I match the client’s tool possibilities (often a combination of tools) is to use the Volere knowledge model as a guide and determine which classes of knowledge can be automated by which tools in the client’s environment. The knowledge model is a class model showing the relationships between knowledge in the Volere template. The first version was published in our Mastering Requirements Process Book. There is a more up to date version in Requirements-Led Project Management, Addison Wesley, 2006.
The business requirements are independent of any programming language. The requirements, as we suggest you write them, can be readily used by object developers.
Usually people called business analysts, but this varies from company to company. Some business users also write requirements, As long as you are someone who can think about the real needs of the business, not just the widgets on the screens, then you can learn to discover and communicate requirements.
Business process modeling is very much part of the Volere requirements process. We suggest you firstly define the contextual boundary of the work to be investigated by your project. Then partition that work using business events, build one or more models for response to each event. You are modeling the business process that exists at the moment (“as is”) both from the point of view of the technology and people currently used, and what is behind it (the essence). It is also useful to model how the business might be done in the future (“to be”). The requirements come from understanding the business, not just the software part of it.
Software is only useful if it fulfills some genuine business need, and works the way the users need it to work. There is no conflict between requirements and agility, and we suggest that good requirements help the agile process. Even eXtreme programmers find they build better software when they have a good understanding of what the requirements process is all about.
There is no conflict. It depends on which parts of RUP you are using, but generally it is safe to say that RUP asks you to find the requirements for the software, but not how to do it and how to relate it to the business. We tell you how.
Lots of current clients use PRINCE2 – and other project management methods. Many of the deliverables from the Volere requirements process can be used directly by Prince 2, and several of the PRINCE2 deliverables are usable by the requirements process. For example, the PRINCE2 business case describing the organization’s rationale for the project, helps define the Scope/Stakeholders/Goals trinity for the Volere blastoff.
Not always, and certainly not all at once. However, a more precise answer depends on the type of project you are working on, and some other factors such as:
- Size of project and size of project team
- Criticality of project
- Degree of risk you are willing to take
- Geographical diversity of the development team and other stakeholders
- Whether you are outsourcing the development
- Stakeholder experience
- Political or legal demands of the organization (for example, FDA or FAA rules, ISO9001, etc)
- Availability of stakeholders to work together
Generally, we advocate that you write down only what you need to, but all the above factors, and some others, have to be considered when you decide how formal the requirements specification is to be. In some situations it is necessary to do a lot of detailed requirements specification before any implementation work. In other situations implementation work can start as soon as the goals, stakeholders and first cut scoping has been sketched out. Volere, because it provides a requirements knowledge framework, is successfully used by projects at both ends of this scale of formality/agility.
The simple answer is that you gather the requirements needed for one iteration at a time. The hard part of that is planning the iteration. We suggest you make use of business events as the basis for each iteration. We have found that business events give partitions of the system that are independent form each other, and generally comply with the users’ ideas on how the system can be released.
Saying you don’t have time for requirements is the same as saying you don’t have any requirements, or that the software does not have to meet requirements. And if it does not have to meet requirements, we have some software you can have, free.
Requirements do not take a long time when you look at the result of not doing the requirements. There is evidence that getting the requirements correctly means a shorter delivery time, and lower overall cost of the software.
The scope of the work defines the business area you are studying in order to find the real requirements for the product. In other words, by understanding the business being done, you will come to build a product that fits better with the users’ work, and subsequently need less revision later.
The scope of the product defines that part of the work scope—in other words the business you have studied—you decided will best be done by automating it. You write the requirements for whatever is inside the product scope.
A fit criterion is a measurement for a requirement. It is needed because some requirements are too vague or ambiguous to be properly useful. For example, “The product shall be easy to use” is well-intentioned, but not yet able to be implemented. However, if you add a fit criterion such as “75% of first-time users shall be able to buy the correct cinema tickets within 90 seconds, without using the help functionality” makes it clear to the designer what is needed to make the product successful.
You negotiate the fit criterion with the appropriate stakeholders, and writing it helps you to discover the real intention for the requirement. You can also think if the fit criterion as the input conditions for the eventual test of the software, rather than the test itself.
Not when you compare it to the time it takes to correct software that turns out not the meet the real requirements. Nowadays, requirements are gathered incrementally, which means that development gets under way earlier, and the staffing is more even throughout the project.
Usually faster development times. When the programmers are give the correct requirements, they get the right software sooner. Correct requirements eliminate the lengthy (and expensive) reworking that always follows when the wrong software is delivered to the users. This is fairly well documented.
The Volere process is not a rigid prescription that has to be obediently followed, but rather a set of activities and deliverables that bring results. Many clients adapt Volere and incorporate its activities into their own process.
You need to understand the need for requirements. There are no prescribed prerequisites, but we expect you have some knowledge of the software development cycle, and know about the need for requirements.
Immediately apply what you have learned to your current project. The part that you focus on depends on where you are in your life cycle, but at the very do a quick audit on your current deliverables by using the template as your checklist. In the last session of the course you will discuss and formulate your own particular strategy with the instructor and your fellow participants.
Prototypes are an integral part of requirements gathering. However, there is a difference between a prototype built for requirements-gathering purposes and a design prototype.
Requirements are gathered based on the needs of the business. It is unlikely that someone in India can conduct workshops and interviews with your business users to determine their needs. In fact it is safe to say that requirements are the part of software development that cannot be outsourced.