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 stakeholders.

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 starting point:

• 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 work).
• 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 business decisions.

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 web site.
• 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 that group.
• 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 requirements.
• 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.