What is it?
Designing a large and complex system is a job that must be
done in stages. A lot of decisions are bound up within the deployed implementation;
we need to make the biggest decisions first -- that is, the decisions that
affect most of the rest --- and defer the smaller ones. Bigger decisions
are about requirements and the overall architecture; smaller decisions
include the design of specific routines or the naming of local variables.
Programming languages are very good for expressing the end result of
the decision making process, telling the machinery what we want it to do.
But they aren't very good at expressing part-finished designs: the big
decisions without the fine detail. That's why we use modeling languages
such as UML (or less well known ones like ODP).
Modeling language allows us to talk clearly about the high-level aspects
of design, whether discussing things at the whiteboard, or describing a
design for the benefit of future maintainers. It enables us to think and
communicate clearly about the most important issues, without the clutter
of implementation detail.
Although a model is abstract, it need not also be fuzzy. Traditional
requirements documents, written in English and illustrated with ad-hoc
diagrams, tend to be ambiguous and inconsistent; progressing the design
towards the program code increases detail and precision at the same time.
During the process, issues glossed over in the requirements spec are raised
— sometimes quite late in the schedule, resulting in last-minute fudges.
But it is the precision, not the detail, that exposes the gaps and inconsistencies.
Precision means being exact about what your statements do and don't imply.
Used properly and to the full, modeling allows you to be precise about
the high-level issues. Because you're being abstract, you can cover all
of a large system in a short time; because you're being precise, you discover
lots of questions about the requirements that you can take back to the
Constructing a good model therefore
Increases your confidence that you understand the customer's business domain
and needs; and increases their confidence that they are going to get an
Decreases late fixes when inconsistent requirements are discovered or after
the customer sees your first delivery.
Reduces ad-hoc and incoherent decisions during design.
Reduces overall costs of development.
Makes maintenance easier.
Modeling isn't just used for describing the requirements or
architecture of a program. It can be used to describe the concepts and
activities in a business domain, entirely separate from any single piece
of softare. There are several uses:
The software is there to support the business. It is therefore a useful
first step to describe the business, before going into the role of the
system within it.
If you design several systems within the same domain, they will use some
of the same concepts. Making a common definition of those concepts gives
you a head start in understanding and documenting the requirements of any
Where components are coupled together, it's necessary to describe their
connections — particularly in component
based development, where there may be many possible configurations.
To describe what the components are talking to each other about, we need
a common business model. This has to include not just data definitions,
but also information about business rules and activities.
It can be very useful to model a business domain just for the benefit of
the business, so that everyone is talking the same language; particularly
where we are trying to manage the integration
of a large enterprise.
We generally begin a project by constructing a model of the
principal concepts in the domain. This can act as the basis for
requirements and designs, and interface definitions. Models can also be
used as the basis for describing changes to existing systems - software
requirements management should make explicit the refinements of any SRS
(software requirement specification).
It is sometimes better to go straight for building the software, without
any modelling. This is the case where the end-product is small or can be
made quickly by assembling existing components. In any kind of project,
an aim should be to give the customer feedback about what you're providing
for them, frequently and as soon as possible. The most effective feedback
is an actual working system (even without most of its features): if this
can be done very early, that's great — it's what CBD is about. Otherwise,
the most useful early feedback comes from the many questions generated
by the elaboration of a model.
complete solutions for requirements engineering
(consultancy, courses, workshops, mentoring, seminars, development)