264
Engineering Systems Integration
the system well into the deployment phase, the first-order stakeholder may
have a greater influence on the system than the internal stakeholder may.
Both the type and duration of stakeholder and system domain relationships
contribute to stakeholder influence (Ku 2007).
The selection of key stakeholders is based on the product of the stakeholder’s importance and influence. From these factors, the stakeholders are
ranked as primary, secondary, and tertiary entities based upon thresholds
determined by the analyst(s). Primary stakeholder needs have direct input
into the development of the system’s functional analysis and the overall measure of effectiveness model. Secondary stakeholder inputs have limited
weighting in the development of the functional analysis and the overall measure of effectiveness model. However, these stakeholders will be incorporated to the maximum extent possible within system boundaries, as described
in subsequent sections of this chapter. Tertiary stakeholder inputs are considered beyond the scope of this analysis and will not be incorporated into
the functional analysis and the overall measure of effectiveness model.
The final step of the stakeholder analysis is the definition of stakeholder
requirements. This step is closely related to the stakeholder requirements
definition process described in Revision 3 of the INCOSE Handbook,
which states: “The purpose of the Stakeholder Requirements Definition
Process is to elicit, negotiate, document, and maintain stakeholders’
requirements for the system-of-interest within a defined environment”
(INCOSE, 2006, p. 4.2).
After identification of the primary, secondary, and tertiary stakeholders,
problem statements can be developed. Langford et al. (2007) defines a problem in the following terms: “Whenever there is a difference between what
can be done and what you want to do, and you do not know how to achieve
the desire, there is a problem.” For every stakeholder problem, several stakeholder needs can be identified. A need arises from a condition faced by the
stakeholder that requires a solution to alleviate it.
Once stakeholder needs have been documented, they are used to derive
stakeholder requirements, which are essential for guiding system development and serve to frame the project scope (INCOSE 2006). These requirements drive the development of the functional analysis, the overall measure
of effectiveness model, and system architecture. In addition, the stakeholder
requirements are used in gap analysis to determine the desired state sought
by the stakeholder (“where we want to be”) and, in conjunction with the perceived existing state, establish the gaps to be addressed by the system
solution.
After the stakeholder analysis is completed, it is useful to evaluate the specific methods and their consequences through which the system can be
thought of and analyzed. For example, changes in certain policies may have
very visible impacts on the design of the system. It may be important to consider desensitizing the system design to small changes in policy using the
stakeholder sentience analysis as a feedback measure.
Engineering Systems Integration
the system well into the deployment phase, the first-order stakeholder may
have a greater influence on the system than the internal stakeholder may.
Both the type and duration of stakeholder and system domain relationships
contribute to stakeholder influence (Ku 2007).
The selection of key stakeholders is based on the product of the stakeholder’s importance and influence. From these factors, the stakeholders are
ranked as primary, secondary, and tertiary entities based upon thresholds
determined by the analyst(s). Primary stakeholder needs have direct input
into the development of the system’s functional analysis and the overall measure of effectiveness model. Secondary stakeholder inputs have limited
weighting in the development of the functional analysis and the overall measure of effectiveness model. However, these stakeholders will be incorporated to the maximum extent possible within system boundaries, as described
in subsequent sections of this chapter. Tertiary stakeholder inputs are considered beyond the scope of this analysis and will not be incorporated into
the functional analysis and the overall measure of effectiveness model.
The final step of the stakeholder analysis is the definition of stakeholder
requirements. This step is closely related to the stakeholder requirements
definition process described in Revision 3 of the INCOSE Handbook,
which states: “The purpose of the Stakeholder Requirements Definition
Process is to elicit, negotiate, document, and maintain stakeholders’
requirements for the system-of-interest within a defined environment”
(INCOSE, 2006, p. 4.2).
After identification of the primary, secondary, and tertiary stakeholders,
problem statements can be developed. Langford et al. (2007) defines a problem in the following terms: “Whenever there is a difference between what
can be done and what you want to do, and you do not know how to achieve
the desire, there is a problem.” For every stakeholder problem, several stakeholder needs can be identified. A need arises from a condition faced by the
stakeholder that requires a solution to alleviate it.
Once stakeholder needs have been documented, they are used to derive
stakeholder requirements, which are essential for guiding system development and serve to frame the project scope (INCOSE 2006). These requirements drive the development of the functional analysis, the overall measure
of effectiveness model, and system architecture. In addition, the stakeholder
requirements are used in gap analysis to determine the desired state sought
by the stakeholder (“where we want to be”) and, in conjunction with the perceived existing state, establish the gaps to be addressed by the system
solution.
After the stakeholder analysis is completed, it is useful to evaluate the specific methods and their consequences through which the system can be
thought of and analyzed. For example, changes in certain policies may have
very visible impacts on the design of the system. It may be important to consider desensitizing the system design to small changes in policy using the
stakeholder sentience analysis as a feedback measure.