-Now we are at the point in which we - -2
-have collected and modeled our requirements. So the next thing - -3
-that we can do is to analyze the requirements to - -4
-identify possible problems, and specifically there are three types of - -5
-analysis that we can perform. The first type of analysis - -6
-is verification. So in this case we're talking about the - -7
-requirements verification. And in verification - -8
-developers will study the requirements - -9
-to check whether they're correct, whether they accurately reflect the - -10
-customer needs as perceived by the developer. Developers can - -11
-also check the completeness of the requirements, check whether there - -12
-are any missing pieces in the requirements as we - -13
-discussed earlier. They can check whether the requirements are pertinent, - -14
-or contain irrelevant information, like the one shown here. - -15
-And they can also check whether they're consistent, unambiguous, testable - -16
-and so on, so all those properties that should - -17
-be satisfied for the requirements. A second type of analysis - -18
-that is typically performed on requirements is validation. And - -19
-the goal of validation is to assess whether the collected - -20
-requirements define the system that the stakeholders really want. - -21
-So the focus here is on the stakeholders. And in - -22
-some cases, stakeholders can check the requirements directly if - -23
-the requirements are expressed in a notation that they understand. - -24
-Or they might check them by discussing them with the - -25
-developers. Another possibility is that stakeholders asses the requirements by - -26
-interacting with a prototype of the system, in case - -27
-the requirements engineering process that is being used involves - -28
-early prototyping. And finally surveys, testing, and other techniques - -29
-can also be used to validate requirements. A final type - -30
-of analysis that we can perform on requirements is - -31
-risk analysis. And risk analysis aims to identify and - -32
-analyze the main risks involved with the development of - -33
-the system being considered. And if some requirements are deemed - -34
-to be too risky, like in this case, this might result in - -35
-changes in the requirements model to eliminate or address those risks. And note - -36
-that all these analysis activities can - -37
-be performed in many different ways depending - -38
-on the modeling languages chosen to - -39
-represent the requirements and on the context. -- cgit 1.4.1