This is an excerpt from the Volare web site cited in your book. The full content is available at: http://www.systemsguild.com/GuildSite/Robs/Template.html
The rest of this document is divided into 3 parts:
Use the Requirements Shell.
Requirement Numbering Give each requirement a unique identifier to make it traceable throughout the development process. The numbering scheme suggested in the requirement shell is: Requirement # is the next unique requirement number Requirement Type is the section number from the template for this type of requirement The inclusion of the section number is not absolutely necessary because we do have a unique requirement id. However it serves as a reminder of what this requirement relates to and helps to remind why the requirement is considered important. Also the ability to compare requirements of the same type makes it easier to identify contradictions and duplications. For example: A functional requirement is section 9, and the next unique number is 128. Requirement #: 128 Requirement Type: 9 The product shall record the time when it is notified of a truck breakdown A performance requirement comes from section 12, and the next unique number is 129. Requirement #: 129 Requirement Type: 12 The product shall inform the truck drivers of their schedule 30 minutes before they are due to leave the depot. Event/use case # is the identifier of a business event or use case that contains this requirement. There might be several Event/use case #'s for one requirement because the same requirement might relate to a number of events. The terms event and use case are already widely used in the systems development world. We use the term business event to mean a business related happening that causes an event-response within the work that we are studying. We use the term event-driven use case (or product use case) to mean a user-defined (or actor defined) piece of activity within the context of the product. Business events and product use cases provide a way of grouping business-related requirements and tracing them through into implementation; they are used throughout the Volere development process. Customer Value Customer Value is a measure of how much your client cares about each requirement. Ask your stakeholders to grade each requirement for Customer Satisfaction on a scale from 1 to 5 where 1 means mild interest if this requirement is satisfactorily implemented, and 5 means they will be very happy if this requirement is satisfactorily implemented The stakeholders also grade each requirement for Customer Dissatisfaction on a scale from 1 to 5 where 1 means that it hardly matters, and 5 means that they will be extremely displeased if this requirement is not satisfactorily implemented The point of having a satisfaction and a dissatisfaction rating is that it guides your clients to think of the requirement from two different perspectives, and helps you to uncover what they care about most deeply. Dependencies This keeps track of other requirements that have an impact on this requirement. If the dependency exists because requirements use the same information, then use of standard naming conventions and definitions (see Section 5) will implement this dependency. Other dependencies exist because a solution to this requirement has a positive or negative effect on solutions to other requirements. Capture these types of dependencies by cross referencing the requirements. Some requirements, especially project drivers and project constraints, have an impact on all the other requirements. Conflicts This keeps track of other requirements that disagree with this one. Conflicts that are caused by mistake are solved simply by bringing them to the surface and resolving them. Other conflicts are because of true differences in opinion/intention. These are the conflicts that might eventually need to be addressed using negotiation or mediation techniques. There is nothing wrong with having conflicting requirements providing you know that you have them. Then you are in a position to address the conflict. History We follow the requirement from the date that it was created, through all its changes. We minimise future confusion by recording the rationale for making major changes. When a requirement is deleted we record when and the rationale behind the deletion. The date that the requirement passes its quality checks, and who passed it, is also recorded.
3a. The users of the product
Content
A list of the potential users of the product. For each category of
user, provide the following information:
User name ? This is most likely to be the name of a user group
like: schoolchildren, road engineers, project managers.
User role ? Summarizes the users' responsibilities.
Subject matter experience ? Summarizes the users' knowledge of the
business. Rate as novice, journeyman or master.
Technological experience ? this describes the users' experience with
relevant technology. Rate as novice, journeyman or master.
Other user characteristics ? Describe any characteristics of the users
that have an effect on the requirements and eventual design of the
product. Describe things like:
Physical abilities/disabilities
Intellectual abilities/disabilities
Attitude to job
Attitude to technology
Education
Linguistic skills
Age group
Gender
Motivation
Users are human beings who interface with the product in some way. The
role of the client is to pay for the development of the product and
the role of the customer is to buy the product. The role of the user
is to use the product to do work. You use the characteristics of the
users to define the usability requirements for the product.
Examples
Users can come from wide, and sometimes unexpected, sources. Consider
the possibility of your users being clerical staff, shop workers,
managers, highly-trained operators, general public, casual users,
passers-by, illiterate people, tradesmen, students, test engineers,
foreigners, children, lawyers, remote users, people using the system
over the telephone or Internet connection, emergency workers, and so
on.
3b. The priorities assigned to users
Content
Attach to each category of user a priority rating. This gives the
importance and precedence of the user. Prioritize the users into:
Key users. These are critical to the continued success of the
product. Give greater importance to requirements generated by
this category of user.
Secondary users. They will use the product, but their opinion of
it has no effect on its long-term success. Where there is a
conflict between secondary users' requirements and those of key
users the key users take precedence.
Unimportant users. This category of user is given the lowest
priority. It includes infrequent, unauthorized and unskilled
users, and people who misuse the product.
Percentage of this type of user ? this is intended to assess the
amount of consideration given to this category of user.
Motivation
If some users are considered to be more important to the product, or
the organization, then this should be stated because it should affect
the way that you design the product. For instance, you need to know if
there is a large customer who has specifically asked for the product,
and if they do not get what they want then the results could be a
significant loss of business.
Some users may be listed as having no impact on the product. This
means that the users will make use of the product, but have no vested
interest in it. In other words, these users will not complain, nor
will they contribute. Any special requirements from these users will
have a lower design priority.
3c. User participation
Content
Where appropriate attach to the category of user, a statement of the
participation that you think will be necessary to provide the
requirements. Describe the contribution that you expect this user to
provide ? business knowledge, interface prototyping, usability
requirements etc. If possible, assess the minimum amount of time that
this user must spend for you to be able to determine the complete
requirements.
Motivation
Many projects fail through lack of user participation, sometimes this
is because the required degree of participation was not made
clear. When people have to make a choice between getting their
everyday work done and working on a new project, the everyday work
takes priority. This requirement makes it clear, from the outset, that
specified user resources must be allocated to the project.
11a. Ease of use.
Content
This section describes your client?s aspirations for how easy it will
be for the intended users of the product to operate it. The product?s
usability is derived from the abilities of the expected users of the
product and the complexity of its functionality.
The usability requirements should cover such things as:
* Efficiency of use - how quickly or accurately the user can use the
product.
* Ease of remembering - how much is the casual user expected to
remember about using the product
* Error rates - for some products it is crucial that the user
commits very few, or no, errors.
* Overall satisfaction in using the product - this is especially
important for commercial, interactive products where there is a
lot of competition. Web sites are good example of this.
Motivation
To guide the product's designers into building a product that will
meet the expectations of its eventual users.
Examples
The product shall be easy for 11 year-old children to use.
The product shall help the user to avoid making mistakes.
The product shall make the users want to use it.
The product shall be used by people with no
training, and possibly no understanding of English.
Fit Criterion
These examples may seem simplistic, but they do express the intention
of the client. To completely specify what is meant by the requirement
it is necessary to add a measurement of acceptance. We call this a fit
criterion. The fit criterion for the above examples would be:
[An agreed percentage, say 90%] of a test panel of 11 year olds shall
be able to successfully complete [list of tasks] within [specified
time]
One month's use of the product shall result in a total error rate of
less than [an agreed percentage, say 2%]
An anonymous survey shall show that [an agreed percentage, say 75%] of
the users are regularly using the product after [an agreed time]
familiarization period.
Considerations
Refer back to Section 3, the Users of the System, to ensure that you
have considered the usability requirements from the perspective of all
the different types of users.
It may be necessary to have special consulting sessions with your
users and your client to determine whether there are any special
usability considerations that must be built into the product.
You could also consider consulting a usability laboratory that has
experience with testing the usability of products that have
constraints (sections 1-7 of this template) similar to yours.
11b. Personalization and internationalization requirements
Content
This section describes the way in which the product can be altered or
configured to take into account the user's personal preferences or
choice of language. The personalization requirements should cover such
things as:
* Languages, spelling preferences, language idioms
* Currencies including the symbols and decimal conventions
* Personal configuration options - there are a myriad of these
Motivation
To ensure that the product's users do not have to struggle with, or
meekly accept, the cultural conventions of the builder.
Examples
The product shall retain the buyer's buying preferences.
The product shall allow the user to select a chosen language.
Considerations
Consider the locations of the potential customers and users of your
product. Any out of country users will welcome the opportunity to
convert to their home spelling and expressions. By allowing users to
customize the way in which they use the product, you are giving them
the opportunity to participate more closely with your organization, as
well as give them their own personal user experience.
You might also consider the configurability of the product. This
allows different users to have different functional variations of the
product.
11c. Ease of learning.
Content
A statement of how easy it should be to learn to use the product. This
will range from zero time for products intended for placement in the
public domain (for example a parking meter or a web site) to a
considerable time for complex, highly technical products. (We know of
one product where it was necessary for graduate engineers to spend 18
months in training before being qualified to use the product.)
Motivation
To quantify the amount of time that your client feels is allowable
before a user can successfully use the product. This requirement will
guide designers in how users will learn the product. For example, the
designers may build elaborate interactive help facilities into the
product, or the product may be packaged with a tutorial. Alternatively
the product may have to be constructed so that all of its
functionality is apparent upon first encountering it.
Examples
The product shall be easy for an engineer to learn.
A clerk shall be able to be productive within a short time.
The product shall be able to be used by members of the public who
will receive no training before using it. They may have seen the
advertising campaign.
The product shall be used by engineers who will attend 5 weeks of
training before using the product.
Fit Criterion
Fit criterion for the above example requirements are:
An engineer shall produce a [specified result] within [specified time]
of beginning to use the product, without needing to use the manual.
After receiving [number of hours] training a clerk shall be able to
produce [quantity of specified outputs] per [unit of time].
[Agreed percentage] of a test panel shall successfully complete
[specified task] within [specified time limit].
The engineers shall achieve [agreed percentage] pass rate from the
final examination of the training.
Considerations
Refer back to Section 3, the Users of the System, to ensure that you
have considered the ease of learning requirements from the perspective
of all the different types of users.
11d. Accessibility requirements.
Content
The requirements for how easy it should be for people with common
disabilities to access the product. These disabilities might be to do
with sight, physical disablement, hearing, cognitive, or others.
Motivation
In many countries it is required that some products are made available
to the disabled. In any event, it seems self-defeating to exclude this
sizable community of potential customers.
Examples
The product shall be usable by partially-sighted users.
The product shall conform to the Americans with Disabilities Act.
Considerations
There are users with disabilities other than the commonly-described
ones. Similarly, there are partial disabilities that are fairly
common. A simple, and not very consequential example, is that
approximately 20% of males are red-green color blind.