Skip to main content

Author: Jill Liles

Methods for Eliciting – Not Gathering – Requirements

methods-for-elicitingThe word “gather” does not truly communicate the nature of the Business Analyst’s (BA) job. You do not gather requirements-they are not just lying around on the ground waiting to be picked up.

The word “elicit” more closely matches the job, because it connotes a more active role for both the BA and for those with whom the BA works. The dictionary defines elicit as:

  1. To draw forth or bring out (something latent or potential)
  2. To call forth or draw out (as information or a response)

There are many ways to elicit requirements from your stakeholders. A BA should be proficient in all of these: interviews, workshops, focus groups, brainstorming, observation, and surveys/questionnaires. While all of these methods involve three basic parts: preparation, conducting, and follow-up, they do have differences.

Interviews

Interviews, either with an individual or with a group of people, offer the opportunity for rich, detailed communication.

Prepare

  • Define interview goal: Determine exactly why you are holding the interview and what you want to achieve in it.
  • Select participants: Decide who needs to be involved in the interview in order to achieve that goal.
  • Determine logistics: When and where will the interview be held, and how will the interviewees be invited?
  • Design the interview: Decide on the format that is most appropriate for the interviewees and the goal. Should it be structured with a detailed agenda and formal set of questions, or unstructured with a looser agenda, depending more on ad hoc interaction? Should the questions be open-ended requiring sentences or paragraphs to answer, or closed-ended requiring short, even one-word answers?

Conduct the Interview

Take time at the beginning to ensure that the interviewee(s) knows the purpose of the interview, who you are, and what your role is. Wrap up the interview with questions like “Is there anything else you would like to add?” and a hearty “Thank you!”

Follow up

Like any other meeting, interview minutes should be published. This allows the interviewees to see what you learned in the interview and validate that what you heard is what they intended to say.

Workshops

A workshop is a structured method for interacting with a group of people. Workshops can generate much information quickly if well facilitated and if participants are active.

Prepare for Workshop

  • Define purpose: Determine exactly why you are holding the workshop and what you want to achieve in it.
  • Select participants: Decide who needs to participate in the workshop in order to achieve that purpose. Make sure to consider the personality types involved and ensure that you’ll get participation from the entire group, not just a few dominant people.
  • Determine logistics: When and where will the workshop be held, and how will the participants be invited?
  • Conduct preliminary interviews: Some workshop methods include collecting some information from the participants before the workshop to provide a starting point. Such methods provide specific guidance about what preliminary information should be collected.

Conduct the Workshop

Be sure to accurately capture all of the information that the workshop produces. Depending on the size of the group, you may want to assign a record-keeper so you can focus on facilitation

Follow up

Some types of workshops result in the assignment of action items to the facilitator or participants, in which case, they must be managed to closure. The workshop results should be published so the participants and other interested parties can see what you learned in the workshop.

Focus Groups

A focus group is an interactive session with a carefully selected group of people designed to capitalize on the synergy of a group.

Prepare for the Focus Group

  • Select participants: Decide who needs to participate in the focus group in order to achieve its purpose.
  • Define roles, topics, and logistics: Define who (among the people running the focus group) must do what, and the specific topics that the participants will discuss. Also define the basic logistics such as when and where the focus group will be held, and how the participants will be invited.

Run the Focus Group

Carefully facilitate the group to ensure free and open interaction among the participants. Participants must feel free to interact openly or the focus group could fail.

Follow up

The focus group report records what was learned, including both agreements and disagreements among the participants.

Brainstorming

Brainstorming is a method of quickly generating many creative ideas from a group of people.

Prepare for Brainstorming

  • Define topics and time limits: Define precisely what will be the focus of the brainstorming session, and how long it will be allowed to go on.
  • Select participants: Decide who needs to participate in the brainstorming session in order to achieve its purpose.
  • Determine evaluation criteria: Decide how the ideas that come out of the brainstorming session will be judged afterward. Be sure that the evaluation does not go on during the brainstorming session.

Conduct Brainstorming

Encourage a free flow of ideas. This requires careful facilitation to ensure that participants feel comfortable with adding any idea to the list, and that no criticism or even discussion of the ideas goes on during the brainstorming session.

Follow up

Apply the evaluation criteria to the ideas that were generated to reduce the list to only those ideas that are reasonable or viable.

Observation

Observation is watching people as they go about their jobs. Observation can be an effective way to gain a realistic and detailed understanding of how work is done in the production environment; however, it is time consuming and may disrupt work.

Prepare for Observation

  • Define goals and individuals to be observed: Decide what you are trying to accomplish in the observation and who you should observe in order to achieve those goals
  • Decide on mode: Observation may be done in either of two ways:
    • Passive/invisible: Observing in a way that does not disturb the workers. “Invisible” refers to the fact that the workers are not even aware that observation is taking place.
    • Active/visible: Interacting with those who are being observed. For example, asking questions and having them describe what they are doing and why.

Observe

If people believe that they are being evaluated, they are likely to do the work “by the book,” instead of the way they normally do it. So those who are being observed must be assured that the observation is not for the purpose of judging them. As the observation goes on, keep detailed records of what is observed and questions that must be answered later.

Follow up

After obtaining answers to any remaining questions, publish the results of the observation.

Surveys/Questionnaires

Surveys allow you to collect information from many people in a relatively short period. A survey can be an effective way to collect quantitative information; however, writing the questions requires great skill and care to avoid ambiguity that could compromise the utility of the results.

Prepare for the Survey

  • Define purpose, target people, and logistics: Decide what you are trying to learn from the survey, who you should target in order to achieve those goals, and how the survey should be distributed (for example, paper, e-mail, internet, telephone).
  • Choose survey type:
    • Open-ended questions vs. closed-ended questions: Open-ended surveys are more difficult to analyze, yet closed-ended surveys limit the responders’ options.
    • Anonymous vs. signed vs. optional: People may be more forthcoming if they do not have to provide their names, but anonymity does not allow for any follow-up questioning.
    • With vs. without pre-survey or post-survey interviews: Pre-survey and post-survey interviews increase the valuable data that you can get from the survey, but add significant effort.
  • Define target response level and follow-up activities: Getting many people to respond to a survey is difficult. If you are expecting more than a small minority of the target people to respond, it will require follow-up work beyond merely distributing the survey.
  • Write questions: This step is more challenging than it sounds. Writing questions that cannot be misinterpreted (resulting in misleading results) requires great skill and concentrated effort.
  • Test the survey: Because it is so difficult to write questions well, it is advisable to test the survey to see if people misinterpret any of the questions, and to see if it provides the information that is sought.

Distribute the Survey

Get the survey into the target people’s hands, and encourage them to respond. If follow-up activities are planned to increase the response rates, do them.

Follow up

After the response period has ended, analyze the data, and summarize and report it to the appropriate people.


Jill Liles is the Senior Product Marketing Manager at Global Knowledge http://www.globalknowledge, where she primarily focuses on marketing activities for Cisco training courses. She also coordinates all marketing for Canada. In her spare time she volunteers with her local Susan G. Komen Foundation affiliate and crafts jewelry. This article draws from Global Knowledge’s Requirements Development and Management course.

Copyright © Global Knowledge Training LLC. All rights reserved

Is the Business Analyst’s Work Ever Done?

Solution Assessment and Validation

The business analyst’s work is not finished when the requirements document is signed off. Although other experts are responsible for the project activities, the BA remains involved to ensure that decisions made have no adverse impact on the business stakeholders. As the project moves forward, the BA should collaborate with the solution team (for example, development, procurement) to ensure that the final solution will satisfy the requirements.

After the solution has been built, the BA collaborates with many people on activities such as testing, conversion, cutover, and training. Depending on the roles defined in an organization and the project, the BA may collaborate with the people who are responsible for these activities, or the BA may be the responsible person. In either case, the BA ensures that all of the right things happen.

Monitor Solution Design and Planning

As the technical team derives the solution design, the BA must learn enough about the implications of that design to ensure that it supports the requirements well. For example, the BA might:

  • Review user classes to ensure that all of the solution functions, uses, and end users have been accounted for.
  • Review the developers’ functions and feature list for completeness.
  • Map the documented requirements (both functional and Quality of Service) onto the elements of the system design to ensure complete coverage.

When the technical team defines its phasing plan (which identifies the order in which requirements will be addressed and functionalities designed and built) for incremental development, the BA must ensure that the plan supports the stakeholders’ needs. If the plan calls for features to be delivered in a certain order, the BA should ensure that the planned order and delivery dates would be useful to the business stakeholders. The BA should also ensure that the phasing plan provides opportunities for any needed prototyping or validation during the project.

Tracing the requirements to the design is a good way to ensure complete coverage, and it lays the foundation for maintaining traceability throughout the project. The traceability information must be captured and recorded as the designs are being done, as trying to derive the traceability after the fact is difficult, if not impossible.

Finally, as the solution is being designed and built, the BA may identify business process improvements that are unrelated to the solution but that would be beneficial. This is especially likely where those processes will be affected when the solution is implemented.

Validate the Final Solution

As each deliverable of the project becomes available, the BA must ensure that appropriate validations take place to ensure that those deliverables satisfy the requirements and can be used by the intended end users.

  • System testing looks at the final system to determine if the requirements have been satisfied. System integration testing refers to testing the final solution to ensure that it can coexist and integrate with existing systems and databases. Many organizations have an independent testing group whose main responsibility is to prepare for and perform these tests. When that is the case, the BA will usually review the test plans and the test results, and at times, the BA may help with the testing. However, in organizations that don’t have testing groups the entire responsibility falls to the BA.
  • Operations testing involves testing the final solution to ensure that it can be installed and run without an adverse effect on the other existing systems. If the computer operations group takes responsibility for this testing, then the BA will usually review the test plans and the test results. But if this testing is necessary and no one takes responsibility for it, then the entire responsibility for this testing falls to the BA.
  • Acceptance testing ensures that the business need and user’s needs have been fully satisfied. If the customer takes responsibility for this testing, then the BA will usually review the test plans and the test results. Otherwise, the entire responsibility for this testing falls to the BA.

Assess Other Solution Options

The BA should collaborate with a variety of people on the project as the solution is being put together. In all cases, expect the experts in each area to be making good choices. The BA’s role in the collaboration is merely to serve as the business stakeholders’ advocate and assure that their needs will ultimately be met.

Although the technical team takes the lead in evaluating and deciding on the technologies that could be employed to build the solution, the BA should remain involved. This is because every technical choice has the potential to cause limitations in the final solution that will be noticeable to the users. So, the BA must learn enough about the effects of the team’s technical choices to ensure that they actually do support satisfying the requirements, and ultimately, the business needs.

When the plan involves purchasing or leasing (as opposed to internally developing) a solution, the BA may take the lead in choosing the solution. But even if someone else has primary responsibility for this, the BA will still remain closely involved. The BA ensures that any RFP (request for proposal) or RFQ (request for quote) accurately translates the requirements. The BA should also verify that the proposals received will fully meet the business need. And, when the solution is finally received, the BA ensures that it is adequately tested to be sure that is actually satisfies the requirements.

Support Implementation of the Solution

In some organizations, an operations team takes the lead in implementation, but often the BA is responsible. In either case, the BA must remain involved to ensure that implementation and any necessary conversion meets the needs of the users.

The BA ensures that any necessary installation planning is done, and that the appropriate technical experts review that plan for correctness. This could be as simple as ensuring there is enough disk space for the new software, or as complex as replacing entire computer systems with new ones.

Conversion is almost always an issue. Since the solution is most likely changing some attribute of the business process, there will probably be data conversion; there may also be other kinds of conversions to be done. Planning for these includes identifying the rules for handling the inevitable problems that will be found.

Finally, the plan to the final cutover to the solution must be well thought out. When should it happen? Will there be downtime involved? If so, how much is acceptable? An important, but often overlooked item is the “backout” plan. If the cutover fails, what must be done so the business can resume working with the old system? If there is significant data conversion or other changes, this can be a difficult problem.

Communicate the Solution Impacts

The responsibility of communicating the impact of the final solutions is assigned to different people in different organizations. In any case, the BA must still remain involved. Before the new solution is implemented, the BA should work with the business stakeholders to ensure that they are ready for it by:

  • Ensuring that everyone who needs to know about the implementation has the information they need, when they need it, before implementation
  • Setting the expectations of users and other stakeholders about how the change will affect them and the business process
  • Making sure that any needed training and help is available to the users in a timely manner

After the implementation is complete, the BA collaborates with the appropriate people to report on the implementation. This reporting provides pertinent information to all the parties who need to know that the implementation took place, and if there were problems. A key item is the business impact that the change had. Since the project was undertaken to improve a business process, the actual impact on the business process is of major concern.

Perform Post-Implementation Review and Assessment

The final validation occurs after rollout of the solution is complete. This activity, also known as “Lessons Learned,” is designed to help the organization learn from each project, supporting continuous process improvement.

You need to capture these successes, identify why they happened on this project, and determine what can be done on future projects to make them routine. The parts of this project that worked particularly well represent opportunities for future projects.

By the same token, if there were things on this project that were problematic, they also represent opportunities for improvement. You need to capture these issues, identify why they happened on this project, and determine what can be done on future projects to avoid them.

The Lessons Learned review is one of the most potent mechanisms for organizational learning and continuous improvement, as long as you actually use what you learned in future projects.

In Summary

Solution assessment includes all the activities that the BA collaborates in to ensure that the technical and other decisions being made by the development team result in meeting the needs of the business and users. These activities include design decisions, phasing for incremental development, maintaining the traceability matrix, choosing technologies, procuring solutions, and ensuring usability.


Jill Liles is the Senior Product Marketing Manager at Global Knowledge http://www.globalknowledge, where she primarily focuses on marketing activities for Cisco training courses. She also coordinates all marketing for Canada. In her spare time she volunteers with her local Susan G. Komen Foundation affiliate and crafts jewelry. This article draws from Global Knowledge’s Requirements Development and Management course.

Copyright © Global Knowledge Training LLC. All rights reserved