From the category archives:

Requirements Elicitation

Requirements elicitation is a core business analyst competency that involves discovering real stakeholder needs and problems. Business analysts use multiple techniques to elicit requirements, ensuring they have discovered each requirement.

The agile movement promotes positive change when it encourages teams to work together to create products that are fit for purpose with as little non-value-added activities as possible. Agile approaches embrace mechanisms for continuous improvement, and include practices that can be traced to Lean thinking, a management philosophy that aims to identify what creates value [...]

{ 17 comments }

While we’ve already talked about the importance of Preparing for Elicitation and Conducting Elicitation Activities, it’s not enough to stop there. The next two (and IMHO, critical) tasks in the Elicitation Knowledge area are Document Elicitation Results and Confirm Elicitation Results. The purpose of Document Elicitation Results is to: Record the information provided by stakeholders for [...]

{ 6 comments }

The User Story:  simple and elegant. “As a ______, I want to _________, so that I can __________.” Why must a user story only be used for Agile projects?  I was at a seminar recently where the speaker kept talking about user stories only in the context of an agile project.  Is there a thought [...]

{ 9 comments }

A reader asks: How much is too much information to go over with the users? Would you go over technical details with users in a requirements meeting? Such as, if there were additional requirements pertaining to a technical implementation of updating mail server, changing AD roles/groups retrieved etc… I would think this would be overkill, but [...]

{ 3 comments }

With the travel itinerary laid out before me, I could see I had a long schedule ahead to get to the project site: three flights, two layovers, one overnight leg, and a 9am requirements elicitation meeting to welcome me first thing the next morning. That was not what worried me though; this was Day 1 [...]

{ 7 comments }

One thing that surprised me as I leveraged the structure of the BABOK to analyze my own BA career experiences is that I tended to rely on some “tried and true” ways to elicit requirements. This was definitely an area where, although I felt very confident in the results I could achieve, I could do for [...]

{ 10 comments }

It’s difficult to even think about being a business analyst without elicitation. Yet, it’s so core, it’s often difficult to abstract from the other BA tasks as well. It seems we are almost always eliciting something – the business need, the solution requirements, our stakeholder’s concerns, assumptions and constraints, etc. While some elicitation will, by [...]

{ 31 comments }

We have two readers ask similar questions of our Help A BA! staff concerning extracting business rules from legacy systems; so let’s help them both out. Reader 1: As rules are mostly hardcoded and code walkthrough is too time consuming in mainframe systems, what is the best way to extract business rules from legacy systems [...]

{ 6 comments }

This journey has had its ups and downs. Like any new venture, it started with buoyancy – or maybe better, that feeling you get when you are heading up the first big hill of a roller coaster. You know you are in for a crazy ride, but right now it just feels good to have [...]

{ 7 comments }

In my last post, Help a BA! How do I get stakeholders to focus on business requirements?, I wrote: As discussed above, it’s not only OK, but expected that the business side will be involved in defining the solution that will be built to address a business problem or opportunity. The solution requirements, which describe [...]

{ 4 comments }

?>