Now we are at the point in which we
have collected and modeled our requirements. So the next thing
that we can do is to analyze the requirements to
identify possible problems, and specifically there are three types of
analysis that we can perform. The first type of analysis
is verification. So in this case we're talking about the
requirements verification. And in verification
developers will study the requirements
to check whether they're correct, whether they accurately reflect the
customer needs as perceived by the developer. Developers can
also check the completeness of the requirements, check whether there
are any missing pieces in the requirements as we
discussed earlier. They can check whether the requirements are pertinent,
or contain irrelevant information, like the one shown here.
And they can also check whether they're consistent, unambiguous, testable
and so on, so all those properties that should
be satisfied for the requirements. A second type of analysis
that is typically performed on requirements is validation. And
the goal of validation is to assess whether the collected
requirements define the system that the stakeholders really want.
So the focus here is on the stakeholders. And in
some cases, stakeholders can check the requirements directly if
the requirements are expressed in a notation that they understand.
Or they might check them by discussing them with the
developers. Another possibility is that stakeholders asses the requirements by
interacting with a prototype of the system, in case
the requirements engineering process that is being used involves
early prototyping. And finally surveys, testing, and other techniques
can also be used to validate requirements. A final type
of analysis that we can perform on requirements is
risk analysis. And risk analysis aims to identify and
analyze the main risks involved with the development of
the system being considered. And if some requirements are deemed
to be too risky, like in this case, this might result in
changes in the requirements model to eliminate or address those risks. And note
that all these analysis activities can
be performed in many different ways depending
on the modeling languages chosen to
represent the requirements and on the context.