So you've been tasked to get requirements on a strategic project, and you're thinking to yourself, "How can I make my business requirements documents as incomprehensible as possible?" Going this route may not be just a job security thing. Making yourself indispensable as the interpreter of requirements seems to be the traditional route of delivery and getting buy-in. Just keep running the requirements process until someone gets desperate and finally signs off on the spec in the vain hope of getting something useful for their effort before the end of Q4 2014.
So, some tips and traps for those of you looking to truly perplex and bafflegab your bosses:
- Just give a list of "the system shall ..." statements. Having a few hundred of these statements with no accompanying business process descriptions as a common point of reference to help navigate the swamp will keep the average executive bogged down for days. Their paranoia that something critical got missed might just match your paranoia when they show up at your desk to have requirement 143 explained to them.
- Experiment with similes when describing data objects. No one wants to hear about 'customers' repeatedly. Why not make the document more dynamic and talk about prospects, or accounts, or valued relationships, or partners, or something more interesting. You just shouldn't be overusing simple words repeatedly ... it's boring!
- The use of UML sequence diagrams and class diagrams will help prove to that doubtful executive that you truly understand systems development and have a deep understanding of industry standards. Just loading up their inbox with hefty documents packed with these pretty pictures will have them panting for more.
- Remove all evidence of traceability between one set of requirements and the next. The idea is to produce a set of business objectives and scoping documents in one format and using one set of techniques. Then get your business requirements using something completely different. Go for something truly unique in the system specs. The idea is to show your diverse understanding of ALL the different approaches available to the business analyst. Besides, they are signing off on each document separately anyway... there is no real need to look back at what came before.
- Be snappy with solutions. No matter what the request. Within three minutes of the executive's starting to the grand vision, cut him or her off and begin explaining how the solution is easily delivered by looking at the existing legacy applications. Your attention to promoting existing corporate assets will be well received.
- Tell your CFO that you want to use Xtreme programming on the Basil II financial compliance project. The idea of a programmers eagerly jumping into the breach to resolve important issues for the business should be warming to her heart.
- Tell your outside sales force they need to be dedicated to a requirements discovery session for three weeks. Your attention to thorough detail will be appreciated by the SVP sales.
- Adopt PowerPoint as your primary documentation engine. A few simple screen mock-ups to show the user interface will immediately grab everyone's attention as delightfully artistic. Besides, the workflow behind it should be entirely self-evident to any self-respecting programmer that's been with the company for a few dozen years.
- Make sure the first dozen pages contradict the second dozen pages. Every executive should be presented with options. How could they not like alternatives for the business?
- Drop out key sections of the document and pop these into secondary or tertiary documents. Then refer generally to the existence of these other documents, but don't put in the actual page, or a hyperlink. This is a great way to ensure they read the whole thing.
Hey guys - have fun and add your own. I wish you all great success.
Keith Ellis is the Vice President, Marketing at IAG Consulting (www.iag.biz) where he leads the marketing and strategic alliances efforts of this global leader in business requirements discovery and management. Keith is a veteran of the technology services business and founder of the business analysis company Digital Mosaic which was sold to IAG in 2007. Keith's former lives have included leading the consulting and services research efforts of the technology trend watcher International Data Corporation in Canada, and the marketing strategy of the global outsourcer CGI in the financial services sector. Keith is the author of IAG's Business Analysis Benchmark - the definitive source of data on the impact of business requirements on technology projects.

written by Vinu Shankar, May 19, 2009
Vinu
written by Diana Ryan, May 19, 2009
written by Kristin Zaharias, May 19, 2009
written by Jim Freel, May 19, 2009
written by Christine miller, May 19, 2009
written by David Wright, May 19, 2009
written by Steve Hogan, May 19, 2009
written by Rizwan Khurshid, May 20, 2009
Thanks,
Riz
written by Michael Cornell, May 21, 2009
A good BA needs a good sense of humor. We've all been in those strange requirements gathering meetings...
written by Doug Goldberg, May 22, 2009
the absurdities of our analysis world demand that we take a step back, suck in a little unpolluted air, and laugh until our bellies hurt.....so we can do it all over again tomorrow.
written by Tze-Chiu Lei, May 27, 2009
written by Scott Pollino, June 04, 2009
A visual model for an executive will look much different than the one you pass to your infrastructure architect.
http://www.linkedin.com/in/scottpollino
written by Patrick Wong, June 08, 2009
I truely believe a green BA could not use the above "Tricks" to gain respect, but a real productive experienced BA could. Take Point Number 10 as an example, before you could maunipulate a "Key Section", you should know what is "Key" and shuffle it to an adequate subsequent document, It sounds trival, but I believe not everyone could do it nicely, it is definitely not easy.
Then, when the executive come to you, could you link all relationshop and depict the whole things by your own speech? If you could you are the audience of this excellent article.
written by leslie munday, July 07, 2009
Here are some others:
11. If you have a really important requirement, make sure that you repeat it several times in the document, to ensure that the reader does not lose sight of its importance.
12. Put all the requirements information into a single document (including version history, project team members, phone numbers, addresses, change requests, glossary terms and issues) that way readers in need of this information only have to look for it in one place. This is more important the larger the project.
13. Don't waste time defining common words in a glossary. Readers can pull up their definition from an English dictionary.
14. (I believe the author already caught this one, but it is worth repeating) Keep you readers attention by varying the use of words to explain similar requirements. For example don't keep repeating 'The user enters' information, but introduce words like 'inputs', 'types' and 'keys-in'.
15. If you are not sure whether the information is needed in the requirements document, put it in, just to be sure.
16. Documenting procedures for changing the requirements document is a waste of time and just causes confusion amongst the authors. Let each author have their own copy of the document and merge them together when it comes time to release.
Leslie.
written by Pat Maher, July 08, 2009
written by Rainer Thiel, November 04, 2009
@dwright: You are spot on!
Oh, and fwiw, heres a further extension to the useful points about keeping the language lively:
Make extensive use of a Thesaurus, and also, never provide synonyms for anything. Maybe have a glossary, but it should never be anything more than a long list of words, preferably unordered. That way you can hide lots of repetitions. Descriptions, explanations are actually a waste of time. Remember you are dealing with a very smart community of stakeholders who are already in perfect agreement on the exact meaning of any terms or phrases you bring to the table. ;-)
Keith Ellis is the Vice President, Marketing at IAG Consulting (

I get that its trying to be funny but with so many people either out of work or on the verge of being dropped, I think this entry was ill-timed. Believe me, I'm not one to take myself too seriously but this one feels like a serious waste of space.
Here's to hoping the next one will be back on track.