Stakeholders and Software Requirements


Stakeholders in any organization can represent group, a person or even another organization that might have indirect or direct stake to such organization. Stakeholders can affect any organization’s objectives, actions or policies, and stakeholders can have different responsibilities, and considerations within such organization. In the past, stakeholders were representing a common conception that business can fundamentally rely upon, and has its effect of the economic capital of any organization. In today’s business world, the stakeholders represent people; and infrastructure that are necessary to any organization where the interests of such organization can be protected by them (Worthington, 2009).

Collecting the software requirements can be affected by choosing different stakeholders for a simple reason; that in many situations the stakeholders can have different interests in different areas of the business that might affect the outcomes of the gathering requirements process.

Stakeholders and Software Requirements

Worthington(2009) explained that within any organization the stakeholders represent all the parties that can be affected by the organization decisions, and can represent the business economic, social, and environmental capital. It is also possible that the stakeholders within any organization harbour different conflicting interests. Stakeholders can be categorized as Connected, Internal and External Stakeholders:

  • Internal Stakeholders represent employees, managers, and others that can affect the running of the organization on a daily basis.
  • Connect Stakeholders represent suppliers, shareholders, customers, and parties that might be investing in the business.
  • External Stakeholders – represent the group that are not directly linked to the organization, but can influence the activities within the organization. (2011) explained that one of the important steps in the software development lifecycle is the requirements elicitation, where stakeholders within an organization are identified, and the different areas of requirements gathering are also identified. The level of details of the requirements gathered once such process is completed, can add a degree of complexity of business processes, and the size of the application, and as such; careful selection of the stakeholders has to be considered. Some of the problems that can face the requirements elicitation are:

  • Stakeholders can add ambiguous understanding to the business process.
  • Stakeholders can add inconsistency description within a single process by multiple users.
  • Requirements elicitation can have insufficient input from stakeholders.
  • Requirements gathering can have different directions that can be affected by the conflict of interests’ of the stakeholders.
  • Stakeholders can change requirements after the fact that the project has begun.

The traditional methods of requirements elicitation such as interviewing stakeholders, flowcharting of business processes, and interviewing end-users in some cases can improve the accuracy of the requirements gathering; however in many cases such methods can create more conflicts among users and stakeholders. Modern tools equipped with better ways of handling the complexity, and the multilayered process of requirements elicitation where it can improve the requirement gathering process. Some of these tools are: Use Cases, Prototypes, Data flow diagrams, user interfaces, and transition process diagrams (, 2011).

As a good starting point of requirements gathering process, using the project charter, statement of work, and project objectives are a good source of requirements’ collection. However such document is not enough for requirements gathering, and there are different methods for eliciting requirements where interactions with customers, stakeholders, and sponsors are required. Brainstorming, interviews, workshops, and focus groups will give a good chance for the stakeholders to express themselves, and such discussion can be translated into project requirements (Sherrer, 2008).

Sherrer (2008) explained that regardless of the project, service or product, collecting requirements is a collaborative effort between all the engaged parties in the process, and some of the recommended approaches that can help facilitate the process are:

  • During the requirements elicitation sessions, avoid jargons and acronyms, unless all the audience understand what the term means.
  • Ask the right question that can be more than simple Yes/No.
  • Make sure that everyone provides their thoughts about the subject.
  • Resource, money, and time will limit what requirements can be accepted, and prioritizing such requirements is very important.
  • It’s important to understand that there are different types of requirements that are needed, such as requirements to achieve the business objectives, to create the deliverables, to meet the project objectives, to confirm the product design and specifications, and to develop the testing strategies for deliverables.

A stakeholder in any organization represents any individual or group who is affected or can be affected by the achievement of the organization’s objectives. From the system prospective, system stakeholders are organizations or people who will directly or indirectly influence the system requirements. Stakeholders include; managers, end-users, and others involved in the organizational processes that can influenced by the engineering of the system. There are different approaches to identify the stakeholders in any development project; one of the approaches that can identify the stakeholder is to uncover the network of the stakeholders, where each stakeholder being a node; and each edge represents the relationship between other stakeholders (Sharp and Finkelstein, 1999).

Chevalier (2006) explained that other approaches used for identifying stakeholders is to identify the core problem that required identifying its stakeholders, and choose one of the methods that can identify stakeholders that can be related to this problem, and some of these methods are:

  • Identification by experts – Use key members of the organization, and the staff of such organization to identify the stakeholders.
  • Identification by self-selection – Use announcements within the organization to invite stakeholders to come forward.
  • Identification by other stakeholders – Use stakeholders that can identify other stakeholders.
  • Identification using written records and population data – Use the organization charts, and directories to identify the stakeholders.
  • Identification using oral or written accounts of major events – Ask employees to describe major events where the problems occurred in the past within the organization, and the people who were involved in such event.


Stakeholders play an important role in the requirements elicitation process, and the first step for any IT project is to identify the right stakeholders that can provide software requirements details.  The arrival of the stakeholders within an organization; brings an ethical dilemma to the company in how they can satisfy the new member’s need, and also avoid the conflict within the organization.

The guiding principles of identifying stakeholders within any organization can be achieved through identifying the actors that can be affected by a certain problem or influenced by certain problem within such organization. Also, another way of identifying the stakeholders is by identifying the leaders and public officials of the groups within an organization (Chevalier, 2006).

Finally, from my previous experience, gathering requirements is much like searching for the treasure. At the start of the process most of the requirements are identified broadly. However, with good analysis to such requirements, and with persistence to know the truth; and more details about the process, it will eventually lead to more information collected collaboratively with help of the stakeholders. By digging deeper to explicit a well-defined requirements, more details will be surfaced around the problem that can help improve the requirement gathering process.


Chevalier, J. (2006) Stakeholder Identification [Online]. Available from: (Accessed: 13 May 2011). (2011) Requirements Analysis Process: requirements Elicitation, Analysis and Specification [Online]. Available from: (Accessed: 13 May 2011).

Sherrer, A. (2008) Project Management Road Trip [Online]. Available from: (Accessed: 13 May 2011).

Sharp, H. & Finkelstein, A. (1999) Stakeholder Identification in the Requirements Engineering Process [Online]. Available from:  (Accessed: 13 May 2011).

Worthington, I.(2009) Stakeholders and How They Affect Your Business [Online]. Available from: (Accessed: 13 May 2011).


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: