FACT #1: The Standish Group’s 1994 Chaos Report found that the top three project impairment factors across 352 companies and 8,000 projects were
- Lack of user input (12.8% of respondents),
- Incomplete requirements and specifications (12.3%), and
- Changing requirements and specifications (11.8%)
FACT #2: Almost 50% of defects identified during testing to be due to defects in requirements. Source: “Calculating your return on investment from more effective requirements management.”
How does one address this? Let’s first understand the processes and tools that are in place today.
- Development Process (the way we do it)
- Waterfall
- Iterative.
- eXtreme Programming
- RUP
- Tools (the hammer and tongs of it)
- Word, Visio, Excel, Power Point (all are documents)
- UML – Visual Paradigm, Rational
- Experience (hey cant dismiss that)
- Business experience (Knowing the business is critical)
- IT experience (What do we have, what do we need to build, the know how and prior experience with similar requirements)
Notice something?
While we have tools and processes that define the way we do it and have the tools and experience to execute, we seem to have ignored the big-fat-white-elephant-with-a-pink-ribbon sitting in the room all along. Change.
With every development project that we undertake, with the changing business, we are faced with change. From simple ones such as I-really-don’t-think-we-need-to-have-that-up-there-in-bold or can-you-make-the-text-label-SS#-instead-of-SSN?, to more esoteric and convoluted ones such as you-know-some-of-our-users-really-don’t-connect-to-the-internet-to-use-the-application or this-report-really-should-pull-data-from-our-old-Cobol-systems. Where are the tools required to control those ceaseless changes?
Simple question: So how does one control change?
Simple answer: You cannot. Change is permanent. You have to manage it.
In any requirements gathering exercise,
- Recognize the responsibilities of each group
- First, understand that requirements definition is a shared responsibility. Both the business and IT have equal stake in this process.
- Business team
- Describe business requirements in a simple language, preferably with ‘real world’ examples – and leave design and implementation to the IT.
- Prioritize. What do you really, really, really need? What do you really, really need? What do you really need? What can wait until the next release? Do you need to system to perform that function for you? Consider the bang for the buck – IT cannot tell you what is critical to your business.
- Signoff on all the documents, only after satisfying yourself that we have covered all that you need, accurately and appropriately. – RTFM
- Inform IT in advance about changes to business needs / scenario – do not wait until ship date to start hmm and hawing
- IT team
- Spend time to understand the business, the business goals and the business context – it’s not all about code.
- Identify functional and nonfunctional requirements – do not mix ‘em up.
- Inform the business and all stakeholders regarding development progress and problems in a timely fashion – if you are going to miss a ship date, then the business needs to know, and who knows they might re-prioritize, and you could get to push that nasty little corner-case functionality to the next release. Hey not all change is bad
- Get a good grip and over view of the entire system, so that you can effectively predict the downstream impact of changing requirements plus. You’ll know what can and can’t be done, and more importantly, what shouldn’t be done.
- Recognize the mode of expression
- Word documents don’t always tell the story effectively
- Not all requirements are describable in any one tool – mix ‘em up.
- Some requirements may be lying in undocumented live applications – legacy code is not always bad.
- Model Processes– work shops, walk-through’s, scripted role plays, Visio, flowcharts, UMLs
- Mock ups – WYSIWYG, but don’t get carried away
- Recognize the role of the business analyst
- At the crux of the business user and the IT staff lies this hybrid artificially created creature.
- Many business analysts sadly and erroneously confuse themselves as to be the business users – they need to align themselves as the bridge, the go-between, the translator.
- Other business analysts have their thinking clouded with prior application design knowledge, and try to ‘out think’ IT.
- IT personnel playing the business analyst begin to dictate requirements based on personal design principles or beliefs.
- Recognize the appropriate software tool
- There are several specialized tools out there in the market today that address specific needs
- Requirements definition
- Axure RP, Borland DefiniteIT, Compuware Optimal Trace, iRise, Ravenflow, Serena Composer, Sofea Profesy apart from modeling tools (such as Microsoft Visio) Microsoft Office, Graphics packages (e.g., Adobe Illustrator) HTML etc.
- Requirements management
- Borland CaliberRM, Compuware Optimal Trace, IBM Rational RequisitePro, Serena Dimensions RM, Telelogic DOORS, Test management tools, Change management tools and even and homegrown applications
- Research these tools and ascertain the best-fit in terms of
- Usability – are your business users, business analysts and developers all comfortable with the tool
- Life-cycle worthiness – can you use the tool from start (project conceptualization and initiation) to finish (several iterative changes later unto the final release and maintenance phases) seamlessly
- MS Project is not a tool for requirements management.