and existing systems and distilling the user and system requirements from this information.
Sources of information during the requirements discovery phase include documentation,
system stakeholders and specifications of similar systems. You interact
with stakeholders through interviews and observation, and may use scenarios and
prototypes to help with the requirements discovery. In this section, I discuss an
approach that helps ensure you get broad stakeholder coverage when discovering
requirements, and I describe techniques of requirements discovery including interviewing,
scenarios and ethnography. Other requirements discovery techniques thatStakeholders range from system end-users through managers and external stakeholders
such as regulators who certify the acceptability of the system. For example,
system stakeholders for a bank ATM include:
I. Current bank customers who receive services from the system
2. Representatives from other banks who have reciprocal agreements that allow
each other's ATMs to be used
3. Managers ofbank branches who obtain managemc~nt information from the system
4. Counter staff at bank branches who are involved in the day-to-day running of
the system
5. Database administrators who are responsible for integrating the system with
the b,mk's customer database
6. Bank security managers who must ensure that the system will not pose a security
hazard
7. The bank's marketing department who are likely be interested in using the system
as a means of marketing the bank
8. Hardware and software maintenance engineers who are responsible for maintaining
and upgrading the hardware and software
9. National banking regulators who are responsible for ensuring that the system
conforms to banking regulations
In addition to system stakeholders" we have already seen that requirements may
come from the application domain and from other systems that interact with the
system being specified. All of these must be considered during the requirements
elicitation process.
These requirements sources (stakeholders, domain, systems) can all be represented
as system viewpoints, where each viewpoint presents a sub-set of the requirements
for the system. Each viewpoint provides a fresh perspective on the system, but these
perspectivl~s are not completely indep<:ndent--they usually overlap so that they have
<;ommon requirements.
Viewpoil1lts
Viewpoint-oriented approaches to requirements I~ngineering (Mullery, 1979;
Finkelstein et al., 1992; Kotonya and Sommerville, 1992; Kotonya and Sommerville,
1996) organise both the elicitation proct:ss and the requirements themselves using viewpoints.
Akey strength of viewpoint-oriented analysis is that it recognises multiple perspectives
and provides a framework for discovering confliicts in the requirements proposed
by different stakeholders.Viewpoints can be used as a way of classifying stakeholders and other sources
of requirements. There are three generic types of viewpoint:
1. Interactor viewpoints represent people or other systems that interact directly
with the system. In the bank ATM system, examples of interactor viewpoints
are the bank's customers and the bank's account database.
2. Indirect viewpoints represent stakeholders who do not use the system themselves
but who influence the requirements in some way. In the bank ATM system,
examples of indirect viewpoints are the management of the bank and the bank
security staff.
3. Domain viewpoints represent domain characteristics and constraints that influence
the system requirements. In the bank ATM system, an example of a domain
viewpoint would be the standards that have been developed for interbank communications.
Typically, these viewpoints provide different types of requirements. Interactor
viewpoints provide detailed system requirements covering the system features and
interfaces. Indirect viewpoints are more likely to provide higher-level organisational
requirements and constraints. Domain viewpoints normally provide domain constraints
that apply to the system.
The initial identification of viewpoints that are relevant to a system can sometimes
be difficult. To help with this process, you should try to identify more specific
viewpoint types:
l. Providers of services to the system and receivers of system services
2. Systems that should interface directly with the system being specified
3. Regulations and standards that apply to the system
4. The sources of system business and non-functional requirements
5. Engineering viewpoints reflecting the requirements of people who have to develop,
manage and maintain the system
6. Marketing and other viewpoints that generate requirements on the product features
expected by customers and how the system should reflect the external image
of the organisation
Almost all organisational systems must interoperate with other systems in the
organisation. When a new system is planned, the interactions with other systems
must be planned. The interfaces offered by these other systems have already been
designed. These may place requirements and constraints on the new system.
Furthermore, new systems may have to conform to existing regulations and standards,
and these constrain the system requirements.
Interviewing
Formal or informal interviews with system stakeholders are part of most requirements
engineering processes. In these interviews, the requirements engineering team puts
questions to stakeholders about the system that they use and the system to be develped.
Requirements are derived from the answers to these questions. Interviews may
be of two types:
1. Closed interviews where the stakeholder answers a predefined set of questions.
2. Open interviews where there is no predefined agenda. The requirements engineering
team explores a range of issues with system stakeholders and hence
develops a better understanding of their needs.
In practice, interviews with stakeholders are normally a mix of these. Th
answers to some questions may lead to other issues that are discussed in a less structured
way. Completely open-ended discussions rarely work well; most interviews
require some questions to get started and to keep the interview focused on the system
to be developed.
Interviews are good for getting an overall understanding of what stakeholders
do, how they might interact with the system and the difficulties that they face with
current systems. People like talking about their work and are usually happy to get
involved in interviews. However, interviews are not so good for understanding the
requirements from the application domain.
It is hard to elicit domain knowledge during interviews for two reasons:
1. All application specialists use terminology and jargon that is specific to a domain.
It is impossible for them to discuss domain requirements without using this terminology.
They normally use terminology in a precise and subtle way that is
easy for requirements engineers to misunderstand.
2. Some domain knowledge is so familiar to stakeholders that they either find it
difficult to explain or they think it is so fundamental that it isn't worth mentioning.
For example, for a librarian, it goes without saying that all acquisitions
are catalogued before they are added to the library. However, this may not be
obvious to the interviewer so it isn't taken into account in the requirements.
Interviews are not an effective technique for eliciting knowledge about organisational
requirements and constraints because there are subtle power and influence
relationships between the stakeholders in the organisation. Published organisational
structures rarely match the reality of decision making in an organisation, but
interviewees may not wish to reveal the actual rather than the theoretical structure
to a stranger. In general, most people are reluctant to discuss political and organisational
issues that may affect the requirements.
Effective interviewers have two characteristics:
I. They are open-minded, avoid preconceived ideas about the requirements and
are willing to listen to stakeholders. If the stakeholder comes up with surprising
requirements, they are willing to change their mind about the system.
2. They prompt the interviewee to start discussions with a question, a requirements
proposal or by suggesting working together on a prototype system. Saying to
people 'tell me what you want' is unlikely to result in useful information. Most
people find it much easier to talk in a defined context rather than in general
terms.
Information from interviews supplements other information about the system
from documents, user observations, and so on. Sometimes, apart from information
from documents, interviews may be the only source of information about the
system requirements. However, interviewing on its own is liable to miss essential
information, so it should be used alongside other requirements elicitation
techniques.
Scenarios
People usually find it easier to relate to real-life examples than to abstract descriptions.
They can understand and critique a scenario of how they might interact with
a software system, Requirements engineers can use the information gained from this
discussion to formulate the actual system requirements.
Scenanos can be particularly useful for adding detail to an outline requirements
description. They are descriptions of example interaction sessions. Each scenario
covers one or more possible interactions. Several fonns of scenarios have been developed,
ea,~h of which provides different types of information at different levels of
detail about the system. Using scenarios to describe requirements is an integral part
of agile methods, such as extreme programming, that I discuss in Chapter 17.
The scenario starts with an outline of the interaction, and, during elicitation, details
are added to create a complete description of that interaction. At its most general,
a scenano may include:
I. A description of what the system and users expect when the scenario starts
2. A description of the normal flow of events in the scenario
3, A description of what can go wrong and how this is handled
4. Information about other activities that might be going on at the same time
5. A description of the system state when the sCf:nario finishes.
Use-cases
Use-cases are a scenario-based technique for requirements elicitation which were
first introduced in the Objectory method (Jacobsen, et al., 1993). They have nowbecome a fundamental feature of the UML notation for describing object-oriented
system models. In their simplest form, a use-case lldentifies the type of interaction
and the actors involved. For example, Figure 7.6 shows the high-level use-case of
the article printing facility in LIBSYS
No comments:
Post a Comment
Your comments are welcome!