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.
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.
Requirements Elicitation Functions
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.
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:
· Training Manuals.
· Work Statements.
· Policy Manuals.
· Business Plans.
· Requests for Proposal (RFP).
· Market Studies.
· Comparative Product Reports.
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.
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
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.
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
Method #5. Interview
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.
Maintains focus throughout the elicitation process.
Allows for complete explanation and discussion of attributes and needs.
Interviewer must be highly skilled in order to generate appropriate information.
Subject responses generally limited to their business domain.
Method #6. Observation
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.
Elicits information that is not captured through documentation or questioning.
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
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.
Throw away model can be a quick, inexpensive way to uncover requirements.
Evolutionary model provides smooth transition to an implemented system.
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.
Stakeholders can collaborate and reach a mutual understanding. Lower costs due to stakeholder consensus during a one-time event.
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:
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.
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
Method #10. Surveying
· 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.
Yields a large set of results.
Short surveys can be completed quickly.
Typically less expensive and easier to administer than other methods.
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.