Estimation with Use Cases: Deeper Thoughts

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.

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.

Tweets from Rolf

Just in case you're interested and did not notice, you can follow me on Twitter using http://twitter.com/rolfgoetz

Shall or must to markup mandatory requirements?

Generations of Business Analysts before me had to decide which auxiliary verb to choose in a mandatory system requirement. "Shall", like in "The system shall..." is probably most widely used in the English spec-writing world. But is it a good idea?

Scott Selhorst of Tyner Blain did some research using a novel research method on how ambiguous shall and must are. The bottom line: if for any reason it might not be clear to some reader that shall means mandatory, use must (consistently throughout the spec, of course, and put the convention in your requirements management plan).

I think the shall (as opposed to must) dates back to the old MIL-STD 498, or even DOD-STD 2167A.  And anyone who "grew up" BA-wise in the military or air traffic control fields like me, is very accustomed to the shall, and must might sound too harsh. But, hey, here's my favourite answer to that: "You're writing a spec, and you're not gonna win the literature Nobel prize for it!"

Interesting enough, as Scott points out in his article, in many languages other than English shall is not really used for the meaning of mandatory. In German, for instance, the meaning of shall is much closer to should than must.  And we all know what happens in waterfall projects when acceptance testing is due and the developer has implemented only half of the should requirements...

Writing Many High Quality Artefacts - Efficiently

I finished a process description on writing many artefacts, like use cases, requirements, book chapters, test cases, in high quality with the least effort possible. Please have a look, I'm eager to see your comments. After all, it's a Planet Project wiki article, so if you feel like it, just edit.

This, again, is on evolution, or learning by feedback. Makes heavy use of inspections. Inspections BTW, are one of the most effective QA methods known in software engineering history, according to metrics expert Capers Jones.