Business Analysis: The Elicitation Process

This article covers the phase of gathering requirements from stakeholders.

Requirements Elicitation. A Project's Foundation

Gathering the requirements that must be accounted for in order to achieve a project's goal is the process that forms the foundation for its success. The BA typically has responsibility for managing this phase. Requirements elicitation is the set of activities where information is given by stakeholders, users, and customers to be applied to the design of the initiative or the solution.

Elicitation is a perpetual process during a project development. It is not a stagnant, compartmentalized activity. As issues arise, information gaps occur or new requirements evolve, the BA must initiate or continue elicitation of stakeholder input. The project's success depends upon the accuracy, completeness, and detail of the stakeholder requirements. Eliciting requirements not only involves obtaining documented criteria but also uncovering latent or potential needs.

Though techniques for gathering requirements may be common, the deliverables are difficult (at best) to define. Typically the BA is dealing with a variety of input points (that is, IT, sales, and finance) where each has a different documentation and reporting structure, often along with a unique culture and language. Strong organizational and communication skills are required during this phase, as it is generally up to the BA to shape the information into models, diagrams, and other tools to communicate the findings to decision makers and to team members.

Enterprise opportunities, restrictions, assumptions, and current reality are all reflected by stakeholders during requirements elicitation. The BA must be able to resolve conflicts between requirements, eliminate the potential for conflicts (if possible), and achieve consensus among team members and stakeholders as requirements are defined and prioritized.

When considering elicitation activities, the BA must develop strategies for two primary functions: Preparing for Elicitation and Conducting Elicitation.

Requirements Elicitation Functions

Elicitation Process

There are several effective techniques a BA can use to obtain requirements. Each method has strengths and weaknesses that affect the quality of the requirements that are elicited. The BA must base his decision on which techniques to employ by determining 1) what methods are appropriate for both the stakeholder and elicitor, and 2) what methods will capture the requirements most effectively and efficiently.

Method #1. Brainstorming

Excellent for generating ideas, brainstorming involves bringing stakeholders together to discuss the project's objectives and suggest potential needs. The group's mission is to create a broad set of opinions, ideas, definitions, or to explore possibilities about a requirement set. This method encourages diversity of thought and creative input. The participants will focus on an objective and present as many requirements as possible, then the BA distills those solutions into a defined set of needs.

STRENGTHS: Ability to elicit many requirement ideas quickly.

Allows free thought without restrictions or compartmentalization.

WEAKNESSES: Participants must be creative thinkers

Method #2. Document Analysis

Document analysis is usually performed to elicit information pertaining to an existing process or structure. This method may be necessary to employ when a subject matter expert is no longer with the organization or not available for elicitation. Though limited to published material, the BA can gather adequate details about current attributes, rules, or behavior.

Some of the documents that the BA can analyze include:

· Contracts.

· Training Manuals.

· Work Statements.

· Policy Manuals.

· Business Plans.

· Requests for Proposal (RFP).

· Market Studies.

· Comparative Product Reports.

· System Files.

The BA must first determine if a document is applicable or relevant. He can use the information gathered with this method to construct follow up elicitation through other techniques; because of this, document analysis is typically done early in the requirements elicitation process.

STRENGTHS: Leverages existing material, not starting from scratch.

Provides means to cross check other elicitation methods.

Can provide significant detail about current attributes.

WEAKNESSES: Limited to as is information.

Existing documentation may be out of date or incomplete.

Finding relevant information may be time consuming.

Method #3. Focus Group

When the BA seeks to gather shared attitudes, needs, or preferences, he can form a focus group to elicit requirements. A small collection of stakeholders shares ideas and thoughts with the help of a moderator. A session can be conducted in one room or through an online meeting. The results are generally qualitative, not quantitative. A focus group can convene during any phase of a project life cycle.

The group generally consists of six to twelve participants, and the topic may influence who is chosen to participate. For example, if the group is discussing a business process, then the attendees will likely come from business areas that impact the process.

Group composition can be either homogeneous or heterogeneous. A homogeneous group is made up of members having similar characteristics and perspectives, such as within a single work area. Though this type of group would provide a comprehensive view of a single attribute, it lacks a broad perspective. A heterogeneous group consists of members with diverse characteristics and perspectives. This group can be effective when attempting to gain a broad perspective about the topic (though unfamiliarity with other members may limit the quality of responses).

STRENGTHS: Can save time and cost by eliciting many requirements in one session.

A healthy interchange among members is effective to elicit attitudes and perspectives.

Want to learn more? Take an online course in Business Analysis.

WEAKNESSES: Does not generally produce numerical data or other metrics.

Homogeneity may reduce completeness in gathering requirements.

Participants may be unwilling to openly share thoughts within the group.

Scheduling may affect timing of requirements elicitation.

Method #4. Interface Analysis

By conducting an interface analysis, the BA observes how a system interacts with users and other systems. This method is used frequently with projects involving IT components. It can be conducted with both internal and external systems and users. Requirements are traced to specific functions carried out by the system or hardware involved in the process. The BA can uncover potentials, limitations, functionality, and operability between systems or hardware.

Interface analysis can provide significant detail about inputs, outputs, and systemic dependencies, but is limited in providing stakeholder perspective and nonsystem requirements. However, the BA can easily determine system needs based on this method.

STRENGTHS: Provides valuable detail about which system requirements are necessary.

Saves time and expense by enabling the BA to accurately determine

testing and integration requirements.

WEAKNESSES: Does not provide a complete understanding of business process requirements.

Method #5. Interview

The BA can choose to conduct a one-on-one or group interview to elicit requirements through a series of questions directly asked to stakeholders, end users, or subject matter experts. The interview can be structured or unstructured, conducted in a formal or informal system. Questions are either open-ended (eliciting a thoughtful, expressive response) or closed-ended (requiring a direct, coded response).

The key to accurate requirements elicitation using this method is to determine the most appropriate interview subject and designing the most useful questions. Follow up questioning should be used to clarify vague, incomplete, or hard to understand responses. The interviewer must present the questions in a logical order to enable the BA to understand the complexity and dependencies of the requirements.

STRENGTHS: Provides a simple, direct way of eliciting requirements directly from stakeholders.
Maintains focus throughout the elicitation process.
Allows for complete explanation and discussion of attributes and needs.

WEAKNESSES: Doesn't allow BA to reach consensus among stakeholders easily. Requires substantial time commitment and stakeholder involvement.
Interviewer must be highly skilled in order to generate appropriate information.
Subject responses generally limited to their business domain.

Method #6. Observation

An effective method of understanding a stakeholder's needs is through observation of his work environment and process flow. Sometimes called job shadowing, the BA follows a subject matter expert or end user through the business process to be improved or re-engineered. This method establishes a baseline from which modifications can be made.

The observation can either be done passively or actively. Passive observation requires the BA to simply watch the business process without involvement or discussion. Active observation involves discussion with end users and/or performing functions within the flow (hands on approach). The BA must be wary of becoming a disruption while conducting observation. This method can involve either a demonstration or actual work in progress.

STRENGTHS: Provides actual and practical insight to current work flows.
Elicits information that is not captured through documentation or questioning.

WEAKNESSES: Provides requirements only on existing systems, structure, or process.
May be disruptive to business unit.
Limited observation period may miss unusual occurrences.
Responses to issues can be time consuming to observe entire process.

Method #7. Prototyping

When a product or a system tool is to be developed or adapted, building a prototype (model or mock up) can enable the BA to uncover construction attributes and process flow. IT projects usually involve using screen shots and layouts to develop interface stages and functions.

The two objectives the BA seeks to fulfill by using prototyping are 1) to determine the functional scope of the method and, 2) to determine the use of the prototype. Within the scope, the prototype is developed in a way that exhibits the depth of the issue or the need that the initiative will address. A horizontal model represents a shallow, but wide view of a product's makeup, for example, a series of computer software screen shots without the functionality behind them. A vertical model is designed to exhibit a narrow view composed of several layers of a system or product; for example, a self-contained DVD player model to be installed in a computer.

Once the scope for the prototype has been determined, its use in the product development cycle must be defined. There are primarily two model uses:

1. Throw Away Model. By using rudimentary tools, such as drawings or plastic model parts, the prototyping can quickly reveal the framework of the product from which the attributes can be determined. It is discarded when the final system is in place.

2. Evolutionary Model. As part of the ongoing development, this prototype is extended from an initial design through full implementation. It becomes part of the system.

STRENGTHS: Supports visual, multi-dimensional expression of the requirements. Allows user interaction with model and early feedback.
Throw away model can be a quick, inexpensive way to uncover requirements.
Evolutionary model provides smooth transition to an implemented system.

WEAKNESSES: Can be expensive and time consuming if product or system is complex.
May require numerous invalidated assumptions to design.
Initial model can lead to unrealistic expectations for final design

Method #8. Requirements Workshop

The BA can host a requirements workshop, a focused, one-time team event used to scope, define, analyze, and prioritize requirements. This one or two day event is the fastest method to deliver high quality results. As the participants go through exercises, the requirements that evolve are captured by a team member (called a scribe).

It's important that the BA gather the most appropriate stakeholders to participate, and maintain the focus of the event. The goal of the workshop is to provide the bulk of requirements to be elicited. If he is the facilitator, he must be able to resolve requirements conflicts quickly to reach consensus within the workshop period. And he should make sure that all participants are heard from.

Once the workshop is completed, the BA will analyze the documentation generated and provide a report to the participants, project manager, and other interested parties.

STRENGTHS: Elicits requirement details quickly.
Stakeholders can collaborate and reach a mutual understanding. Lower costs due to stakeholder consensus during a one-time event.

WEAKNESSES: Scheduling can be a challenge.
Success is highly dependent upon a skilled facilitator and appropriate participants.
Number of participants can have a negative effect on outcome (too many can slow the schedule; too few can produce low quality requirements).

Method #9. Reverse Engineering

The BA can conduct a complete breakdown of an existing product to elicit requirements for the product development. By performing reverse engineering, he can reduce the finished product into its underlying process, components, and attributes. According to the IIBA, there are two categories of reverse engineering:

· Black Box Reverse Engineering. Studying the product without examining its inner structure and functions.

· White Box Reverse Engineering. Studying the inner structure and functions

The BA must examine the cost-benefit ratio of conducting this method, as it can be time consuming if the product or system is complex. The advantage of using reverse engineering is that it results in a complete examination of the end result. This is helpful in determining compatibilities, dependencies, interrelated functions, and design.

SSTRENGTHS: Provides detailed, current information about a product or system. Provides a complete starting point to develop initiative or solution.

WEAKNESSES: Can be expensive and time consuming.
Tools used to decompose the product may be expensive and require training.
Can infringe on copyright laws if competitor product is used.
Requires specialized skills to:

1) Abstract from specificity to generalization.

2) Make assumptions about business rules.

3) Relate functions used for production to current or future

business processes.

Method #10. Surveying

If requirements are to be elicited from many stakeholders, the BA may choose to use a survey which provides a questionnaire to be completed. Surveys can be sent simultaneously to stakeholders, end users, and subject matter experts. The questions used, as with the interview method, can be open-ended or closed, depending upon the level of detail sought.

When writing the questions, the BA should keep in mind the following caveats:

· Communicate the survey's purpose and objectives to provide scope to respondents.

· Be aware of the characteristics of the survey population (for instance, communication skills and terminology).

· Focus on the requirements being elicited.

· Keep survey short (IIBA prefers 10 items or less).

· Make sure wording and syntax can be clearly understood.

· Avoid negative questions.

· Avoid complex concepts or question structure.

· Attempt to elicit as much detail as necessary.

· Avoid questions that may put respondents on the defensive.

STRENGTHS: Can be effective at obtaining quantitative as well as qualitative results.
Yields a large set of results.
Short surveys can be completed quickly.
Typically less expensive and easier to administer than other methods.

WEAKNESSES: Open-end questions can require time to analyze.
Statistical sampling methods may be required to achieve unbiased results.
May require follow up interview or re-survey if information is incomplete or missing.
Not suited to uncover actual work process attributes or unwritten behaviors.