Recently, someone asked me about the different types of requirements gathering sessions; and, the person asked me what type was preferred over the other. Really the type of requirements gathering session used is driven by the organization and project size and complexity. I decided to post this information in case others had the same question. This post discusses the different approaches used to understand and capture user requirements.
Overview
To identify the system features and all other requirements requirements gathering meetings, or sessions, are held. Separate requirements gathering meetings are usually held for each type of requirement. This means a requirements gathering meeting is held to define the features along with the Vision. Then, another requirements gathering meeting is held to define the use cases or user stories and so on. The cycle is repeated until all requirements are documented. There are various approaches that can be used to gather requirements.
Using a Survey
Some projects may begin with a survey. The survey is used to ask users questions. The surveys are usually anonymous so respondents do not identify themselves. In the real world surveys are usually distributed over the internet. And, once the survey is ready for responses participants are sent an email with a link to the survey. The email usually includes basic instructions including the due date for responses.
The Analyst goes through the survey responses and translates the responses into requirements, as applicable. Following is a list of a few examples survey questions that may be included in the survey:
- Problems have users had with the existing software or similar software they've used in the past.
- What features users would like to see implemented in the new (or updated) system. Users are typically asked to state the top ten features that would help them be more productive on the job. Users are typically asked to prioritize the features by listing the highest priority feature first and so on.
- What success criteria the user has for the product. (This is the criteria the software must meet for the user to view the implementation as a success.)
Using Group Sessions
Another form of requirements gathering is applied through the use of group sessions. With group sessions a group of people discuss the requirements. The group may be large (100 or more people); or, it may be small (5 or 10 people). The size of the group is driven by the size of the organization. For example, the Department of Defense (DoD) is the largest Federal Government agency. The DoD's requirements gathering groups would be much larger than that of a small consulting company. And, keep in mind these sessions don't include every single user; but rather people identified as stakeholders. (The term stakeholder is discussed in the post titled, Facilitating Meetings: Stakeholders in Business & SMEs (Subject Matter Experts).)
Examples of group sessions include focus groups and Joint Application Development (JAD) sessions. Group sessions are usually facilitated because a number of people participate in the sessions. A focus group session may include representatives from various companies invited to participate in the requirements gathering sessions. This approach ensures everyone impacted by the software helps shape the software product. Focus group sessions may or may not include the technical team. For example, when working for the Federal Housing Finance Board (FHFB) we supported a project that built a reporting system. The reporting system was to be used by FHL banks across the United States. Therefore, we hosted Focus group sessions where FHFB and FHL bank employees participated in stating requirements for the system. We used a combination of in-person meetings and virtual meetings.
JAD sessions, on the other hand, are highly structured, facilitated workshops. These sessions include stakeholders and technical team members. This approach supports a forum where stakeholders can ask the technical team questions to fully understand the software product that will be implemented. And, the technical team can ask questions about the requirements to fully understand what the stakeholders expect. Using this approach gives both sides (stakeholders and technical team) an opportunity to gain a clear understanding of the requirements to be implemented. Lastly, a facilitated workshop means the session has a facilitator or moderator. The facilitator or moderator makes sure the agenda is followed, everyone has a chance to speak and the meeting rules (i.e., do not talk while someone else is talking, etc.) are followed.
Using One-on-One Meetings
Another approach is to host one-on-one meetings. In a one-on-one meeting the analyst speaks solely to a single stakeholder. There are two situations in which I have used this approach. In one example I was supporting a project while working for an international union. I was gathering requirements for a survey system that would be used by millions of people. An organizer, who was very much in touch with the local unions, served as the stakeholder. In this situation, the stakeholder had already talked with the local union workers numerous times and knew exactly what they wanted.
In a second example, the analyst may have participated in a group requirements gathering session. There may have been one or two stakeholders who didn’t say anything in the group session. Or, an individual in the group session may have started to make a point but never finished. In either of these examples the analyst may schedule a one-on-one meeting to elicit additional input. However, for the most part one-on-one meetings are rarely used because it does not give everyone or the majority input regarding system requirements.
Reverse-Engineering Software to Gather Requirements
An analyst may also gather requirements by reviewing an existing software product. The analyst would go through the software to define all of the requirements that were implemented. This approach might be used if a company has an outdated software product; but, doesn’t have the requirements documents for the product. After the analyst documents the requirements for the outdated software product additional requirements may be added. For example, a group session may then be used to identify other requirements that should be added. Or, stakeholders may discuss changes that should be made to the outdated software requirements, which results in an updated version of the requirements document being produced.
These are a few of the requirements gathering methods that may be used to define requirements for a new or existing system.
