Information Technology Reference
In-Depth Information
Business Requirements
As the name suggests, these identify the business drivers and behaviors
for which the work is being initiated. For example, the need to submit
tax returns annually, or raise appointment letters for new hires, could be
a business requirement, which requires building a new application, or
making an enhancement to an existing application. Although these require-
ments are called business requirements, they are business requirements
directed at systems personnel by the business user. The business user
might have created a different set of business requirements, directed at
other business users, to make a business case for those requirements.
What should a good business requirements document contain? First
and foremost, it should identify the business end state that one wants to
achieve — file the tax returns, hire the employee, and work backwards.
A business requirement often stays at the “true” system level.
Systems Requirements
These are the business requirements that have been converted to appli-
cation and system functionality. The business need to file tax returns
annually converts into a systems requirement to create or enhance a tax
preparation system. A business requirement to provide 24/7 support
becomes a systems requirements to implement an online self-service Web
site.
Systems requirements correspond to the “S” layer of the SEE (Solution,
Engineering, Execution) model. There may be multiple solutions that can
satisfy the business requirements. Some of these solutions may involve
non-software solutions. All, however, must be considered.
Whose responsibility is it to consider all the options? If the responsibility
was assigned to the Information Systems department, there would be a
natural tendency to propose or prefer an information systems solution.
Businesses need a
group that is at a level above Information
Systems. At times, the Strategy group, if there is one, can play this role.
Others who could take this mantle are the business users themselves or
a combination of business users and solution analysts. Solution analysts
are different from requirements analysts, who would be interacting with
business users to gather detailed requirements later in the process. These
roles could be played by the same person as long as the roles are well
understood.
Solutions
