Asking the right questions is the key to gathering quality requirements for your software project, but before you can begin asking questions, you need to know who to ask.
Identify User Groups
In most cases, multiple groups, or classes, of users will interact with the software you want to build. For example, a manufacturing workflow tracking application may have the following user groups:
- Assembly line workers
- Machine operators
- Shift managers
- Division manager
- Shipping department
- Plant accounting department
- Corporate accounting department
- Plant manager
- Regional manager
Identifying the user groups will make it easier to select the best elicitation techniques and questions to get the information you need for the project.
Prioritize User Groups
Once the user groups have been identified, they need to be prioritized based on which user group tasks most closely align with the business objectives.
Let’s assume the business objective for Super Widgets, Inc. is to reduce production time by identifying production bottlenecks. Based on this goal, Business Analyst (BA) Betty would prioritize the groups and elicit requirements from them.
The shipping department may have some reasonable requests for functionality; however, if they do not align with the business objective, their requests will likely not receive development priority. Of course, they may be flagged for inclusion in a future product iteration.
As a word of caution, be careful to listen to input carefully from all user groups. It is possible that someone from a user group that is not classified as a priority may provide insight that may prove very valuable. Gather requirements first. Then prioritize them based on alignment with business objectives.
Create a User Persona
Creating a user persona for each group can be helpful. The user persona is a fictitious character that represents a member of a user group. Below is a simple example of a user persona for Acme Widgets, Inc.
Accounting Annie is 38 years old and has an accounting degree. She has been working at Acme Widgets, Inc. for four years. She is detailed oriented and likes to have information presented in an organized manner. She accesses the production workflow application multiple times each day to complete accounting tasks. She gets frustrated with slow loading reports. Inaccurate data is a primary concern and impedes her productivity.
Select a Group Product Champion
In cases where there are large user groups, it is useful to select one person as the group’s product champion to be the primary contact. Ideally, the product champion will have industry experience, familiarity with the organization’s current operations, a clear understanding of project’s business objective, and a skilled communicator.
The product champion will work closely with the business analyst (BA) to get input from other members of the user group. The opinion of the product champion does not outweigh the input of other group members, nor are they the “boss” of the group. Their role is to help create a collaborative environment that produces quality user requirements that align with the project’s business objectives.
It is essential to communicate expectations of the product champion and get buy-in from a person before naming them as the product champion for a group. Failure to do this could create more headaches and negate the benefits of working with product champions.
Gathering the Requirements
Now that you know who to talk to, it’s time to start getting input from people that will use the software.
The following paragraphs give an overview of different ways to elicit project requirements from various stakeholders. There is an art and science to executing each of these techniques, and this article is not the place to go into great detail for each of them. Click here to schedule a consultation to learn more about these techniques and gathering requirements for your software project.
Conversations
Individual conversations are the most common elicitation technique. This method is a great way to build rapport and relationships with people who will be interacting with the software. One to one conversations also offer a more relaxed atmosphere which helps a person be more open about their wants and needs.
Individual conversations with multiple people are likely to reveal differing opinions about the project. At some point, key stakeholders will have to collaborate to work through those differences.
Workshops
Structured workshops are an ideal way to bring together key decision makers, product champions, and other project leaders to collaborate on project requirements.
The role of the BA is to facilitate the workshop and keep participants focused during the session. Workshops can be a few hours or last for multiple days. They require a great deal of planning and leadership to yield useful project requirements.
Focus groups
Focus groups give the BA a method to get input from specific users within a user group about functional and quality requirements.
These sessions should be facilitated in a conversational manner that gives all participants an opportunity to share their perspectives on the project.
Surveys
Another tool to gather requirements is via surveys or questionnaires. Asking relevant questions is the critical factor. Questions should be a mix of direct response and open-ended.
Be careful about asking too many questions. If the questionnaire is too long, people will be less likely to engage or respond thoughtfully.
Observation
Sometimes watching people work is one of the best ways to get a feel for the current situation. People often have trouble describing the details of their work, especially if it is complicated. In other cases, people may not be aware of some of the things they daily because it is such an ingrained habit. A mouse click here or there can have a substantial impact.
Observations are time intensive, especially if there are many people or stations to observe.
System Forensics
This technique helps the BA validate the input they are receiving from the other elicitation techniques. This step typically includes a review of the current system interface, user interface, and document review to understand the current environment.
Before You Start Asking Questions
There must be clarity on the business objective of the project before you begin gathering requirements from users. Detailed knowledge of the business objective provides the framework for an effective requirements gathering process.
Once the business objective is clear, the next step is to create a plan for getting user input. Don’t go into this armed with a bunch of questions and no plan. This is a recipe for disaster. Remember, bad project requirements are a significant factor in failed software projects.
If you are thinking about a software project and have questions about gathering requirements, give us a call at (812) 285-8766 or fill out our Contact Us form.
Up Next: Building User Cases