Page 126 - Software and Systems Requirements Engineering in Practice

94 S o f t w a r e & S y s t e m s R e q u i r e m e n t s E n g i n e e r i n g : I n P r a c t i c e

As previously mentioned, depending on the starting point,
several different types of models (e.g., business, feature, goal, analysis,
design, implementation) may be used. As we descend to lower and
lower levels within a business, feature, goal, or analysis model, we
include more detail.
The lowest level in an analysis model consists of testable use
cases, as described with scenarios, flowcharts, and state diagrams.
The lower-level use cases and requirements are the same except for
phrasing. For example, the use case might be “schedule a patient for
a followup visit”; with the corresponding requirement being “It shall
be possible to schedule a patient for a followup visit using the
scheduling system.” It is important to define the lowest use case level
from the perspectives of both semantics and mechanics in order to
determine when a model is complete. For example, a definition of use
case completeness might include these considerations:
• An individual use case shall be considered terminal (e.g., no
further decomposition) when it has no included or extending
use cases.
• It has been defined with state or activity diagrams describing
both successful and unsuccessful outcomes.
• It provides sufficient information for the creation of test
cases.
• Its documentation is suitable for use as a requirement
definition.
• It has been given a special stereotype of terminal use case (see
Figure 4.7).
• A nonterminal concrete use case shall be considered complete
when it meets all the quality assurance checks for a
nonterminal use case, and all of the leaf use cases that are
included or extend it have been defined and are complete.
• A nonterminal abstract use case shall be considered complete
when all of the concrete use cases reachable from it are
complete. By reachable we mean by traversing the graph
consisting of nodes (use cases) and edges (dependencies, e.g.,
“includes,” “extends”).

Extracting Requirements from the Model
Prior to starting elicitation and analysis, it is necessary to understand
how model(s) will be used on a project. If models are only to be used
for background context and to provide information for testers, less
formality is required. However, if models are to be mined for
requirements and metrics, or if various artifacts are to be
semiautomatically generated from the model, then a more formal
approach is needed. Since a properly crafted model is an acyclic