Stakeholders are the main source of requirements. There are different types of stakeholders, e.g. customers who pay for the product, clients who pay for the development of the product, end-users, policy makers, developers. They have diverse backgrounds, interests, and personal goals. From the definition “stakeholders include anyone with an interest in, or an effect on, the outcome of the product”, two general categories of stakeholders can be seen: stakeholders with an interest, mostly residing in the business / problem world, for instance customers, end-users, who mainly function as the requirements providers that define the product; stakeholders with an effect, mostly residing in the software engineering / solution world, for instance clients, developers, who mainly function as the requirements refiners or constrainers that refine or constrain the product. Although clients also have an interest in the product, their requirements (e.g. time, scope or budget) are more likely to constrain the product rather than define the product.
Conventionally, we have paid more attention on those stakeholders who have an interest in the outcome of the product. Consequently, requirements elicitation is usually user-centred and user-requirements-focused. Users and the like seem to be the main stakeholders involved. However, there is another type of stakeholders that matter as well, especially for the context of enterprise systems where one IT project usually impacts multiple systems. And that type of stakeholder is software architects. They may not be the source of requirements (but sometimes they do, e.g. they may propose certain features maybe because the current technology enables that) but they definitely contribute to requirements by refining them.
To treat software architects as stakeholders and involve them up-front in the requirements phase will benefit the IT project in at least the following ways:
1. Provide an overarching support for Business Analysts, especially when they do not have enough knowledge about the existing IT systems
2. Produce more realistic requirements and less requirements rework later on
3. Better alignment between the existing IT capabilities and the business ask
More on how architects as stakeholder in requirements engineering will be talked about in the follow-up posts.