Uncovering Hidden Software Requirements
Base Level Users in Requirements Gathering Sessions Can Yield Gold
The need is clear for business people to be part of requirements definition – that is, understanding the intent of the system and creating a common definition of success. Once that course is set and specification begins, how can we ensure we’re getting the right details to accomplish those goals?
Today, the idea that a software team can gather requirements without direct participation from the stakeholders who can speak for the user is outdated. Receiving sufficient quality customer input — along with the business stakeholders — makes a direct impact on a software teams’ ability to predictably deliver business value.
I have found that business stakeholders are not necessarily equal, interchangeable resources. For example, consider a requirements session where the stakeholders do not have the authority to make business decisions. Or, a session where the stakeholders lack sufficient knowledge of business processes. And then there’s the case where the stakeholders have the authority and knowledge of business processes yet the solicited requirements are still incomplete. So what’s wrong with this picture?
Probably what’s missing is the perspective of a resource who has knowledge of business operations and is also an end user of the existing process or the new process being designed. A base level user who knows not only how the system actually works from the ground floor, but also knows about the undocumented bugs — and the work around to get from A to B — that the current system may have.
Adding base level users brings an important perspective to the requirements session and improves the quality of business information and project implementation. This resource is not only cost effective but typically has more availability than the stakeholders who wield the power to make business decisions.
The Benefits of Using Base Level Resources
There is a wide body of knowledge regarding User Centered Design, which emphasizes the value of using end users in the requirements process. After all, these are the people who are using the current solution that is being replaced or will be physically using the new solution on a daily basis.
Users involved in the design of a solution from the beginning understand how that solution works and are better equipped to use the solution after it has been developed. The User Acceptance Testing process is also enhanced when the base level / primary end user is involved in testing, satisfying one of the key goals of User Centered Design.
Hands On Knowledge of Operations
Base level resources are often essential to the requirements process because they have knowledge of ground level businesses operations that other resources are often unaware of. Jason Prine, owner and Principal Business Analyst at JPx2 Consulting Inc., describes these resources as the “folks who work in the weeds everyday … and are essential to any successful project.”
It makes a lot of sense: Having the appropriate operational requirements goes a long way in making sure the end product satisfies the needs of the user. This also prevents requirements from addressing only things as they should be rather than how they are.
Next week I’ll share some ideas on how to welcome and prepare base level resources into your requirements process.
Does your requirements gathering process routinely get input from base level users? What effect has it had on your team’s ability to quickly deliver business value?
Photo Credit: Angelo Juan Ramos
Category: Business-IT Alignment, For Practitioners, Requirements Definition
Interesting article, Alan. I agree, having been in both types of situations, that an end user is quite valuable in giving insights of those who will actually use the software! Looking forward to the next article…