-But how can we do that? How can we identify the purpose - -2
-of the system and collect good requirements? To answer that question, let me - -3
-give you another definition of requirements - -4
-engineering. And this one is a classical - -5
-one, one that summarizes what we discussed so far, and then we can - -6
-use as some sort of reference. And it is a little long. - -7
-Definitely longer than the one that we saw at the beginning. But it's - -8
-an important one and it contains a lot of very relevant points. So, - -9
-we're going to go through it and highlight these points. So the definition says, - -10
-that the requirements engineering is a set of activities concerned - -11
-with identifying and communicating the purpose of a software intensive - -12
-system and the context in which it will be used. - -13
-And this is exactly what we said at the beginning. But - -14
-something we can highlight in here, is the fact that - -15
-we're talking about a set of activities. So, what that means - -16
-is that requirements engineering is not just a phase or - -17
-a stage. It also says that it's about identifying and communicating. - -18
-And what that is telling us is that communication is - -19
-as important as the analysis. So, it's important to be - -20
-able to communicate these requirements not only to collect them. - -21
-And we will discuss many reasons why that is the - -22
-case. It explicitly talks about purpose. So that allows me - -23
-to stress, once more, that quality means fitness-for-purpose. We cannot - -24
-say anything about quality unless we understand the purpose. And - -25
-the last thing I want to point out in this first - -26
-part of the definition is the use of the term - -27
-context. This is also something else that we mentioned at - -28
-the beginning, that designers, analysts, need to know how and - -29
-where the system will be used. Without this information, you - -30
-cannot really understand what the system should do and you - -31
-cannot really build the system. So now, let's continue and - -32
-read the second part of the definition that says, hence. - -33
-Requirements engineering acts as the bridge between the real-world needs of - -34
-users, customers, and other constituencies affected by a - -35
-software system and the capabilities and opportunities afforded - -36
-by software-intensive technologies. This is a long sentence, - -37
-but also here, we can point out a - -38
-few interesting and relevant points. Let me start - -39
-by highlighting two parts. Real-world needs, and the - -40
-capabilities, and opportunities. So, what are these two - -41
-parts telling us? They are telling us that requirements - -42
-are partly about what is needed, the real-world needs - -43
-of all these stakeholders. But they're also partly about what - -44
-is possible, what we can actually build. We need - -45
-to compromise between these two things. And, finally, I would - -46
-like to point out this term constituencies, which indicates - -47
-that we need to identify all of the stakeholders, not - -48
-just the customer and the users, so anybody who is - -49
-affected by a software system. It is very important to - -50
-consider all of these actors. Otherwise, again, - -51
-we'll be missing requirements, we'll be missing - -52
-part of the purpose of the system and we will build a suboptimal system. -- cgit 1.4.1