Recently, Claudia Capelli called my attention to an IEEE Software Article with the title "Nurturing Requirements". The article was written by Dave Thomas and Andy Hunt who call themselves "T h e P r a g m a t i c P r o g r a m m e r s". The short article can be found here.
Claudia, who is working towards her Ph. D., liked the way the article points out to the fact that requirements are in constant change. The article is straight to the point.
Foster, bring up, nourish requirements. Is that the right way? I believe it is. Remember: requirements are a never ending story.
Is it ok to conclude the article with the sentence: "So, while you’re reading the rest of this issue about requirements and process, remember one thing. Requirements aren’t engineered; they’re nurtured."?
It is not! Despite the fact that requirements will evolve as " a complex, multi loop
multilevel feedback system" (using M. Lehman words), requirements elicitation, modeling and analyis must be done the proper way.
Which is this proper way? Answer: use a requirements engineering process. What is the catch? The catch is on using a proper process, which must be tuned to the case at hand.
Requirements evolution, or better software evolution has been a research topic dear to me for almost 10 years. We have introduced the concept of a requirements baseline which is in constant change, but is also the base for the required software.
By the way: if the title reminds you of something, probably it is the movie, or its originator´s book.
2 comments:
To me this article primarily demonstrates what a poor job the research community has done in expressing its findings to practitioners like the two authors. Many of their terms and ideas -- constraints, hopes as NFRs for e.g. -- mirror exactly some work in academia. But they seem ignorant of this.
I like the agile idea, but I think it hasn't been the subject of sufficient theory testing -- does it reduce cost overruns? build better products? We have lots of apocryphal 'yes' answers but no good, sound data. That is an area I'm interested in investigating.
I'm also not sure how well the house metaphor holds for agility. Most of us don't have the unlimited budget to build a house like this. And if we do make changes, usually that results in major delays. Certainly the building industry is similar to software engineering in that aspect, for e.g., the Montreal Olympic Stadium.
Neil Ernst
Toronto - Requirements Ph.D. student
Neil,
Yes. Peter Freemnan likes to say:
"ideas are cheap, data is dear".
It is hard to find hard data for support for agile methods, but look for the recent xp/agile workshops. If I recall right there has been some experimental studies on the subject.
A place to look is at University of Calgary.
jcl
Post a Comment