Information Technology Reference
In-Depth Information
business functions, workflow, tasks, systems, subsystems, and components, there is
need to decompose this high-level requirement into manageable and understand-
able pieces—pieces that have meaning to day-to-day operations. The stated require-
ment in the example above is at least in business terms. At times, you will receive
requirements from the business side in technical terms; e.g.,
to better manage pro-
duction, inventory, and shipping schedules, we want a database of customer purchases
.
In this case, the iterative process for decomposing the requirement starts with ask-
ing the requestor to restate their requirement in business terms. Perhaps a database
is the right solution and perhaps not, and there may be much more needed than just
a database. That determination follows understanding the business need.
You may receive business requirements in terms of “we need to comply with
Sarbanes-Oxley.” Approaching this requires decomposition of the legislation into
requirement statements. Subsequent requirements for modifying the organizational
operating environment, workflow, and systems will all trace to one or more of these
legislative requirement statements.
6.2 objecties
The objective of this chapter is to present IA requirements engineering as another
tool in the IA
2
toolkit. The material in this chapter will enable you to determine,
align, record, and track business drivers behind IA solutions.
6.3 iA requirements engineering
and Compliance Management
Every business driver may be articulated as a compliance requirement. A compre-
hensive compliance management program addresses all organizational require-
ments, including legislation, regulation, directives, instructions, codes, mission,
stakeholder objectives, policies, standards, procedures, etc.
IA compliance manage-
ment identifies all compliance requirements that dictate the organization's IA posture.
Compliance requirements include those external and internal to the organization.
External requirements are those imposed upon the organization by sources outside
the organization, like regulatory bodies, national laws, and local codes. Internal
requirements are self-generated or self-imposed to guide organizational behavior
and include a mission statement, policies expressing organizational behavior, stan-
dards to express what to use to implement and enforce policies, and procedures to
express how to use the standards. All of these compliance requirements are candi-
dates for business drivers.
Although all are candidates for business drivers, you need to discern which
apply to the problem at hand. Moreover, any given compliance source may apply in
