NASA Technical Reports Server (NTRS) 20040086930: Goals Analysis Procedure Guidelines for Applying the Goals Analysis Process

12 Pages·0.79 MB·English

by  NASA Technical Reports Server (NTRS)

GOALS ANALYSIS PROCEDURE
GUIDELINES FOR APPLYING THE GOALS ANALYSIS PROCESS
Albert E. Motley III, NASA Langley Research Center, Hampton VA.
Abstract Introduction
One of the key elements to successful Goals analysis is predicated on the fact
project management is the establishment of the that no project operates in a vacuum; there are
"right set of requirements", requirements that interfaces between the customer, the builder,
reflect the true customer needs and are and the environment,2 or the rest of the world
consistent with the strategic goals and (figure 1). The participating organizations at
objectives of the participating organizations. A each of these interfaces represent potential
viable set of requirements implies that each sources of goals and objectives that may
individual requirement is a necessary element influence the requirements of the system under
in satisfying the stated goals and that the entire development.
set of requirements, taken as a whole, is
sufficient to satisfy the stated goals.
Unfortunately, it is the author's experience that
Figure 1. The Environment today2
during project formulation phases' many of the
Systems Engineering customers do not conduct I
a rigorous analysis of the goals and objectives
that drive the system requirements. As a result,
the Systems Engineer is often provided with
requirements that are vague, incomplete, and
internally inconsistent. To complicate matters,
most systems development methodologies
assume that the customer provides
unambiguous, comprehensive and concise
requirements.
This paper describes the specific steps
of a Goals Analysis process applied by Systems
Engineers at the NASA Langley Research
Figwe 1.1. The environment loday
Center during the formulation of requirements
for research projects. The objective of Goals
The author believes the concept of
Analysis is to identify and explore all of the
Goals Analysis is analogous to the concept of
influencing factors that ultimately drive the
Requirements Analysis. Where the latter
system's requirements.
establishes a trade space, or region of feasible
1 NPG-7120.5 Proeram and Project Management Process and 2 Blanchard. B. S., Systems Eneineerine Manaeement, 3rd ed., Wiley-
Reauimnents, rev A. NASA. April 1998, p 18. Interscience, 1991, figure 1.1, p 2.
I
unbound world of human needs5 Most
-
Figure 2. Trade Space Region of literature on the subject of Systems
Feasible Solutions3 Engineering methodology illustrates the
Systems Analysis and Development process as
some form of flow diagram where the customer
needs or requirements are an input to the
process. While the process may contains steps
-
,306 + 10f 135 - to validate the customer inputs, seldom does
2oE + 10f 160 the process include explicit steps to assist the
~
Systems Engineer in developing and refining
these inputs.
Figure 3. Influence Space: Region
of Overlapping Interests."
_.------- .-__.
,.He 5-
solution (figure 2),3t he author suggests that the
former establishes an influence space (figure
3),4 or region of overlapping interests. It is the
author's belief that the source of all
requirements driving the system's design are
captured within the goals and objectives that
define the boundaries of a fully developed
influence space.
It is also the author's belief that
rigorous application of Goals Analysis, to seek
out and explore all the interfaces and associated
influence factors, will lead to better and more
There is literature, such as that by
rapid requirements development and the
Rechiten: which provides useful Goals
minimization of requirements creep.
Analysis techniques. These techniques
encourage the Systems Engineer to work with
Why is Goals Analysis Needed? the customer to progress from problem
statement to systems solution. Included are
It is the Systems Engineer's task to
such processes as working the problem
bring structure, in the form of a systems
statement forwards, from problem to solution,
solution, to an inherently ill-structured and
and then working it backwards, from solution
to problem. Another approach is to generalize
3 Eppen. Gould, and Schmidt, Introduction to Management Science, 5 Rechtin, Eberhardt, Svstems Architecting - Creating & Building
4th ed., Prentice-Hall, 1993, figure 3.7, p 102.
Comolex Svstems, Prentice-Hall, 1991, p 1.
4 Motley, Albert, Goals Analvsis Process, an internal document of the
6 ibid.. p 54.
Systems Engineering and Controls Branch, NASA, May 1999.
2
the problem statement then attempt to focus on requirements are given by the customer and not
specific problem solutions. A third technique a product of the process. While the model's
is to explore multiple parallel problem formulation steps include "determining the
solutions based on partial evidence of a system objectives and constraints."' The
solution's viability. A final suggestion is the author agrees with statements by Forsburg and
use of analogies and metaphors to relate the Mooz that the specific role of systems
current problem with previous system engineering, and particularly the steps of a
solutions. However, Rechiten is quick to point goals analysis process, in this model are
out that these techniques must be used with obscured.8
careful judgment and that they are best applied
Again, in the "Requirements
in cases where just "...a few leaps of
Interrelationships and Supporting Data"
imagination may bring the problem and
diagram by Grady,' (figure 5) the customer's
solution together.lt6 The author has found that
needs are illustrated simply as an input box to
techniques of this nature are generally not very
the diagram. No part of the process provides a
useful when working with new, large, and
structure for developing the needs.
complex problems.
Figure 5. Requirements
Figure 4. Bomen Spiral Diagram'
Interrelationships and Supporting Data'
During the Systems Definition phase of
[email protected] fqljk 5z-l the "Integrated Waterfall Model''1o (figure 6),
Sage assumes that the group developing
PM 9005 2-12
systems requirements are "...sufficiently
Boehrn's (1988b)s piral modcl or the
software process informed about the intended purpose of the new
or modified system such that they can identify
Bohem's spiral model,7 (figure 4) is
perhaps one of the most frequently referenced 8 K. Forsberg, and H. Mooz, "The Relationship of Systems
illustration of the structured systems process. Engineering to the Project Cycle," Proceedings of the F'irst Annual
However, this model also assumes the Svmoosium of NCOSE, 1991, exhibit 4, p 58.
9 Gradey, Jeffrey 0..Sv stems Requirements Analvsis, McGraw-Hill
1993, figure 4.2, p 113.
7, Boehm, B.W. "A Spiral Model of Software Development," Software
Eneineerine Proiect Management, IEEE Computer Society Press, 1988, 10 Sage, Andrew P., Svsterns Engineering, Wile Interscience. 1992,
pp 128-142. figure 1.6, p 17.
3
Figure 6. Integrated Waterfall Model" process to the very first inception of a system's
need by the Customer.
Figure 7. Blanchard Software Life Cycle"
--
and develop the system level requirements in
sufficiently complete detail. .., 111 Again, no
structured process or methodology is provided I 1
to assist in the development and definition of a
Customer's needs into a set of system goals.
t
Finally, in Blanchard's "Software Life
Cycle" model,12 (figure 7) the entry block is
titled "Identification of the Need" with an
associated statement in the text that reads "this
information is generally included in a software
requirements specification. This portion of
the text does include a reference to Functional
Analysis from a previous section in the book,
but that topic deals primarily with the
translation of systems requirement into detailed
design criteria. The very next block on the
diagram jumps directly into "Systems pipn 3.25. sdcvrm tire cycle
Conceptual Design" with no provision or
mention of Goals Analysis. I21
The lack of readily available
methodology, or specific process steps, to
perform goals analysis is not a criticism of the Goals Analysis Process.
work published by the authors referenced in
Typically, at the inception of a new
this paper but rather an observation by this
project, the customer has already identified a
author of the need to push Systems Engineering
set of top level goals that he/she believes are
methodology further back into the lifecycle
necessary to fulfill a perceived needs. The
engineering group accepts these goals, then
I1 Sage, Andrew P., Svstems Eneineering, Wile Interscience, 1992, develops a system concept to fulfill the needs.
figure 2.3, p 49.
Paramount to the success of any
12 Blanchard, B. S., Svstems Eneineering Management, 3rd ed.,
undertaking is the clear and coherent statement
Wiley-Interscience. 1991. figure. 3.25, p 121. of what is to be accomplished. Without a
13 ibid.,p 121. concise statement of the goals, there is very
4
little chance of establishing direct linkage or has an interest in the project's final results.
between the customer's needs and the system The relationship between the project and the
designed to satisfying those needs. Unless this partner can generally be classified into three
linkage is clearly established then it is all too categories: Vested Interest Partners,
easy to ... make an error of the third kind - Contributing Partners, and Influential
"
solving the wrong pr~blem."'~ Independent Partners.
The Goals analysis process outlined in Vested Interest Partners are those
the remainder of this paper is designed to help individuals or organizations who have a
the customer fully explore all the factors that strategic stake in the project. In other words,
influence the perceived system's need and to the strategies they have incorporated into future
articulate the most general top-level goals and plans are dependent on, or affected by, the
objectives. The process also helps the success of the project. Vested Interest Partners
engineering group understand the influencing are generally the source of objectives that must
factors driving the goals, which ultimately flow be accomplished by the systems under
down to a quantifiable set of performance consideration.
requirements for the system to be developed.
Contributing Partners are those
As the architecture of the systems individuals or organizations who are involved
concept is refined and detailed, subsequent with the project but only from a current
iterations of the Goals Analysis Process allows business perspective. In other words, the
for development of lower and lower levels of success or failure of the project does not affect
system requirements, which tie directly to the strategies of their future plans (aside from
project upper level goals. the failure of any given business venture
affecting an organizations future plans).
Contributing Partners are generally the source
Participants in the Goals Analysis
of constraints that limit the bounds of viable
Process
solutions for the system under consideration.
The following people, or organizations,
Influential Independent Partners are
should participate in the Goals Analysis
those individuals or organizations that have the
Process: the Program or Project Manager, the
ability of affect the project, but they are not
Lead Systems Engineer, the Systems
involved from a current business perspective or
Engineering Support Team, representatives
from a strategic future perspective (partners of
from the Customer, representatives from the
this type are often known as political friends or
User group, representatives from Engineering
foes). Advocacy from Influential Independents
Management, and representatives from each of
may come at a price; that price often takes the
the identified Partners.
form of additional objectives for the system to
accomplish. Opposition from Influential
Identification of Partners.
Independents often takes the form of additional
The first step in establishing the constraints that further limit the bounds of
boundaries of the Influence Space is the viable solutions for the system under
identification of partners. For the purpose of consideration
this paper, a partner refers to any individual or
It is quite possible that any given
organization that is participating in the project
partner may fall into more that one
classification. This is not a problem as the
14 Rechtin, Eberhardt, Svsterns Architectine - Creatine & Building classifications are actually just constructs to
cornulex Svsterns, F'rentice-Hall, 1991, p 53. assist the customer in exploring and identifying
5
potential partners in a way that may not have each offering a new insight as to the relative
been readily apparent. value of each partner to the project.
A technique for helping the customer Outputs: Weighted listing and
identify partners is to ask questions such as: description of each metric to be used.
“Who does the Customer want to know
0
Ranking Each Partner’s Relative
about this project?”
Importance to the Project
“Who does the Customer want to
0
In this step, the list of Activity Partners
participate in this project?”
is sorted in accordance with the metrics just
“Who might want to know about what the
0 developed. The reason for ranking partners at
Customer is doing?”
this stage of the analysis is often difficult to
understand, but doing so now will prove
“Who will the project, or the final results,
invaluable during subsequent steps when
affect?
‘I
resolving priority issues between partners
The process of identifying Activity
becomes important. At this point it may be
Partners should result in a listing of individuals
convenient (for future requirements tracking
and organizations that may/will/should be
and flow down purposes) to assign unique
involved with the planning, development,
identification numbers or letters to each
implementation, and operations of the system
partner.
under consideration.
Outputs: Partner list ranked according
to the metrics.
Establish the Metrics for Ranking the
Partners
Document the Current Situation
Once the Partners have been identified
This is the process of establishing and
they must be sorted in relative priority or
documenting the status quo. It is important to
significance of the partner to the project. Such
seek out and solicit support from those
a sorting requires a set of metrics for ranking
individuals most experienced in the technical
each partner. The significance of each metric
fields related to the project. Research, to
must be in terms of value to the customer or
establish a complete understanding of the
influence over the project. Several different
current situation’s status and how it evolved, is
criteria may be used in sorting the partner list.
the key to this step. Benefits of this step
For example, one sorting may be by funding
include a deeper understanding of the problem
source. In other words, the most likely or the
and lessening the possibility of duplicating
largest funding partner would be ranked higher
previous efforts.
on the list. A second sorting order may be by
technical expertise. In other words, the The narrative of this Current Situation
partners with the critical technical capabilities Document should delineate both the positive
or skills would be ranked higher on the list. and the negative aspects of the status quo.”
Another possibility is to sort the partners by Developing this narrative is best accomplished
political advocacy. In other words, the most through group interaction with representatives
influential political advocates or foes would be from all project Partners.
ranked higher on the list.
Outputs: Current Situation Document.
Generally, a project can identify several
different metrics for sorting the partner list,
~~ ~
15 Walters, J. Milam, ESSM Goals Analvsis Effort, an interna!
document of the Systems Engineering Office, NASA, April 199 1. p 1
6
Develop the Issue Base individual. However, if the issues have been
expressed as compound statements, then
The purpose of this step is to identify
consolidation will be a very difficult task that
the issues of each Partner in reference to the
requires the entire team to accomplish.
system under consideration. These issues
become the basis for each of the systems goals A useful technique is to generate a table
or subgoals. A good place to start is by of issues (similar to the "what" axis of a QFD
exploring the Strategic Plans of each Partner. Correlation Matrix).16 Be sure to include a
The Systems Engineer must work with each of column for mapping issues back to each and
the Partners to identify supporting and every partner sharing that issue. Also, each
conflicting elements within their plan relative issue listed in the table must be uniquely
to the system under consideration. It is helpful identified. When two or more partners share
to ask questions such as "How will the system the same issue, it is often convenient to adopt
under consideration support or hinder the the issue identification of the highest ranked
Partner's future activities?" Each issue should partner. This helps reduce the "proliferation of
be assigned a unique identification number or identifiers'' and helps to maintain tracking and
letter that is a composite of the originating flow down of the issues from the source
Partner's identification. This will be important partners.
for future requirements tracking and flow down
Outputs: A System's Issue Table that
purposes.
lists each unique issue.
Avoid the use of compound statements.
Try to decompose the issues such that each
Prioritize the Systems Issue Table
statement relates to a single issue and each
This is perhaps the most difficult step in
issue is contained in a single statement.
the Goals Analysis Process. The customer, in
Decomposing the issues into basic statements
concert with the Partners, must agree to the
will simplify the latter process of consolidating
priority order of the System's Issue Table. In
redundant issues and converting issues into
general, the issues of higher ranked partners
Goals Statements.
receive higher-ranking priority, but this is not
Outputs: Summary report describing the
always the case. The Systems Engineer should
issues each partner has with the system under
anticipate significant negotiation and
consideration.
compromise between the partners before an
iteration of this step is completed
Consolidation of the Issue Base into
Outputs: A prioritized System's Issue
the System's Issue Table (the "Super
Table.
Set" of Issues)
The objective of this step is to Develop Preferred Future
consolidate the common or shared issues so
The Preferred Future describes the
that each issue is listed only once. Often, the
combined Partners' view of the system upon
issues of different partners will partially or
successful completion of the project. This view
fully overlap. If all the issues were represented
must include the interfaces and how they
in graphical form, the results would be a large
operate. It is frequently prefaced by a "Vision
and complex Venn diagram.
Statement," a description of the desired
If the contents of the Issue Base have accomplishments in relation to other efforts.
been properly developed into basic statements,
then consolidation is almost a clerical level task 16 OFD Awareness Training, Quality Education and Training Center,
that can be accomplished by a single Ford Motor Corporation, 1989, p 26,
7
This provides a clear understanding of where considered. Generalization of the top-level goal
the efforts are pointed and what can be is designed to take the problem addressed by
expected upon completion of the project. This the system out of its narrow context and
portion of the analysis can be very helpful in explore more general considerations. In other
solidifying required constituencies. Minimally, words, what is the real problem? The primary
the narrative should contain all the positive method of achieving this generalization is a
aspects described in the Current Situation as rigorous questioning of the stated top-level
well as corrections to all the negative aspects." goals. Typical considerations include:
Ideally, development of this narrative will
stimulate ideas that are strides beyond the 0 Why is the goal stated this way?
current situation. Care should be taken to
Are there underlying goals not brought to
0
prevent description of an idealized future that is
light which affect the wording, i.e. politics,
unrealistic from the expected cost and schedule
personal agendas, etc?
constraints as well as to prevent over
achievement of the actual needs. However, no Is the stated goal truly the objective or a
0
plans should be discounted in the early means of achieving some other objective?
iterations of Goals Analysis, since those that
The purpose is to guard against a
are overly optimistic will be removed through
technically acceptable system that is infeasible
validation and in subsequent iterations.
for other reasons and to assure that the true
Outputs: Preferred Future Document. objective is pursued." Included is
consideration of those directly or indirectly
affected by the project. This may be
Generate Goals and Objectives
accomplished in part by listing the political
Statements
advantages of meeting the goal as well as
In this step the issues of the Systems possible drawbacks of pursuing the goal. If
Issue Table are translated into Goals opposition from the Partners, in particular from
Statements. Each issue is rewritten into an the Influential Independent Partners, appears
objective statement such that accomplishing unmanageable, then a modification of the goals
that particular objective will resolve the issue. may be in order.
Again, try to avoid the use of compound
The most effective method of
statements. Try to keep each statement a single
performing this step is an interactive group
Goal and each Goal a single statement.
session. Brainstorming and Brainwriting2'
19 20
All the Goals and Objectives generated
are good methodologies to follow. The main
directly from the System's Issue Table are point is that all inputs are heard and considered.
known as the root set or the set of imposed
System Goals and Objectives. All the Goals
and Objectives generated later in the process,
for the purpose of providing logical continuity
in the formation of a Goals Tree, are known as
18 ibid., p 1.
derived Goals and Objectives.
Possibly the most critical facet of any 19 deBono, Edward, "Lateral Thinking - Creativity Step by Step,
project is the correct and concise statement of Harper & Row, 1970, p 149.
the top-level goal(s). The exact wording of this
20 Adams. James, Conceptual Blockbusting, 3rd ed. Addison-Wesley
objective is crucial and must be very carefully
Publishing, 1986, pp 134 - 137.
21 Wycoff. Joyce and Richardson.Tim, Transformation Thinking,
17 Walters. J. Mila m,, - an internal
Berkley Publishers Group, May 1995.
document of the Systems Engineering Office, NASA, April 1991, p 2.
8
Outputs: Concise and understandable branch of the hierarchy requires no more
top-level Goal Statement(s) and "root set" of definition or decomp~sition.~~
imposed System Goals and Objectives.
Individual subgoals are arranged into a
hierarchical representation. This is easily
Partner Value Considerations accomplished by writing each goal statement
generated from the Systems Issue Table on a
An area rarely considered in goal
card and arranging them so that each lower
development is the values of concerned and
level assists in the accomplishment of the next
affected Partners. This issue is included to
higher level. As the development progresses,
amplify and articulate the underlying personal
the lowest level goals are expanded further by
goals contained in the Goal Statements and
discussion with the cognizant organizations.
Preferred Future Document. Paramount for
When gaps occur in the diagram, where
consideration are the values of partners with
imposed goals (or goals generated from the
decision authority over continuation of the
Systems Issue Table) are insufficient to provide
project22. This should lead to a reiteration of
a logical flow between levels, then derived
the potential advocate/foe list and the
goals (or goal statements generated during the
reevaluation of the reasons for their
analysis process strictly for the purpose of
support/opposition. The purpose of personal
maintaining logical continuity) must be
goals and values that are unrelated to accepted
synthesized and inserted. Progressing in this
project goals should be removed in this step.
manner assures that every objective by project
The considerations are designed to resolve
personnel, even on the lowest level, is directly
unstated, non-technical conflicts contained in
tied to the project's top level goal.
the top level goal and vision statements for the
project. The result of this effort is a graphical
hierarchical representation of the project goals,
Output: Conflict resolution of non-
which contains technical and non-technical
technical issues.
requirements at the terminating branches. The
representation takes the approximate form of an
Develop the Goals Tree
organizational chart. One output of the effort is
In this step, the top-level goal a set of technical requirements for the project.
developed in the previous step is decomposed The tree may also provide information that
and mapped into subgoals of narrower scope. affects non-technical requirements such as cost
Subgoals are objectives, which if and schedule.24
accomplished, assist in satisfying the next
Two useful tests on the structure of the
higher level goal. Typically, the major
Goals Tree are: 1) to ask if each individual goal
subgoals of the project will become the top-
on a given level is a necessary element to
level goal for project support organizations.
fulfilling the next higher level, and 2) if all the
For example, if a subgoal of the project is to
goals as a set on a given level are sufficient to
maintain instrument temperature to within 5"
fulfill the next higher level. Additional
K, this may become the top-level goal for the
decomposition and expansion are required until
thermal-control organization. The expansion of
the goals of each level can pass these two tests.
goals may be terminated when a given subgoal
is measurable. When a subgoal is capable of Output: Goals Tree
being indisputably judged as satisfied, that
22 Walters. J. Milam, ESSM Goals Analvsis Effort, an internal 23 ibid.. p 3.
document of the Systems Engineering Office, NASA, April 1991, p 2. 24 ibid.
9
Validate Quality Functional Deployment (QFD).27 But
that is a topic for another paper.
At this point, the process departs from
earlier sub'ective considerations and becomes
objective." The outputs of previous steps are Acknowledgements
now scrutinized. Through editing, selection,
Although this paper was not co-
comparison, etc., a validated version of the
authored, credit must be shared with my
work to date is produced. Where criticism was predecessor, Mr. J. Milam Walters, for his
previously discouraged, it is now invited. The efforts at formalizing the Goals Analysis
purpose is to decide which facets of the work Process applied to developing space flight
truly belong, which may be deleted, and which projects at the NASA Langley Research Center.
insures that a logical flow down has been
developed.
References
Output: Validated version of work to
[l] NPG 7120.5 Program and Proiect
date
Management Process and Requirements, rev A,
NASA, April 1998.
Iterate the Process
[2] Blanchard, B. S., Systems Engineering
Much of the power of the systems
Management, 3rde d., Wiley-Interscience, 1991 .
approach comes from the idea of iteration by
[3] Eppen, Gould, and Schmidt, Introduction to
one-pass analysis.26 This allows the individual
Management Science, 4* ed., Prentice-Hall,
steps to be performed at a general level during
1993.
the early iterations, then defined in further
detail during subsequent iterations. Also this [4]M otley, Albert, Goals Analysis Process, an
enables incremental refinement of the output internal document of the Systems Engineering
for each step as understanding of the entire and Controls Branch, May 1999.
system, gained through repeated iterations of
[5] Rechtin, Eberhardt, Systems Architectina -
the process, is continuously improved.
Creating & Building Complex Systems,
Output: Improved Goals Analysis Prentice-Hall, 1991 .
[6]B oehm, B.W., "A Spiral Model of Software
Conclusions
Development," Software Engineering Proiect
This paper has described the specific Management, IEEE Computer Society Press,
steps of a Goals Analysis process applied by 1988.
Systems Engineers at the NASA Langley
[7] K. Forsberg, and H. Mooz, "The
Research Center. Projects that apply this
Relationship of Systems Engineering to the
process to the early phases of a research project
Project Cycle," Proceedings of the First Annual
will improve their understanding of factors
Symposium of NCOSE, 1991 .
influencing the project and perhaps lead to
better requirement development with a reduced [8] Gradey, Jeffrey O., Systems Requirements
chance of requirement creep. The outputs of a Analysis, McGraw-Hill, 1993.
Goals Analysis will provide excellent input for
[9] Sage, Andrew P., Systems Engineering:,
a Requirements Analysis process such as
Wile Interscience, 1992.
27 Sullivan, L. P.. "Quality Function Deployment - A System To
25 Walters, J. Milam, ESSM Goals Analvsis Effort, an internal
Assure That Customer Needs Drive The Product Deslgn And
document of the Systems Engineering Office, NASA, April 1991, p 4.
Production Process,'' Oualitv Progress Magazine, June 1986, pp 39 - 50
26 ibid.
10