Identifying the Right Stakeholders
Your first step in the requirements gathering process should be to solicit
requirements for your software development project from the stakeholders. The
method and techniques you choose to employ for the purpose of requirements
solicitation will require you to contact these stakeholders for the purpose of
either gathering them together, meeting with them one on one, or communicating
with them long distance. That first contact will require a contact list of key
Who to Choose
If you’ve already developed a list of project stakeholders, check the list
for the people in the following list. If you haven’t, this list is a good
- The chief, or head architect who will take responsibility for the structural
integrity of the application upon completion.
- Anyone who will use the new application to perform their jobs.
- The owners of the business units these people belong to (these owners may
have goals and objectives that are not clear to the people performing the
- Owners of any applications that the new application will interface with.
- Stakeholders who retrieve information from the new application in the
course of performing their jobs (e.g. customer service agents who need to check
on the status of an order through the new application).
- Consumers of reports that could be expected from the new application.
These people tend to differ from the previous group in the way information is
consummed: the previous group need information dynamically as their job
dictates, this group will require information periodically in order to make
Web sites are a different breed of software application with some
stakeholder groups that are unique to it:
- · If the web site is an e-commerce web site, the most obvious group will be
the customers. There will be marketing groups, sales groups, and customer
support groups representing customers. There may be more than one of each of
these groups involved depending on how may distinct geographical areas are
targeted. For example, web sites that have different "stores” for different
locales will each have a "store manager”.
- Graphics/html subject matter experts who own the look & feel of the
- Payment service providers. These stakeholders don’t contribute
requirements to the web site but may place constraints on the features and
functions that are required.
Who not to Choose
The objective of this exercise is to capture all the right requirements. In
order to achieve this, you’ll have to keep your requirements gathering focused.
Here are some tips on how to accomplish this:
- Choose a representative from each group. This person should be recognized
by their peers and the group’s business owner as the logical spokesperson for
- Don’t choose owners who aren’t familiar with how the business functions.
Typically, more senior business owners will be familiar with strategic
objectives but not with the functional objectives you’ll need for your
- Business analysts. Their role is to convert the commercially stated
requirements into features and functions, not to understand the business needs
for the application.
- Other project managers.