Page 88 - Software and Systems Requirements Engineering in Practice

n
g

i
t
i
u
i
r
R
e
q
c
r
e
t
:
3

C
l
i
p
a
h
e
t
s
C h a p t e r 3 : E E l i c i t i n g R e q u i r e m e n t s 59 59
m
e
n
Data flow diagrams (DFDs) have been around for a long time.
There are several similar methodologies, such as those defined by
[Gane et al. 1997] and [Yourdon 1988]. A sample data flow diagram
is shown in Figure 3.10. The vertical lines on the data stores indicate
the number of times that the store is shown on the diagram. While
DFDs appear to have fallen out of favor and viable tools can be hard
to find, they still have their proponents. DFDs can be very effective
diagramming techniques for analyzing business needs. The primary
difference between the data flow and newer (object-oriented)
techniques is the focus on data flows and data structures rather than
services. With data flow techniques, a customer’s data and the flow
of that data are analyzed. Stores needed to hold the data and
processes needed to manipulate the data are added. The results of
the analysis are then captured in data flow diagrams for review
with the stakeholders.
Use case analysis [Jacobson et al. 1992] (use case = business process)
involves either defining a customer process (business modeling) or
showing the relationship of a system or product to the outside world.
The analysis can be done using natural languages and tables or visual
techniques such as those described in Chapter 4. A use case consists of
the following:
• Actors People or things interacting with the use case
• Events Things that cause the use case to happen
• Preconditions Things that must be true for the use case to
happen
• Postconditions Things that must be true if the use case has
successfully completed
• Activities The processes that occur in the use case
• Included use cases Other processes used by this use case
• Extending use cases Other processes that may optionally
take place during the occurrence of this use case
When using natural language, activities are normally described
using a table similar to the one shown in Table 3.2. In addition to the
“sunny day” scenario, tables are normally created for alternate
scenarios. For the “cash a check” example shown in Table 3.2, alternate
scenarios might include how to handle insufficient funds or an ID
that is not acceptable.
One problem with using natural language is that the set of use
cases describing viable business processes makes up a graphical
structure that is not well represented by text documents. For
example, two different use cases might use or include the same use
case (Figure 3.11). Furthermore, as we interact with the customers
or stakeholders, the number of use cases can grow rapidly. If the use
cases are kept in text files, document management issues can arise.