 |
Ignoring Requirements
Posted by daniel on July 17, 2003 at 08:31 AM | Comments (5)
You get a big fat requirements specification document. You know, the one big enough for a three year old to use as a booster seat. You couldn't possibly have read it all -- do you sign it? In Java Today we link to Stephen Taylor's discussion of this issue. In The Experience of Being Understood, Taylor says that in his experience, the business manager always signs to approve a document he couldn't possibly have read himself.
Taylor summarizes the problem as follows:
The development process pretends that the business people use the requirement specification to confirm that the analysts have grasped what they want. But thats not true. The business users dont rely on the requirement specification to tell them this. So what do we rely on?
He answers this question that acceptance of requirements is based on "long conversations about our business and the imagined system". But, he continues, how do we know we're really understanding each other? He offers this analogy.
Consider someone learning to speak, say, Italian. We can distinguish different levels of competence in speakers, from my toilet-and-restaurant Italian (which suffices for holidays, thank you) to the ability to speak like a native. The test for the latter is something like the Turing Test. If an Italian cant tell Italian isnt your first language, you speak Italian like a native. For other levels of proficiency, there are other tests, written and spoken.
In addition in Also Today section we link to Brett McLaughlin's article JSP best practices: The power of time stamps. Brett shows you one way to add a "last-modified" date or time stamp on a JSP page using the lastModified() method.
In today's featured Weblogs Greg Vaughn shares his first entry "How to Become a Java Guru"
. Vaughn encourages you to familiarize with what's already been written. With a reference to Isaac Newton, he advises that you stand on the shoulders of giants and take time to explore new APIs when you approach a new task. Chris Campbell thinks about accessibility and assistive technologies in
"What's the Refresh Rate On Your Tongue". Consider joining the "trend in designing accessibility into products from the start, rather than patching accessible features onto products as an afterthought."
Steve Mallett, the Java Today news editor has gathered the following
Java Today News Headlines : "Apache Maven 1.0 beta10 released", "BEA Releases Remaining WebLogic 8.1 Software", TRON man shuns Gates-like fortune", "An interview with Grady Booch", and "Microsoft Targets J2EE Users with JLCA 2.0".
Once this page is no longer featured as the front page of Java Today it will be archived at
http://today.java.net/today/archive/index_07172003.html. You can
access other past issues by changing the address appropriately.
Bookmark blog post:  del.icio.us  Digg  DZone  Furl  Reddit
Comments
Comments are listed in date ascending order (oldest first) | Post Comment
-
Communication and decisions
I don't disagree with the author and in fact it mirrors my common experience that requirements are ironed out best when talking over things face to face.
What I think the author misses though is that a big value in a requirements document is the recording of decisions. No one, and no group, can remember all of the decisions made when determining requirements. Even if they remember what the decision was they will very likely not remember why options B,C, and D weren't taken. A requirements document isn't meant to be read so much as it's meant to be a resource to look up what the decision was and hopefully why it was the best choice at the time.
One of my biggest gripes with XP is everything is trusted to group knowledge. A customer may very well make a decision in one spat of communication, but a month later when you're demoing the implementation the customer might not even remember that they agreed to X vs. Y, or why. Or you might not even be talking to the same customer representative and the new rep has a whole different idea of what it should be and there's NO documentation to explain why the other customer rep thought differently.
As the author says, communication is great for understanding, but document the understanding achieved because human memory of any specific communication is a pathetically poor reference later on.
Posted by: ckessel on July 17, 2003 at 09:17 AM
-
Communication and decisions
XP says have an On-Site Customer to answer questions and make decisions. It's the job of the On-Site Customer to speak with one voice for Business. If that's not happening, you've got a serious communication problem on the project, rather than a gripe with XP.
I'd start by thinking about whatever is happening that's leaving you the impression of communication happening in 'spats'.
Don't step over it; it's a project killer. You might find it useful to review Chapter 20 -- "Where's the Customer" -- of Auer & Miller's "Extreme Programming Applied" (http://www.amazon.co.uk/exec/obidos/ASIN/0201616408/5jt-21).
Posted by: 5jt on July 17, 2003 at 11:21 PM
-
Re: XP
Hmm, the system gives me an error when I reply so I'll have to start a new post. I simply meant "spat" as in a particular instance of communication, not in any derogatory fashion. The point is still the same though, if you don't document it you're relying on the participants to remember the outcome of the communication, without time distorting their recollection.
Many many times you'll talk to someone about the same thing twice and they'll have different views. Perhaps they've changed their mind, or they understand an issue they didn't before, or they had a headache and gave a poorly thought out response the first time.
And, communication is a 2-way street. If developer Bob quits the team, Ray has to go talk to the customer again on the EXACTLY same issue to understand again what Ray was trying to accomplish. Since understanding is usually achieved over multiple conversations, Ray and the customer will have to start from scratch, slowly achieving mutual understanding. With a document describing what Bob and the customer figured out before, Ray can go into the customer maybe armed with 50% understanding.
Now, 9 months later you're working on a new version, enhancing some previous features. Ray has been promoted, relocated to headquarters out of state, and is no longer around to ask questions. Jennifer is responsible for talking to the customer, but the old customer rep is on maternity leave for 3 months so NEW customer rep B is assigned to the project.
Jennifer has little clue why Feature A does and doesn't work. New customer rep FOO never liked the way the old feature worked anyway and wants to revamp it. So, they both sit down and communicate and achieve understanding and Jennifer goes off and rips out all the old Feature A code and rewrites it.
3 months later Feature A is deliver, customer rep B is estatic. Customer rep A comes back from maternity leave and says "What the hell? My entire department used that feature. I had to explain why we needed that to Ray AND Bob and you STILL changed it. What kind of worthless development organization do you run there where you can't remember a decision? I'm going to talk to my VP about hiring a new contracting outfit!"
Life without documents...
Posted by: ckessel on July 18, 2003 at 08:43 AM
-
Re: XP
ummmmmm ... jUnit test *are* documents, functional documents too boot.
Posted by: gonzo on July 20, 2003 at 10:35 AM
|
java.net RSS Feeds
