Once we collected the required knowledge on the requirements for
the system that we're developing, we need to model it in
a structured and clear way, so that it can be
analyzed and refined. And there are really tons of ways to
do that, depending on your focus and objectives. More specifically,
when modeling requirements you need to decide what you want to
model and how you want to model it. So let's look
at these two aspects independently. What you decide to model depends
on where your emphasis is. That is on which
aspects of the requirements you want to focus. For
example if your emphasis is on the characteristics of
the enterprise of the company that you are analyzing you
may want to model goals and objectives of the
company, or its organizational structure, its task and dependencies
and so on. Conversely, if your focus is on
information and behaviors, you might want to concentrate on aspects
such as the structure of information, various behavioral views
some of which we will see in the next
lesson, or maybe time or sequencing requirements. Finally, if
you're mostly interested in the quality aspects of your
system, you will focus on the various non-functional properties
of the software that are relevant in the context
considered. For example reliability, robustness, security, and so on.
You will just pick the ones that are relevant for
your context. And as we said, there's a second dimension.
After you have decided what to model in your system,
you have to decide how you want to model it.
So I want to show here some options for modeling
enterprises, information, and quality aspects. And as you can see
here for each type of information there are many possible
models that we can use to represent it. And all
these models have advantages and
disadvantages, different levels of formality and
different focus. Something else that I want to point out
about these models is the fact that these models are often
orthogonal to one another, especially if we consider models in different
categories. So what that means is that they're complimentary rather than
mutually exclusive. Different models can be used to provide views
of the requirements from different perspectives, and we will not see
most of these models in this course, but I wanted to
list them anyways to give you an idea of how many
there are and how vast is this area. As far
as we are concerned in the course and for the
projects we will express requirements using one of two main
ways. Using natural language, that is informal specifications and using
UML diagrams, which is graphical models. And we will introduce
UML and the most important diagrams in the next lesson.
And the only other type of models that I want
to mentions explicitly are goal models because they're extremely popular.
So the main idea with goal models is it start with the main goal of
the system and then keep refining it
by decomposing it in sub-goals. So it's kind
of a very natural way of progressing.
And you continue this refinement until you get
to goals that can be operationalized, and represent
the basic units of functionality of the system.