Key Word Definitions for Requirements Documentation

Sometimes it’s a good idea to take a step back and look at what the words mean that you are using in your business requirements documentation. Sometimes it may even be a good idea to add a definitions section to your document and explain what they mean… MUST – this word, or the terms “REQUIRED” or “SHALL”, mean that the definition is an absolute requirement of the specification. MUST NOT – this phrase, or the phrase “SHALL NOT”, mean that the definition is an absolute prohibition of the specification. SHOULD – this word, or the adjective “RECOMMENDED”, mean that there […]


Eliciting Requirements

During requirements sessions, it’s your job as the BA to not only capture the requirements you’re being given, but to facilitate discussion about those requirements and taking the conversation to a deeper level. Here are some things you can do to help with that process: Appear Clueless In order to foster expanded discussion, you should ask silly or frivolous questions. Put yourself in the position of being “clueless” about the process you’re discussing so that others will correct you and explain the options, the true nature of those options, and why they chose the direction they did. This will help […]


Screen Mock Ups

A question was recently raised in a group on LinkedIn regarding UI Design.  The question was if BAs should be doing UI design. While some BAs may be capable of doing UI design based on previous experience, I don’t believe complete UI design should rest on the BAs shoulders.  I do however, think they should provide a starting point for the UI designer/development team. Here’s my response from that posting: In my experience, as the BA, I have created screen mock-ups as part of my requirements package – usually included in the business requirements document or sometimes as part of the […]


Project Re-work – The Need for Better Business Requirements Analysis

I found the article “As if Re-Work Wasn’t Enough” to have some interesting statistics and good information on why we frequently spend large amounts of our budgets on re-work. As business analysts, we need to ensure we not only capture clear, concise requiremetns, but also necessary requirements. I’ll continue saying this – we MUST analyze those requirements we are given. Do not take them at face value, ask questions, ask questions, ask questions. Ask until you get down to the true requirement and then ask some more questions to make sure the requirement is truly necessary. “Studies show that somewhere […]


What is Agile Development – Simple Words, Please

I was recently asked in a group discussion on LinkedIn to explain in simple terms what Agile means. I was thrilled to respond to that question because it sums up why I started my analyst coaching business. There is a lack of information out there for IT analysts that puts things in simple terms and gets down to how you do your tasks, not just what tasks are expected of you. I had several responses in that discussion thread that thanked me for putting this in simple terms and some people said they didn’t really understand what Agile meant until […]


The Art of Note Taking

Taking notes during requirements gathering sessions can sometimes be a daunting task. If you have a room of 15 very vocal business partners and subject matter experts, it can be difficult to take notes and keep the meeting on track. I have had questions around note taking from my clients and I want to give a few pointers for this. If possible, have another scribe in the room. Take notes yourself, but also have a back-up note taker as well to help ensure you capture everything. Make sure you capture any action items that come out of the discussions. When […]


Business Analysis Documentation

Saw this question on a BA forum; I’d love to see your responses. What is the most important document produced by a business analyst and why?


Benefits and Challenges of Creating Use Cases

Benefits of Creating Use Cases The use case helps us to understand and shape both the problem we are trying to solve as well as the solution to that problem. Use cases capture operational requirements from the user’s perspective. It gives a clear and consistent description of what the system should do and is understandable by all stakeholders – Users, Developers, Business Partners. Use cases are an excellent source for the testing team. Use cases help testers with test script writing and as a source for information during testing. Use cases provide the ability to trace functional requirements into actual […]


Get in touch today

Speak directly with The Analyst Coach
and get pointed in the right direction.

Preferred Contact EmailPhone

Subscribe to receive our free white paper on how weak requirements effect strong companies


Sign up to get your FREE Business Analyst Survival Guide

Don't worry, we hate spam too. We will never share your information to third parties.