I came across a thought provoking white paper written by John Smith of Rational Software. It's on Estimation of effort based on Use Cases.
If you have ever tried estimation with use cases, you know that the various levels of decomposition encountered in the wild are troublesome. John does an excellent job in conceptualizing this problem.
The article seems to be from 1999, and I'm not sure whether John's ideas made it into the various estimation tools. For me, reading them brought a great deal of clarity in the levels-of-use-cases concept, so I think it's worth reading anyway.
Friday, May 22, 2009
Tuesday, May 05, 2009
Atomic Functional Requirements
The discussion on shall vs. must at Tyner Blain , on which I have blogged recently, triggered me to wrap up what I have learned about atomic functional requirements over the years.
See 3 principles and 4 rules on PlanetProject. Feel free to do responsible changes.
The article explains how to write atomic functional system requirements so that the spec is easy to read, and ambiguity is kept to a minimum.
Note that it is NOT about the even more important (non-)functional user requirements here, in a sense of what a stakeholder expects from the system, which problems shall be solved, what shall be the inherent qualities of the solution etc. I do not intend to argue that any spec must include atomic, functional requirements. But sometimes setup is so that it must. Don't forget to establish the context first.
Now enjoy the article on how to write atomic functional requirements. Thanks for your comments.
Subscribe to:
Posts (Atom)