In this article I will go over 3 Steps to Eliciting Requirements.
What do you mean by Eliciting Requirements?
The Elicitation and Collaboration knowledge area describes the tasks that business analysts perform to obtain information from stakeholders and confirm the results. It also describes the communication with stakeholders once the business analysis information is assembled. Elicitation is the drawing forth or receiving of information from stakeholders or other sources. It is the main path to discovering requirements and design information, and might involve talking with stakeholders directly, researching topics, experimenting, or simply being handed information. Collaboration is the act of two or more people working together towards a common goal. The Elicitation and Collaboration knowledge area describes how business analysts identify and reach agreement on the mutual understanding of all types of business analysis information. Elicitation and collaboration work is never a ‘phase’ in business analysis; rather, it is ongoing as long as business analysis work is occurring.
In short it’s the process of gathering the client requirements.
Nothing to be scared about? The key is to start.
There are 5 steps to Eliciting requirements.
Step 1: Identify the Method of Elicitation
There are a bunch of methods to pick from to elicit requirements. Here are the most common.
1. One-on-one interviews
The most common technique for gathering requirements is to sit down with the clients and ask them what they need.
2. Group interviews
These are similar to the one-on-one interview except that there is more than one person being interviewed. Group interviews require more preparation and more formality to get the information you want from all the participants.
3. Facilitated sessions
In a facilitated session, you bring a larger group together for a common purpose. In this case, you are trying to gather a set of common requirements from the group in a faster manner than if you were to interview each of them separately.
4. JAD sessions
Joint Application Development (JAD) sessions are similar to general facilitated sessions. However, the group typically stays in the session until a complete set of requirements is documented and agree to.
5. Questionnaires
These are good tools to gather requirements from stakeholders in remote locations or those that will have only minor input into the overall requirements. It can also be the only practical way to gather requirements from dozens, hundreds or thousands of people.
6. Prototyping
Prototyping is a way to build an initial version of the solution – a prototype. You show this to the client, who then gives you additional requirements.
7. Observation
This is especially helpful when gathering information on current processes. You may need to watch people perform their job before you can understand the entire picture. In some cases, you might also like to participate in the actual work process to get a hands-on feel for how the business function works today.
Step 2: Prepare, Prepare Prepare!
- Determine how many systems are involved. Knowing how many systems are involved helps you identify the stakeholders you need to elicit information from in order to understand interfaces, data, processes, and business rules.
- Identify your stakeholders. Eliciting from people who work in the same office as you do is different from eliciting from people in another state (or even halfway across the world). You may choose similar elicitation techniques for each group, but the meeting tools you choose may be different. For instance, you can still have a facilitated workshop, but instead of physically gathering stakeholders together in one meeting, you may have to use an online meeting tool.
- Understand the importance and Personalities of your stakeholder: Outline your stakeholders’ personalities. Are they visual people? Auditory people? Kinesthetic people? Everyone has a primary learning and interaction style. Knowing your stakeholders’ preferred style puts you in a better position to tailor your message to your audience.
- Based on how much time you have to get your requirements completed select the method of Elicitation. You may need to collect all the requirements in a short period of time. This constraint means you may need to develop and elicit the requirements in a highly-intensive Joint Application Development (JAD) session.
- What is the scope of the project? After the project is underway, it should have a clearly defined project scope indicating the boundaries of your project and the objectives to be delivered by the project. You don’t want to go outside the boundaries of the scope.
- Build a questionnaire for your stakeholder’s:
- Write out your stakeholders’ schedules and find the time that works best for them; then book your session. Remember to address not only stakeholders’ schedules but also their time zones and when their days start and end. Schedule at a time when stakeholders are going to be at their best. Make sure you provide the goal of your sessions.
- Ensure that you have your documentation and Tools ready. If you’re using applications and tools for elicitation, make sure you test out the tools prior to the sessions.
- Determine the Agenda and Roles for the meeting: Identify ahead of the meeting as to what the agenda will be and who will be the scribe and be responsible for the meeting notes.
Step 3: Conduct the Elicitation Session
So it’s show time now!
You have prepared as much as you can and are in the session.
You have a plan in place and you have started the meeting.
- When the meeting day arrives, you should facilitate and lead the meeting using the agenda you sent out and you will have a lot of key responsibilities as the meeting facilitator. The facilitator should be responsible for making sure that the conversation stays on task and within the allotted time set forth in the agenda. The facilitator should establish meeting ground rules that the participants follow. Only one meeting participant should speak at a time and all participants should remember they are there to work as a team. Facilitators should make sure that everyone is contributing and manage any conflicts that arise and encourage resolution on all issues. Most importantly, the facilitator should be a great listener and absorb all the thoughts and information the meeting attendees are discussing during the requirements gathering meeting.
- Document and summarize action items. The meeting facilitator may also act as the note taker for the meeting or else assign a scribe to document meeting notes. It is important to listen and document all action items that come from the requirements gathering and elicitation meeting. These action items should be recapped and summarized during the conclusion of the meeting. Meeting participants may be responsible for owning some action items and following up with the meeting facilitator. Future meetings may arise as a result of these action items. ]
- Send out a meeting summary: Shortly after the meeting is over, the meeting organizer should send out a detailed summary of the main points and action item outcomes. Focus on documenting the conclusions drawn from the meeting and send out the meeting summary within two business days while the meeting is still fresh in everyone’s mind. Meeting summary documentation can prove to be important if there are any disagreements or conflicts later on as you will have a baseline to reference if needed.
Here are a list of generic questions to get your mind going in terms of the questions to ask your stakeholders:
The “What” questions to ask
- What goals might you have in mind that this product could help you accomplish?
- What problems do you expect this product to solve for you?
- What external events are associated with the product?
- What words would you use to describe the product?
- What does success look like for this product?
- What aspects of the current product or business process do you want to transition?
- What are the sequence of events?
- What is the start of this product/ process?
The “When” questions to ask
When will this Product be triggered?
When can the product fail?
The “Where” questions to ask
- Where is this product located?
- Where will the output be viewable?
- Where in the process will this product show?
The “Who” questions to ask
- Who will use the Product?
- Who will access the backend?
- Who will view the results?
- Who will input the data?
Here are some open ended questions to ask:
- Can you elaborate on ….
- What is the Purpose …
- Tell me about …
- I am sorry I am not familiar with xyz… can you help me understand …..
Are specific portions of the product more critical than others for performance, reliability, security, safety, availability, or other characteristics? You can never create a product that combines the maximum levels of all quality characteristics. Tradeoffs are necessary between properties such as usability and efficiency, integrity and usability, and integrity and interoperability. (See Chapter 12 of my book Software Requirements, 2nd Edition for more about tradeoffs.) Therefore, it’s important to understand which specific portions or aspects of the product have critical quality demands so that developers can optimize their designs to achieve those objectives.
Are there any constraints or rules to which the product must conform? Most products are subject to corporate policies, industry standards, government regulations, and computational algorithms. It’s essential to know about such business rules so the BA can specify functional requirements to enforce or comply with those rules. Look for subject matter experts within the organization who have current knowledge about the business rules.
How is the product you envision similar to the way you do business now? How should it be different? When automating current business processes or replacing an existing information system with a new one, it’s easy to inadvertently re-implement all the shortcomings of the current approaches. This is known as “repaving the cow paths.” It’s difficult for people to break from the mindset of their current ways of working and to envision something that’s really different and better. The BA should stimulate the thinking of the user representatives to rethink business rules and business processes to see what has changed—or what could change.
The following questions help the BA gain a richer understanding of how potential users view the product. Asking these questions of people who represent different stakeholder groups can reveal conflicts that you’ll need to reconcile.
Which aspects of the product are most critical to creating business value? A user’s view of business value might be different from a manager’s view or an acquiring customer’s view. A user might value a more efficient way to perform a specific task that will save considerable time over many executions. A manager could be more impressed if the product has lower acquisition and support costs than the one it’s replacing.
What aspect of the product will be most valuable to you? Least valuable? No project can deliver everything to everybody on day one. Someone needs to determine the implementation sequence for various capabilities. Ask this question of different user representatives, and look for patterns that indicate certain product capabilities are more important and more urgent than others. Those capabilities should have top priority.
What is most important to you about the product? This deliberately vague question could generate responses dealing either with the product itself or with other aspects of the project. One user might say, “It’s most important that this system be available before the beginning of the next fiscal year.” Another might respond, “It’s most important that this system will let me import all my data from these older systems we’ve been using.” A manager might say, “It’s most important that the people in my department can get up to speed on this new system without training.” These responses have implications for how the project is planned, the functionality to include, and usability, respectively.
How would you judge whether the product is a success? A business manager might judge the success of the product quite differently from how members of various user classes determine success. Surface these different perspectives early so that they can be reconciled to keep all stakeholders working toward a common objective.
Can you describe the environment in which the product will be used? The operating environment has a big impact on both requirements and design decisions. The user interface is also highly sensitive to the operating environment. Touch screen displays are superior to keyboards in some settings, for example, and speech recognition is becoming increasingly effective for certain applications.
Organizing and facilitating a successful requirements gathering and elicitation meeting requires a lot of thought, planning, and execution.
In conclusion there are 3 Steps to Eliciting Requirements.
Step 1: Identify the Method of Elicitation
Step 2: Prepare, Prepare Prepare!
Step 3: Conduct the Elicitation Session
What are some techniques or tips that you can share that you do differently while eliciting requirements?
