Page 127 - Software and Systems Requirements Engineering in Practice

e
r
m
n
e
i
R
C h a p t e r 4 :
e
u
q
t
i
l
n
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 95 95
g
e

s
M
d
o
3.0 Event Management
3.1 Create Event
3.2 Delete Event
3.2.1 Delete Event from Team Calendar
3.2.2 Delete Event Record from Results Database
3.2.3 Delete Event from Event Calendar
3.2.4 Delete Event from Competitor Calendar
3.3 Edit Event
3.4 View Events
4.0 Competitor Management
4.1 Register Competitor
4.2 Disqualify Competitor
FIGURE 4.11 High-level requirements extracted from model
directed graph, it is possible to extract requirements from models
programmatically to populate a requirements database [Berenbach
2003]. An alternative is to keep the requirements in the model,
generating tabular views for review or a Systems Requirements
Specification (SRS) directly from the model (Figure 4.11).
The UML provides the ability to create profiles with specialized
icons and object types. In addition, extensions to the UML exist
specifically for business modeling. We recommend improving the
clarity and simplicity of business and analysis models by augmenting
traditional flowchart or use case symbols with symbols unique to
business modeling or the domain wherever possible, and then
defining semantics, such as those that we have proposed [Berenbach
2004]. For example, one business rule that has been found to be
effective is to require that actors (users of a product) be required to
communicate with concrete (testable) use cases through a boundary,
except on the context diagram. By enforcing this rule, every point
where an interface or form must exist is captured and can be viewed
in an inventory report.
In Figure 4.12 we see the nonfunctional requirement that
operations must complete within one second impacting the software
user interface used by spectators. As mentioned previously, we have
FIGURE 4.12
Adding
requirements to Spectator
diagrams View View Events
Impacts

Spectator Operations must complete
within one second