Started off on James Governor's blog this morning, with an interesting post about a series of events taking place in UK lead by James Stamper and got lead through his blog to a very interesting paper on Requirements Elicitation. Having recently implemented change policy, governance and SDLC at Corel, I was very interested to see this blast from the past - a pertinent reminder that we still face the same issues 14 years later and the human condition still prevails in IT.
Carnegie-Mellon's Michael G Christel and Kyo C Yang provide a brilliant and still relevant position as seen in the overview of the problem in the abstract of the paper:
"There are many problems associated with requirements engineering, including problems in defining the system scope, problems in fostering understanding among the different communities affected by the development of a given system, and problems in dealing with the volatile nature of requirements. These problems may lead to poor requirements and the cancellation of system development, or else the development of a system that is later judged unsatisfactory or unacceptable, has high maintenance costs, or undergoes frequent changes. By improving requirements elicitation, the requirements engineering process can be improved, resulting in enhanced system requirements and potentially a much better system.
Requirements engineering can be decomposed into the activities of requirements elicitation, specification, and validation. Most of the requirements techniques and tools today focus on specification, i.e., the representation of the requirements. This report concentrates instead on elicitation concerns, those problems with requirements engineering that are not adequately addressed by specification techniques. An elicitation methodology is proposed to handle these concerns.
This new elicitation methodology strives to incorporate the advantages of existing elicitation techniques while comprehensively addressing the activities performed during requirements elicitation. These activities include fact-finding, requirements gathering, evaluation and rationalization, prioritization, and integration. Taken by themselves, existing elicitation techniques are lacking in one or more of these areas."
Like it or not, agree or not with the methodology, you are engaged in requirements elicitation if you are in IT. I have to run to an ops meeting, but I am not stopping my rant on this yet. It strikes me that we have come a long way with Agility, but the bottom line is that if you don't start your journey facing in the right direction, then it will always take you longer to get there.
Now, where am I going?
Thursday, December 14, 2006
Subscribe to:
Post Comments (Atom)
Posts
1 comment:
The primary problem with the requirement elicitation is that
"fostering understanding among the different communities" is fundamentally impossible. Why?
Communities is another word for culture. Understanding is another word for meaning. Communities are defined by meaning. Cultures are defined by meaning.
Neither communities or cultures will negotiate away their meaning. But, this is what we are asking them to do. So you need an executive sponsor, whose real job is deciding what things mean. Economically that might be justified, but operationally it just ends up politicizing requirements. And, it inserts volitility into the requirements, because one community will have more or less influence from one day to the next.
The reason we develop requirements in this way is that we think that developer efficency is the most important criteria. But, with free or cheap developers, the efficency constraint needs to be reviewed. Operational costs are much higher than developer costs.
When operational, a system doesn't do the whole job for any particular community, so each community exports data, feeds it into Access and Excel to get what they couldn't get from the requirements elicitation process. This is a hidden cost, because accountants never see the salary contributions towards developing that stuff or using it. It is a negative use cost.
So by using JAD, et.al. we inject hidden costs into the organization's cost structure. And, we inject volitility into the development process. Congrats
Post a Comment