262
Engineering Systems Integration
of events helps determine the interests of the stakeholders and their needs at
some point in the future.
Classification of Potential Stakeholders
Classification of potential stakeholders proceeds using the following steps:
(1) determination of the system boundaries, (2) classification of potential
internal stakeholders, (3) classification of potential first-order stakeholders,
and (4) classification of potential second-order stakeholders. First, to define
the system boundary, one must understand that it can be somewhat ephemeral
in nature. That is, the incidental interactions between stakeholders, the elements and domains that characterize the system, and external interactions
with other systems and stakeholders will change over time and therefore
change the system boundary. Scenario building and analysis are convenient
means to explore the role of stakeholders at various stages in the lifecycle of
a product or service.
Those stakeholders that interact only with internal system elements or
with other stakeholders are classified as internal stakeholders. Those stakeholders that are in direct contact with the system but do not have direct
interaction with the internal stakeholders are considered first-order stakeholders. Second-order stakeholders are defined as those stakeholders who
are connected indirectly to the system via interaction with first-order stakeholders. Both first- and second-order stakeholders are classified as boundary
stakeholders because they interact with external entities across the system
boundary. Therefore, the group of internal and boundary stakeholders comprise the set of valid system stakeholders (Ku 2007). After classifying the
stakeholders, it may be necessary to prioritize them based on when they
influence the system. Determining the relationships between the potential
stakeholders and the system is an initial (and critical) step in prioritizing the
stakeholders. The purpose for prioritizing the stakeholders ensures that
vital inputs (stakeholder problems, needs, and requirements) are utilized to
develop the functional analysis, and thereafter, the system architecture for
the human capital management (HCM) strategy. Drawing from the pool of
potential stakeholders established during the previous steps, stakeholders
are grouped into different system roles, which assist their prioritization and
facilitates the selection of appropriate stakeholder inputs.
Stakeholder analysis helps identify the key system stakeholders—those
stakeholders who help form the acquisition and development, and then take
delivery of the product or service. Determining which stakeholders have significant roles during development and which are focused on those aspects of
defining the project are most likely to either be involved early on or be represented for the early discussions regarding requirements. All stakeholders
must be represented during requirements analysis.
As with any set of requirements, not all stakeholder needs can be met.
There will always be some requirements that are not included or changed
Engineering Systems Integration
of events helps determine the interests of the stakeholders and their needs at
some point in the future.
Classification of Potential Stakeholders
Classification of potential stakeholders proceeds using the following steps:
(1) determination of the system boundaries, (2) classification of potential
internal stakeholders, (3) classification of potential first-order stakeholders,
and (4) classification of potential second-order stakeholders. First, to define
the system boundary, one must understand that it can be somewhat ephemeral
in nature. That is, the incidental interactions between stakeholders, the elements and domains that characterize the system, and external interactions
with other systems and stakeholders will change over time and therefore
change the system boundary. Scenario building and analysis are convenient
means to explore the role of stakeholders at various stages in the lifecycle of
a product or service.
Those stakeholders that interact only with internal system elements or
with other stakeholders are classified as internal stakeholders. Those stakeholders that are in direct contact with the system but do not have direct
interaction with the internal stakeholders are considered first-order stakeholders. Second-order stakeholders are defined as those stakeholders who
are connected indirectly to the system via interaction with first-order stakeholders. Both first- and second-order stakeholders are classified as boundary
stakeholders because they interact with external entities across the system
boundary. Therefore, the group of internal and boundary stakeholders comprise the set of valid system stakeholders (Ku 2007). After classifying the
stakeholders, it may be necessary to prioritize them based on when they
influence the system. Determining the relationships between the potential
stakeholders and the system is an initial (and critical) step in prioritizing the
stakeholders. The purpose for prioritizing the stakeholders ensures that
vital inputs (stakeholder problems, needs, and requirements) are utilized to
develop the functional analysis, and thereafter, the system architecture for
the human capital management (HCM) strategy. Drawing from the pool of
potential stakeholders established during the previous steps, stakeholders
are grouped into different system roles, which assist their prioritization and
facilitates the selection of appropriate stakeholder inputs.
Stakeholder analysis helps identify the key system stakeholders—those
stakeholders who help form the acquisition and development, and then take
delivery of the product or service. Determining which stakeholders have significant roles during development and which are focused on those aspects of
defining the project are most likely to either be involved early on or be represented for the early discussions regarding requirements. All stakeholders
must be represented during requirements analysis.
As with any set of requirements, not all stakeholder needs can be met.
There will always be some requirements that are not included or changed