Page 108 - Software and Systems Requirements Engineering in Practice

u
i
e
q
r
e
a
h
R
4
e
r

C
:
t
p
m
l
e
d
i
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 77 77
g
n
o
t
n
e

s
M
complex processes that can be difficult to understand, even for a subject
matter expert. Some very simple modeling needs can be inferred
from the need for abstraction:
• Process models should, in general, be understandable by
viewers who are not experts in the domain being described
(there are, of course, exceptions, such as views of complex,
domain-specific information).
• Models should be coherent. That is, there should be no holes
or discontinuities. For example, when describing how a bank
customer cashes a check, the reader should be able to traverse
views easily from the point where the customer enters the
bank until the customer is handed money.
• Tools used to create and view models should be easy to use
and should enable processes, not cause difficulties.
Modeling tools and techniques must work in the context of the
organization and project where they are being used. For example, if
requirements are being elicited in a distributed fashion, then the tools
should support distributed requirements elicitation.
For our purposes, a model can be defined as “A representation of
a system that allows for investigation of the properties of the system
and, in some cases, prediction of future outcomes.” We can infer then
that requirements models can be used to
• Provide views that allow us to understand product
requirements precisely.
• Provide views that show generalizations or simplify complex
relationships between requirements.
• Describe the context or background in which a product will
be used.
In systems and software engineering, modeling for analysis has
very different goals than modeling for design. Martin Fowler has
stated about software design: “The fundamental driver behind
[graphical modeling languages] is that programming languages are
not at a high enough level of abstraction to facilitate discussions about
design” [Fowler 2004]. This chapter concerns itself with the use of
models for elicitation and analysis. In requirements engineering,
elicitation and analysis models are specifically used to
• Provide aids for the elicitation of customer needs.
• Clearly define customer processes and the context for any
products being developed.
• Provide a vision for how a product might be used after
completion and deployment.