Page 122 - Software and Systems Requirements Engineering in Practice

C
t
a
h
4
r

:
e
C h a p t e r 4 : R e q u i r e m e n t s M o d e l i n g 91 91
R e q u i r e m e n t s M o d e l i n g
p
use cases and is an endpoint of the analysis (see the next section for
more information). The figure illustrates only one possible scenario;
there may be many. For example, there may be scenarios where the
official enters the wrong competitor (e.g., by assigning a U.S. citizen
to the Albanian ski team) or tries to enter a competitor who does not
exist. All of these scenarios will have to be defined.
A very common mistake at this point in the elicitation process is not
to define error scenarios. The oversight may very well be hidden until it
is time to start testing the system, at which point the elicitation of error
scenarios may become the responsibility of testers. When testers have to
complete scenarios, the elicitation process becomes inefficient to say the
least. Not only are testers less likely to have access to the stakeholders to
elicit error scenarios, but some of the system may have been designed
and built at this point without taking into consideration the need to
handle the “to be discovered” error conditions.
While creating the scenario just described, we find that some
person or thing must have information about teams and provide
information about them (arbitrarily called the “team controller” in
Figure 4.6). So we have identified, while creating a scenario, what is
typically called a business object. A business object is an object that is
part of the system (it could be a person, it could be a group of people,
it could be a computer system or systems) that performs a needed
function or set of related functions. If we can’t find a business object
that does what we need early in the elicitation process, we create one.
Later, we will be collecting requirements by looking at the services
that these business objects have to provide in order for the scenarios
to work. During this effort we identify needed product features,
including the ability to store and retrieve information about teams,
store and retrieve information about individual competitors, and so
on. As these product features are identified, we can create a feature
tree that shows the relationship of all these features (see Figure 4.8).

The Sports Event Management System

Manage Manage Manage
Competitors Teams Events

Delete Team Create Team Edit Team
Details

Remove Add
Competitor Competitor to
from Team Team

FIGURE 4.8 High-level feature tree