Writing good requirements requires a few key ingredients in your approach as a business analyst;

1. Understand the business inside out .. forget about the software for a while.. talk to people, gather data, put all the data together, don’t let a single conversation slip you. I have been eavesdropping all my life .. on all sorts of business discussions.. the more you understand the business, the more likely to deliver value as a business analyst. Write all the business policies, business rules, document the processes as a side job. It will become of immense value later on..

Do not document what you do not understand or what you have been told to write. This is a different job, not yours. If you can not understand perfectly the current state of a business, you can never deliver what improves its future state. When you navigate the business from various points of view, that of the CEO, the head of finance, the sales director.. and through the eyes of the staff, you will have the collective understanding and knowledge of everyone else .. read any document you get your hands on… Ask a lot of questions, the same questions to different people.. Digest the business fully.

2. Carefully analyze your stakeholders, they are the decision makers. Profiling stakeholders are always skipped but it is one of the key success factors in software delivery. Make sure they are well-informed about the facts and if they too are busy, drop a keyword as you run by them to get their attention. They will come to you for more data when they have the time. You must give each what they want from your solution proposition and treat everyone as they expect to be treated. Some stakeholders are micromanagers, control-obsessed.. give them control under your eyes instead of them trying to grab it behind your back. Some stakeholders are too threatened and scared .. don’t corner them with a decision or a signoff.. seek other influence points who can take the responsibility for their actions.

3. Use the right techniques despite the lack of knowledge, you can always educate your project team on new techniques adopted but do not choose inappropriate techniques which miss the angles you need to tackle. Of course, you must be first aware what are the available business analysis techniques and how is each one used and when.

4. Use a requirements management tool, stop using word, excel and email .. work smartly.

5. Adapt with the changes around you but don’t surrender to them. Adaptation does not mean lowering the quality of your deliverables but try to swim along the current of the business you are serving without the slightest affect on requirements quality. Some organizations make fatal business decisions .. not out of ignorance but out of a rush or an external pressure.. clearly state your objection and don’t be afraid to have an opposing opinion. that’s your job .. Sometimes you will discover that the development team have already began building something and you are assigned to analyze a few weeks later… adaptation means that you can still join the project but forget what was developed start as your normal .. don’t twist your solution proposition to the initiated solution construction.

6. Try to stick to a framework, a standard approach in how you work. Standards are designed by domain world leaders and are meant to help us from re-inventing the wheel.

7. Think Alone.. you can elicit requirements, gather data and brainstorm but think finally alone.. Thinking alone is priceless and something which is most commonly avoided, I have no idea why!

8. When you finally write, specify and model your requirements and solution design ensure it does not raise any questions from all the types of readers who shall be your audience. Review, Review and Review … Ten times if needed. An hour of your review or peer review will save hundreds of hours in development and testing .. and hundreds of thousands in operational expenses.

9. Ensure that you are responsible for Post-Implementation Solution Evaluation after quality testing and prior to User Acceptance Testing. There will be a lot of resistance to letting the Business Analysis team verify a solution but seeing the actual software will raise issues you could have missed, especially in big software systems with over ten or fifteen software components. It is wise to verify yourself before your business acceptance team start the transition phase. This is not wasted time, this is saved time. Many Business Analysts, especially leads avoid this aspect of our job dreading the responsibility of the delivery. It is your responsibility anyway so do it right and save yourself the shame.

Written by: Angie M. Eissa, CBAP, MSc BIT, UK Founder & Managing Partner of Business Borderlines