Information Technology Reference
In-Depth Information
to-be vision of compliance management, an as-is snapshot of compliance man-
agement, a gap analysis, a remediation analysis, and a transition plan. Figure 6.1
provides example IA considerations with respect to IA compliance management in
context of the IA
2
views.
Recording the requirements in a series of traceability matrices is essential to
tracking
what needs to be done
and
why it is being done
. If business drivers change,
there needs to be the ability to isolate that part of the solution that is affected by
the change. A traceability matrix is also a useful reference as memories fade and
initial motivations behind particular business functions are lost. Too often, the
justification for a business operation is “well, that's just the way it's always been,”
which is the most unforgivable excuse for continuing a business practice. The
traceability matrix provides a living document that aligns business practices to
the business motivations behind them, including IA practices and their respective
business risk motivations.
6.4
iA requirements engineering and Se
The SE process begins with a
request
for a capability, product, or service. The request
may be a business need (business driver) or a technical need (technical driver). The
first step to fulfilling the request is a
system design
, which includes requirements
engineering and a solution definition. Requirements engineering is the process of
identifying, enumerating, articulating, and addressing the specifications for the
capability, product, or service. The solution definition uses a work breakdown struc-
ture (WBS) to define the component parts of the solution and how the component
parts fit together. The solution definition maps to the requirements in a formally
constructed set of tables known as a requirements matrix. The SE process continues
with the production and delivery of the system (the realization of the capability,
product, or service). Moreover, SE provides for
technical management
that includes
project planning, scheduling, and general oversight for the SE process.
IA requirements engineering is the process of identifying
risks to
the capability,
product, or service and
risks caused by
the capability, product, or service. IA require-
ments engineering also identifies risks to the success of the SE process itself; for
example, a lack of input from representatives of the business side is a risk to fully
capturing and understanding the business requirements.
In a hypothetical example, market research shows that an E-commerce site
will increase profits by 25 percent; therefore, the business objective is to establish
an E-commerce presence that includes business-to-business transactions via pri-
vate communications and business-to-consumer transactions via the Internet. This
business objective prompts many activities to design an enterprise solution. Part
of the architectural process is to use the IA
2
P and IA
2
F to identify, enumerate,
articulate, and address the risks. One manner of addressing risk is to mitigate risk,
