As requirements are discovered (elicited) and captured, they should periodically be analysed; they can be analysed for completeness, correctness, priority, release date, ambiguity, clarity, testability, achievability, cost, risk, scope, cultural feasibility, etc. This is true whether the requirements are captured as user stories, use cases, business tasks or any other format.
The requirements analysis process involves checking backwards with the requirements owners (e.g. product owner(s)) and forwards with the stakeholders who will use the requirements in some way, e.g. to design, build. test, release or administrate the required system.
In checking back (requirements validation) with the owners of the requirements, we are trying to ensure that the real business needs have correctly identified and defined. Consider the goals of the project as well as the overall goals of the organisation, the business case, the priorities and the scope for the project; does the requirement respect these? Have the goals or the scope changed, perhaps with a change of sponsor for example? Do the requirements seem to be related to the original problem? Do we remember what that problem was? Have we identified and involved all of people and groups affected by the requirements?
In these reviews with business stakeholders, ensure that they really do understand the requirements as written. Is this what they wanted? The big question to ask is, ‘How will the requirements, as written, contribute to the solution of the original problem?’ This is the rationale for the requirement; it can sometimes be very difficult to get the stakeholders to clearly specify a rationale. If there is no rationale, the requirement needs to be dropped.
In reviewing the requirements with the people who will build or otherwise acquire as system that satisfies the requirements, we need to ensure that a system as represented by the requested requirements can be built and tested within the defined constraints. In the context of testing, and of development, we need to ensure that there are clear and unambiguous acceptance criteria. The obvious way of doing this is to have the requirements reviewed by the people who will be doing the building and testing; the architects, designers, programmers, testers and release managers.
A well constructed requirement should normally permit multiple solutions. Is this true of the requirements at hand or are they actually solution statements masquerading as requirements? If they are solutions, is this ok? Usually it is not.
That said, we also need to ensure that the required product can be developed within the constraints imposed by the business. Realistic costs can only be determined in the context of the design options, or potential architectures.
Assessment of requirements must therefore involve people with sufficient technical skills and experience to understand the likely implementation costs. If the organisation cannot afford the solution, or cannot justify that expense in terms of benefits, it is not worth continuing with the development.
If what is being requested is not feasible for any reason, e.g. technical complexity or cost, the designers and architects may be able to come to the rescue with an application of the 80:20 rule; e.g. make some changes to the requirements to be able to get most of what you want with less risk and cost.
Requirements reviews, as described here, should be done as early as possible. The earlier in the life cycle the problems are discovered, the quicker and easier it will be to resolve them. This increases the chances of achieving a workable solution first time. Obviously, just because it’s workable does not mean that it really will solve the business problem or will realise the opportunity; in the end, we just have to get it out there and see. This a justification for agile style developments with ‘minimum viable products’ and ‘failing fast’.
Analysis with Models
There are risks in relying purely on text to define requirements. Ambiguity is a problem. It can be difficult to assess completeness. One solution, or partial solution, to do these problems is to use models.
There are mixed opinions about the value of models, particularly formal models. One option is to use informal models, sometimes referred to as napkin models. These are easier for business stakeholders to create and can be less intimidating. Formal models however have more rigour; they are essential when we are intending to automatically generate applications and databases from models. Popular forms for formal models include UML and BPMN.
For Complex systems (with the capital ‘C’), there are other considerations in terms of value of models, but such highly specialist considerations are beyond the scope of this article.
Analysis and Prototyping
Another way of mitigating risks inherent in requirements defined as text is prototyping. Prototyping is popular but there are consequent risks such as the popularly quoted management of user expectations. Another risk is that we may suddenly find that we are no longer dealing with requirements but with solutions; as stated above, a well formed requirement should allow for multiple solutions.
When we are eliciting requirements, the prototype should be as minimalist as possible; the prototype should be used to encourage discussion about the real need.
When we are validating requirements, prior to purchasing a solution or starting system development, the prototype should be detailed enough to show what the system will look like. This gives stakeholders a chance to say, “Now that I’ve seen it, I realise that it’s not what I want.
Our analysis, including reviews, modelling and prototyping, should clarify everyone’s ideas and should give us confidence that we are on track to create what is really needed to solve the business problem or realise the business opportunity. Such clarity facilitates estimating the workload ahead and helps to set expectations and share a vision. All of this will be good news to the project manager and senior management.