News Stay informed about the latest enterprise technology news and product updates.

Business analysis and requirements elicitation: Interview with Ellen Gottesdiener -- Part one

In part one of this two-part interview with EBG Consulting's Ellen Gottesdiener, we learn about techniques used to elicit requirements and hear about the differences between Agile and traditional requirements elicitation.

Let’s face it. Business analysis and requirements is considered by many to be the most challenging part of application lifecycle management. Ellen Gottesdiener of EBG Consulting is an Agile coach and trainer with a special interest in Agile requirements. She is a writer and speaker and will be presenting at several upcoming conferences including Agile Development Practices West , Agile 2011, and STARWEST. In this interview, Gottesdiener tells us more about her upcoming workshop and give us insights into Agile techniques used for eliciting requirements. Read part two.

SSQ: You’ll be part of a team facilitating a two-day Business Analysis and Requirements Workshop at Agile Development Practices West. Can you start by telling us the logistics of how that will work? Will you be emulating gathering requirements for a particular project? Will the workshop be relevant regardless of domain area?

Ellen Gottesdiener: As conference chair, I wanted to put together a team of people who represent a cross-section of business analysis and requirements skills. I also wanted our presenter/facilitator team to be composed of folks with solid knowledge of traditional as well as Agile practices. We have that with our team: Joy Beatty, Kent McDonald, Ken Pugh, Linda Rising, Doug Talbott, and me.

Business analysis -- and the good requirements that result -- is increasingly important for both strategic planning and tactical product delivery. Business analysts require multiple skills: strategic thinking, requirements modeling, requirements elicitation and communication, business architecture and user experience, and customer relationship management. And, they need to be able to adapt analysis practices for traditional and Agile projects.

Because the two-day workshop agenda incorporates sessions focused on these skill areas, I chose the metaphor of a playbook, like the ones football teams use: in addition to skills and knowledge, analysts need a diverse toolkit of methods and practices. 

Here’s how it works. We start and end each day as a community to prepare and retrospect, continually focusing on our playbook. In-between, we are holding parallel tracks so attendees can focus on practices they need or want to improve in their playbook. Our sessions include opportunities for people to practice eliciting, analyzing, specifying and validating requirements. 

An aside: in the analysis and requirements realm we prefer to use the term “elicit” vs. “gather,” since requirements are not just sitting around waiting to be picked up.

Some sessions will cover higher-level topics such as strategic thinking. The idea is to learn how to focus on the right things in the first place, and on essential customer collaboration practices that work.

We are using the same case study throughout the sessions, so participants can practice skills across sessions within the same problem domain. However, the practices we are sharing are useful regardless of the specific domain you work on “back home.”

SSQ: Are the techniques used for business analysis and requirements elicitation different on Web projects than say, embedded software projects?

Gottesdiener: Higher-level practices such as strategic analysis, communication, requirements modeling, and verification and validation are valuable regardless of project type. What differs are the specific elicitation techniques and analysis models you employ to reach a shared understanding of product needs, or requirements. 

Let’s start with elicitation. Elicitation identifies the sources for requirements -- typically stakeholders and documentation -- and develops requirements from those sources. You employ a variety of elicitation techniques. These techniques include exploratory prototypes, facilitated workshops, interviews, observation, focus groups, task analysis, research-based study (such as existing documentation or surveys) and the like.

The project types you mention -- Web and embedded -- define the technologies used to deliver the solution. In both those cases, you need to understand stakeholders and elicit requirements. Because Web-based projects have a strong human focus (versus a machine focus in embedded projects), you draw on human-focused elicitation practices such as workshops, observation, and task analysis. Embedded projects benefit from research-based study. However, for both types of projects, I strongly recommend prototypes, which have the dual benefit of exploring and validating needs.

Analysis enables stakeholders to build a shared understanding of the product requirements so they can prioritize needs and allocate requirements to software. During analysis, teams typically build requirements models in both text and visual form.

Holistic analysis of product requirements includes four functional product dimensions (user role, action, data, and control) and three nonfunctional product dimensions (interfaces, quality attributes, and design and implementation constraints). This is what we at EGB call the “7 Dimensions” framework. Analysis tools for each dimension vary. For example, to analyze user roles, you can employ personas, user role maps or actor descriptions. Or you can define the action dimension using features, user stories, use cases, process models and the like.

Web-based projects typically focus on the user role, action, interface and quality attributes dimensions. Powerful choices here are analysis models such as personas, user story maps, prototypes or wireframes, and clear definitions of usability and performance, which are quality attributes.

Embedded projects are typically concerned with the data (or device state), control, interface and quality attribute dimensions. Depending on the embedded product’s domain, it’s most crucial to analyze events, state diagrams, decision tables, system-to-system interfaces and a variety of quality attributes such as reliability, performance, efficiency and safety. 

And, for both types of projects, I strongly recommend scenarios, which can help drive analysis artifacts and seed acceptance criteria.

SSQ: What are some of the differences in requirements elicitation in an Agile environment vs. a traditional environment?

Gottesdiener: Agile projects focus on delivering the near-term needs that offer the highest value. Business, customer and technology stakeholders on Agile projects need to learn, as frequently and continually as possible, whether they are delivering the right product increments and achieving the anticipated value. Unlike traditional projects -- where elicitation happens mostly up front and culminates in one or a series of documents -- elicitation is continual on Agile projects.

Elicitation on Agile projects is necessary for discovery and preparation. Discovery enables you to populate the product backlog with credible backlog items -- ones that are feasible, desirable, aligned to your strategy, and provide sufficient value. To deliver, you first need to prepare your backlog items. Preparation entails elicitation and analysis -- what we call grooming, pruning, or refining backlog items --so you can estimate and commit to delivering a subset of high-value requirements in a short timeframe. For both discovery and preparation, Agile projects employ high-throughput elicitation practices such as short, lightweight modeling sessions, prototypes and user acceptance tests.

Read part two.

Dig Deeper on Topics Archive

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.