| Business Requirements |
Business
Requirements
As mentioned before, the output of each step is typically
the input to the next step in the process.
In this step the statement from step 1 is
used to generate the Business Requirements (BR), which is the highest level of
requirement. It is the statement, or statements, that describe what capabilities
the business needs to have developed. The BR should not have any mention of a
solution or specification of tool to address the required capability. For
example, a BR of “We need to be able to send a message to individual agents” is
a legitimate BR. “We need to send an e-mail via outlook to individual agents” is
not a good BR. It is a possible solution that would appear in the High-Level
and/or Detailed Specifications but the specificity of the type of message and
the delivery agent are inappropriate for a BR. BR are used to create the use
cases necessary for requirements decomposition.
During the Private Cloud POC we generated several BR as
listed below:
|
ID
|
Assoc
ID |
Type
|
Technical
Assumption(s)
and/or Customer Need(s) |
Functional
Requirement |
|
BR
|
1.0
|
BR
|
User should be able
to select from a collection of predefined system
configurations.
|
The system shall
provide predefined system configurations.
|
|
BR
|
2.0
|
BR
|
|
The system shall
deploy servers in an automated fashion based on user
requests.
|
|
BR
|
3.0
|
BR
|
User should be able
to modify appropriate configuration parameters within limits.
|
The system shall
allow modification of configuration parameters.
|
|
BR
|
4.0
|
BR
|
User should be able
to request various levels of resources based on requirements (T-shirt
sizes).
|
The system shall
allow resources to be assigned by template.
|
|
BR
|
5.0
|
BR
|
Solution must be
well documented and straightforward to deploy.
|
Solution must be
well documented and straightforward to deploy.
|
|
BR
|
6.0
|
BR
|
Solution fulfills
requests faster than the manual process that exists today.
|
Solution fulfills
requests faster than the manual process that exists
today.
|
|
BR
|
7.0
|
BR
|
|
System shall report
on usage, capacity, and performance.
|
Obviously, the ID and Type of BR indicate that these are
the Business Requirements. In order to trace the specifications and functional
requirements back and show that the BR are being met an Association ID is
created also. We have a description and then the actual
requirements.
While it is not a part of the EPP, a very effective
output from the BR step is a Concept of
Operations or
Conops. This document outlines the changes to IT resources, personnel, process,
and security that would be affected by the design. It presents the business need
at a much more detailed level and can be used to help flush out the Functional
Requirements. Use
Cases are a
common component of the Conops, however, sometimes these are not generated until
the BR are being decomposed into the FR. A Conops is similar to the HLA in EPP
but is much more comprehensive.
If the business need affects an existing system it is
effective to do some process flows. Swim Lane diagrams are easy to understand
flows of processes and decisions. They are useful for depicting existing
processes and the change to the process being designed to satisfy the business
need. The Enterprise Architecture group has a group of individuals that does
this Business Process Management (BPM) analysis on a daily basis as needed. An
example of the current process for deploying servers is located here. We used these diagrams and other artifacts to more
clearly define our business need into our business
requirements.
This is the start of Design Morphology as part of the
Design Process.