Archive of Writing Articles

Too many companies don’t document their requirements.

Worse still, too many companies over-document their requirements.

Tony just put up a post at Seilevel’s blog on making sure your spec is reviewed.
Kent Newsome recently posted about starting cross-blog conversations here, possibly inspired by Amy Gahran’s post about it here. Tony’s post is a great topic to cross-blog about.
Three easy steps to blogversation

Post your contribution
Link to the other posts [...]

Thanks to the download squad for pointing me at the Juicy Studio: Readability Test! You can go to Juicy Studio’s site, and calculate the reading level of any URL.
Of the multiple analyses provided, the Gunning Fog index is the easiest result to read - it is a proxy for the number of years of [...]

I’m having a little trouble reading the spec - I left my secret decoder ring at home!
Ever hear that before? A set of requirements that makes perfect sense to one team member can be completely unintelligible to others. Requirements written in business-speak, or full of accounting jargon may be unintelligible to the development [...]

I attended training on making compelling presentations last year - and one thing that was stressed was the use of imagery to drive points home. Although there have been images in my posts to date, they have been utilitarian - not sources of imagery. I need to do better with my writing.
Thanks to [...]

Object oriented analysis and design (OOA/OOD) is a technique used to gather requirements and develop software, as an alternative to more traditional text-based techniques.

OOA allows for clarity of communication, by creating descriptive and unambiguous documentation of requirements. It comes with a great big giant caveat –

People who elicit and manage requirements – product managers, business analysts, program managers, and others – also orchestrate and communicate with their clients. In an enterprise software project, the requirements manager (RM from here on out) has to communicate with people across the client organization. To pass along information, gain support, and gather understanding. Plus [...]

Don’t do it. Don’t use a functional spec to get superficial agreements and navigate the beurocracy that accompanies large projects. Don’t validate the specification trivially. Don’t deploy with a waterfall process (the spec is done, whew, now - on to design) and never revisit the spec. Don’t work with new developers, or remote developers, or anyone else who doesn’t have the context of direct eyeball-to-eyeball conversations with the customers. Also don’t hire any programmers without complete domain expertise in the customer’s business