INCOSE 2008 – How to Deal with Vague Software Requirements
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.
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.
Labels: requirements, risk management, software requirements
posted by Joy at 6/17/2008 01:23:00 AM
2 Comments:
The vagueness mentioned can be dealt with by policy, business rules, or the strategy pattern.
The globalization, internationalization, and localization requirements would be better stated as such.
Vagueness is the flag for architectural enablement. Or, it is the flag for failure. The only project I've been on failed because of vagueness.
Thanks for the comment, I'm moving it over for further discussion on the message board:
http://www.seilevel.com/messageboard/showthread.php?p=5973#post5973
Post a Comment
<< Home