The BABoK (Business Analyst Body of Knowledge) lists 10 techniques for gathering requirements. Here’s an overview of each one. For more details, check out the latest Guide to the BABoK.
Business Analysis / Requirements / Writing
Posted on:
Pairing Business Analysts
Pair programming is a bit of a foreign concept for many people in business. A few years ago, it was foreign to most programmers too. Pair programming is a powerful technique for software development because it allows two people to look at the same problem/solution from two different perspectives at the same time. Would that same approach work for business analysis?
Business Analysis / IIBA / Organizations
Posted on:
First IIBA Certification Exam And More
This is a bit of a potpourri post. Found some good stuff out there today, check it out. The first IIBA Exam just finished in Orlando Florida. Barbara was one of the 16 business analysts who took it. Read about her experience! Her post has inspired me to crack open […]
Business Analysis / Product Management / Requirements / Writing
Posted on:
Writing Correct Requirements
We ran a series called Writing Good Requirements – The Big Ten Rules in May 2006. Bloggers are notorious for not being able to count. We had ten rules at the time, and now we’re adding an eleventh. Writing Correct Requirements may have been the unwritten rule, but now we take a look at it.
Business Analysis / Communication / Requirements / Software requirements specification / Writing
Posted on:
Another Use For ‘Why?’
“Why?” The question is our inspiration and our muse. “Why?” is the justification for our requirements. The key to identifying “What?” and “When?”, which lead to “How?” and “How Much?” But there is another use for “Why?” – communication of intent (with stakeholders and implementers). Requirements documents are artifacts, but they are also dynamic documents. By documenting “Why?” a requirement is a requirement, we make it easier for future readers to understand.
Business Analysis / Requirements / Requirements gathering / ROI
Posted on:
Don’t Prevent My Success
Finding the right balance when defining requirements can be hard. On one side, we want to avoid an inadequate system – “Don’t prevent my success by excluding features I might want”. On the other side, we want to avoid cost-overruns, delayed schedules, and negative-ROI features. This can be a hard line to walk.
Business Process Modeling / Product Management / Requirements / Requirements gathering
Posted on:
Business Rules And Requirements
What is the difference between a business rule and a business requirement? Does the difference matter? A business requirement is something that is multi-customer, and a business rule represents a single customer’s approach to meeting that requirement. Product managers and analysts care about both, but product managers emphasize requirements, and analysts focus more on rules.
Business Analysis / Requirements / Requirements gathering
Posted on:
How Many People for Requirements Elicitation?
How many people should be involved in requirements elicitation? A question from one of our readers via email. Hi Scott, in the last months I faced the issue of managing the requirement elicitation phase in an Identity Management project. I have a very simple question. In your opinion how many […]
Business Analysis / Product Management / Requirements
Posted on:
Wants and Needs
When a client asks for a capability or feature – is it a want or a need? How do we prioritize them?