-Once we collected the required knowledge on the requirements for - -2
-the system that we're developing, we need to model it in - -3
-a structured and clear way, so that it can be - -4
-analyzed and refined. And there are really tons of ways to - -5
-do that, depending on your focus and objectives. More specifically, - -6
-when modeling requirements you need to decide what you want to - -7
-model and how you want to model it. So let's look - -8
-at these two aspects independently. What you decide to model depends - -9
-on where your emphasis is. That is on which - -10
-aspects of the requirements you want to focus. For - -11
-example if your emphasis is on the characteristics of - -12
-the enterprise of the company that you are analyzing you - -13
-may want to model goals and objectives of the - -14
-company, or its organizational structure, its task and dependencies - -15
-and so on. Conversely, if your focus is on - -16
-information and behaviors, you might want to concentrate on aspects - -17
-such as the structure of information, various behavioral views - -18
-some of which we will see in the next - -19
-lesson, or maybe time or sequencing requirements. Finally, if - -20
-you're mostly interested in the quality aspects of your - -21
-system, you will focus on the various non-functional properties - -22
-of the software that are relevant in the context - -23
-considered. For example reliability, robustness, security, and so on. - -24
-You will just pick the ones that are relevant for - -25
-your context. And as we said, there's a second dimension. - -26
-After you have decided what to model in your system, - -27
-you have to decide how you want to model it. - -28
-So I want to show here some options for modeling - -29
-enterprises, information, and quality aspects. And as you can see - -30
-here for each type of information there are many possible - -31
-models that we can use to represent it. And all - -32
-these models have advantages and - -33
-disadvantages, different levels of formality and - -34
-different focus. Something else that I want to point out - -35
-about these models is the fact that these models are often - -36
-orthogonal to one another, especially if we consider models in different - -37
-categories. So what that means is that they're complimentary rather than - -38
-mutually exclusive. Different models can be used to provide views - -39
-of the requirements from different perspectives, and we will not see - -40
-most of these models in this course, but I wanted to - -41
-list them anyways to give you an idea of how many - -42
-there are and how vast is this area. As far - -43
-as we are concerned in the course and for the - -44
-projects we will express requirements using one of two main - -45
-ways. Using natural language, that is informal specifications and using - -46
-UML diagrams, which is graphical models. And we will introduce - -47
-UML and the most important diagrams in the next lesson. - -48
-And the only other type of models that I want - -49
-to mentions explicitly are goal models because they're extremely popular. - -50
-So the main idea with goal models is it start with the main goal of - -51
-the system and then keep refining it - -52
-by decomposing it in sub-goals. So it's kind - -53
-of a very natural way of progressing. - -54
-And you continue this refinement until you get - -55
-to goals that can be operationalized, and represent - -56
-the basic units of functionality of the system. -- cgit 1.4.1