Mary Bone presented a paper “Cyclone Process: Dealing with Vague Requirements” at INCOSE 2008 in the technical track. I’m going to try to summarize her work here.
Her premise is that existing requirements models do not deal with vague requirements, but rather they specifically aim to remove any vagueness from requirements. However, she contends that sometimes you will have vague requirements, and therefore need a way to deal with them.
As an example, she spoke to a requirement that said a system must work in all countries in which a unit is deployed. Well, clearly any good requirements engineering will ask “which countries”? The issue here is that this was a military application, and the list of countries was constantly changing.
A New Model For Software Requirements
Mary proposed the cyclone model which defines requirements to a risk level that is sufficient for the stakeholders. Pictorially, the model resembles the spiral model with a 3rd dimension, risk. The phases look similar as well. There is an elicitation phase in which she encourages all requirements to be captured, with any initial risk information. During analysis, this information is reviewed and a risk assessment is done on the requirements, where a risk factor and rationale for the risk is assigned. Vague requirements are just given a higher risk factor. In particular, the higher risk requirements are re-reviewed, and during a negotiation and commitment phase, stakeholders agree on the requirement, rational, risk, and risk rationale.
I think the key take away here is that you are adding a couple attributes to the requirements to reflect the risk of each one, when the requirements cannot be written clearly. While I’m inclined to avoid excess attributes on all requirements when there is no need for them, perhaps you could just assign a default “normal” risk to all requirements, and when you have a few that are still vague, you assign a high risk to only those. The project can continue forward without requirements being fully defined.
She did not speak to this, but I see this technique being most applicable to projects with strict criteria for requirements sign-off, regulatory projects, etc. In many projects, I think it’s pretty common to move forward with some vague requirements, knowing they’ll be iterated on in a future phase. It’s almost implicit in the iterative methodology.
