Subscribe via RSS Feed

Tag: "software requirements specification"

Requirements Processes: Welcoming Base Level Users to Participate

Doors-ImageNow that we’ve established the advantages of software requirements sessions leverage base level users: we have to address  two very important issues: Are these individuals ready to participate in the requirements process from day one? What can we do to prepare them to do their best? Here are some ideas that I’ve  found to be easily implemented and highly effective:

Start With an Expanded Kickoff Session
Many business analysts find it valuable to have a requirements kick-off session for individuals with no previous requirements session experience. This gives them the opportunity  to describe what is expected during the process and get everyone familiar with the terms, concepts and technologies used on the project. For example, if the project is taking an Agile approach, include a description of what Agile. This helps base level resources feel more involved with the project and prevents them from checking out during the requirements sessions when unfamiliar items come up.

Empower for Best Results
Base level resources often have a wealth of knowledge that BAs are eager to capture. However, some base level users find that participating in a new process and working side-by-side with executive  stakeholders is a little unnerving. One way to encourage the base level resource to speak up is to explain that the reason they’re involved in the requirements session is to correct inaccuracies and provide their viewpoint of how things work.

Clarify Obligations
Participation in requirements sessions often requires “homework”. Be straightforward about action items that may be required during and outside of sessions. Make sure that time commitments are confirmed prior to the kickoff meeting. If the BA thinks of questions that need to be answered prior to the next session, he/she should have a process for tracking and obtaining such information.  Some techniques that have proved successful include giving due dates for assigned items and keeping a list of all requested items and their status.

Emphasize the Value of Participation
While participation in requirements sessions involves time commitments, there are tangible benefits. Participation results in more education on the technology used in the solution and enhances the use of the finished product. For example, call center representatives involved in the design of a CRM solution are better equipped to use the technology from day one and train other representatives.

Building the Ideal Requirements Team
An ideal requirements session should include diverse resources who collectively provide the  authority to make business decisions, insight into business strategy, and knowledge of end user needs and business operations.

Using a base level user is a cost efficient  way to broaden the perspective of the business stakeholder group to include operational knowledge and end-user feedback. Plus, base level users involved in the requirements solicitation process get up and running more quickly and experience business value faster.

If you  use base level resources in your requirements process, what advice would you give to others to get the most from their sessions?

Photo Credit: Eduardo Zarate

Uncovering Hidden Software Requirements


823004299_42b6abf953_z-232x300Base 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