Introduction
The requirements process has grown to be very complex.
There are intricate processes to ensure that every project follows the same steps – regardless of the fact that every project is different in its needs. New requirement tools are becoming available with lofty goals of making the requirements process more robust and complete. We see heated, on-going discussions in online groups, on the best methods for eliciting requirements – agile vs. waterfall, user stories vs. use cases vs. shall/should/must and so on. And who isn’t looking for the perfect requirements template to solve all their requirements issues?
While a good process can help an organization create and sustain good requirements and while a requirements tool can help a team be more efficient, often we focus too much on the process and tools and not enough on the basics of why we need the requirements in the first place. Our work becomes all about chasing the perfect requirement rather than on ensuring that our projects are successful and timely.
Maybe it’s time to get back to the basics behind requirements and why we need them. The purpose of requirements is to understand what the business stakeholders need, to align the team (business and technical) around the purpose of the solution and to ensure that we are building the right solution for the business problem.
In this 3-piece article series, we are getting back to the basics of requirements. Our first installment addresses how to ask the right questions.
The “Five Ws”
Back in elementary school we all learned the basics of information gathering - the “5 W Questions”:
These types of questions form the foundation in journalism, research, storytelling, and police investigations. They are equally important in requirements elicitation. Before starting a project the team needs to do basic ‘research’ on why the project is important and what is needed. The requirements need to “tell the story” of the solution the business needs.
Throughout the project lifecycle, the project team needs to make countless decisions on what is in and out of scope for the project and where to make compromises. By getting answers to these types of basic questions at the start of the project (as well as asking questions throughout the project) the team is able to make better decisions as it encounters issues and roadblocks.
The “Who”
The “Who” questions can be looked at from a couple of different perspectives:
- Who is the solution being developed for?
It is critical to understand who the primary users of the system are so that the team can verify that requirements make sense from these users’ perspective. Other, secondary and occasional, users of the system are also important to identify to ensure that their needs are not forgotten or missed.
- Who are we creating the requirements for?
In addition to the users of the system, it is important to understand who the requirements are being developed for. Different consumers of the requirements have different needs and expectations.
Consumers of requirements can include:
Business Stakeholders / Project Sponsor: Depending on their role, the business stakeholders may need to see process flows, project scope, and business rules in order to validate that the solution is meeting their needs. However, they may not need to see detail about how to populate every screen field or detailed rules for database.
Development Team: For IT projects it is important to identify who is doing the development and what level of information that they need from the requirements. Detailed field validations and database needs may be required, or this type of information may follow existing standards so no additional requirements are needed.
Quality Assurance Team: The QA group need sufficient information in order to validate that the solution is being implemented correctly.
The “What”
From a requirements perspective, the most critical “W” is the “What” questions. Everyone associated with the project – the Project Sponsor, the Business Stakeholders, the project team, and users of the solution – all need to be aligned on what the intended solution is in order for the project to be considered successful.
Typical “what” type questions include:
- What business problem are you trying to solve?
Does everyone on the team agree on the problem being addressed? If your team cannot agree on the problem, then there is no way to define a solution that meets the solution’s needs.
- What’s the motivation for solving the problem?
Is the solution going to resolve user issues, save money, automate processes? By understanding the motivation for solving the business problem, you gain insight into the type of solution that is needed.
- What’s a successful solution worth?
There are many ways to solve problems. Understanding what the solution is worth to your stakeholders helps determine the most practical approach. If the problem is critical to business survival, then a more robust (although potentially more expensive) solution may be needed. If the problem is less critical, then there may be a solution that is less costly, but requires more training or user compromises.
- What unexpected or adverse consequences could the new system cause?
There are often compromises that need to be made in order to implement new solutions. Different organizations and types of users have different reactions to change. Solving a problem for one area or group, may cause other problems or consequences for another. For example, a new user interface for an existing system may have the consequence of needing additional training for the users or even a computer upgrade to take advantage of newer technologies. Understanding possible consequences helps the project team mitigate risk.
The “When”
There are many important “When” type questions that impact a solution and the requirements. When includes questions such as:
- When does the solution need to be completed?
This helps determine if project release dates are critical or not. If a solution is being developed for a time-based event (e.g., a conference, legal deadline, etc.), then it may be more important to reduce scope in order to deliver the solution by a given date if the project encounters road blocks.
- When does the new system need to be available?
Understanding *when* the system needs to be available is critical to the design process by the development team. If a system needs to be truly available 24 x 7, there may be a need for redundant systems and more robust hardware – which can be very costly. However, if the solution is only needed during normal business hours in the U.S. market, then the team can plan for regular downtown for maintenance and updates.
I once collected requirements for a system where the business users wanted a requirement for 24x7 availability. However, when I asked follow-up questions – and explained what 24x7 means to a development team – I was able to ascertain that what was really needed was support for users at any time, but the system could be updated during lower usage periods (e.g., on weekends or evenings) as long as information on availability was provided to users.
- When are the requirements needed?
Along with “when” questions related to the solution, also ask about when various types of requirements are needed. There was a time when all requirements for a project needed to be collected before any development could begin. But, with the need for faster solutions, this is generally not practical. Iterative development of requirements is very common. So, you need to know when requirements for various components of the solution are needed by other team members.
The “Where”
Valuable “where” questions include:
- Where is the solution going to be used?
If you are defining a solution for the U.S. market, then the solution may be relatively straight forward. All users can access a common solution.
If you are designing a solution for an international market, many other aspects come into play. Do you need to support multiple languages and localization for various markets? If multiple languages are needed, then it is important to know which languages are supported, as some languages require special characters or use a lot more screen space for descriptions. Globalization and localization impact screen design, data storage, testing (i.e., who is going to insure that the information makes sense in each local market).
- Where is the solution going to be developed and tested?
Is the team co-located? If so, then communication can be more informal with less written detail. Will development or testing to be done off shore, requiring a different level of detail and explanation? If so, then you may need to plan for different work schedules to support communication in different time zones.
The “Why”
Finally, make sure that you and your team understand the “Whys” for the project. Some of the more important “why” questions include:
- Why is the project being requested? Why is it important?
To be successful the team needs to be aligned on why the project is needed and why it is important to the organization. If some project team members don’t believe that the project is important, then focus and commitment to the solution are impacted.
- Why is one solution favored over another?
Business stakeholders and end-users often have a solution in mind when they request new functionality. It is important to identify if these expectations exist and, if so, why. Is there a business reason for preferring one solution over the other or is it about individual preference? When there are cost factors, is a less expensive solution preferred even if it is not the first choice of the business users?
- Why is a given feature needed and why is it important?
Understanding why a given feature is needed and important helps the solution team prioritize the order of features. Features that are more critical to the overall solution can be developed and tested first.
And the One H
In elementary school we also learned that the “One H” often goes along with the “Five Ws”. So what do we need to do about the “How” for the projects we work on?
Common thought is that requirements define the “What” and not the “How” for a solution. But, this doesn’t mean that there aren’t many important “how” questions that also need to be asked. Remember: One person’s “how” may be another person’s “what”. It’s important to understand stakeholders’ and users’ expectations on how a solution will work for them in order to successfully meet their needs.
Important “how” questions include:
- How is the solution going to be used?
Knowing how a solution or feature is going to be used enables the team to better meet the expectations of the business.
- How does the stakeholder want the solution to work?
When you are defining a business solution there are often a lot of preconceptions on how a requested feature will be implemented. Understanding these preconceptions enables the project team to make better decisions.
- How can we judge the success of the solution?
By understanding how a business stakeholder judges the success of a project enables the team to deliver a more successful solution.
Keep Asking Questions
As you work on your current or next project, ask yourself if you understand what is important to the business stakeholders and the project sponsor. If you don’t understand what is needed to ensure that the project is successful, keep asking pertinent questions until you do.
You don’t need to have the formal title of “Business Analyst” to ask these questions. Everyone on the project team should be able and willing to ask key questions to understand the needs of the project in order to create an optimum solution. Understanding the purpose behind a business request even on a small project with no formal requirements makes the solution more successful. During the development of a solution there are constant decisions that need to be made in order to accomplish the goals of the project. By understanding the basics behind the project, the team can make better choices while building the solution.
Asking the right questions is just the start of getting back to basics. Knowing the right questions to ask are critical to the success of any project, but other things are important too.
Coming Next:
In the second and third articles in this series, my colleagues cover other fundamentals for obtaining the requirements for a project. Charlene Ceci discusses the basics for obtaining the requirements. Greg Kulander follows with the basics of how to share this information with your team and stakeholders.
Author: Cathy Brunsting, Principal Consultant, Geneca
Cathy Brunsting is a Principal Consultant at Geneca (www.geneca.com) and a Certified Scrum Master (CSM). She has over twenty-five years of experience in all aspects of business analysis, systems development and project management, from project inception to customer acceptance. She is skilled in the analysis of business problems, as well as the design, implementation, testing, and on-going support of technical solutions. Her areas of expertise include Health Care, Insurance, Interactive Solutions, e-Business Solutions, Financial Systems, Gaming and Lottery Systems, Telecommunications (Operator Console, Voice Recognition, and Call Processing), Order Entry/Subscription Services, and Database Design. Ms. Brunsting was also the founding President of the Chicagoland chapter of the International Institute of Business Analysis™ (IIBA).