Information Technology Reference
In-Depth Information
Requirements Analysis
The overall purpose of
requirements analysis
is to determine user, stakeholder, and organi-
suppliers and members of the purchasing department. Questions that should be asked during
requirements analysis include the following:
•
Are these stakeholders satisfied with the current accounts payable application?
•
What improvements could be made to satisfy suppliers and help the purchasing
department?
One of the most difficult procedures in systems analysis is confirming user or systems re-
quirements. In some cases, communications problems can interfere with determining these
requirements. For example, an accounts payable manager might want a better procedure for
tracking the amount owed by customers. Specifically, the manager wants a weekly report that
shows all customers who owe more than $1,000 and are more than 90 days past due on their
account. A financial manager might need a report that summarizes total amount owed by
customers to consider whether to loosen or tighten credit limits. A sales manager might want
to review the amount owed by a key customer relative to sales to that same customer. The
purpose of requirements analysis is to capture these requests in detail. Numerous tools and
techniques can be used to capture systems requirements. Often, various techniques are used
in the context of a joint application development session.
requirements analysis
The determination of user,
stakeholder, and orga-
nizational needs.
Asking Directly
One the most basic techniques used in requirements analysis is asking directly.
Asking
directly
is an approach that asks users, stakeholders, and other managers about what they
want and expect from the new or modified system. This approach works best for stable
systems in which stakeholders and users clearly understand the system's functions. The role
of the systems analyst during the analysis phase is to critically and creatively evaluate needs
and define them clearly so that the systems can best meet them.
asking directly
An approach to gather data that asks
users, stakeholders, and other
managers about what they want and
expect from the new or modified
system.
Critical Success Factors
Another approach uses critical success factors (CSFs). As discussed earlier, managers and
decision makers are asked to list only the factors that are critical to the success of their area
of the organization. A CSF for a production manager might be adequate raw materials from
suppliers; a CSF for a sales representative could be a list of customers currently buying a
certain type of product. Starting from these CSFs, the system inputs, outputs, performance,
and other specific requirements can be determined.
The IS Plan
As we have seen, the IS plan translates strategic and organizational goals into systems devel-
opment initiatives. The IS planning process often generates strategic planning documents
that can be used to define system requirements. Working from these documents ensures that
requirements analysis will address the goals set by top-level managers and decision makers
(see Figure 12.21). There are unique benefits to applying the IS plan to define systems re-
quirements. Because the IS plan takes a long-range approach to using information technology
within the organization, the requirements for a system analyzed in terms of the IS plan are
more likely to be compatible with future systems development initiatives.
Strategy
translation
Figure 12.21
Goals and mission
of the organization
Systems
requirements
Converting Organizational
Goals into Systems
Requirements
Screen and Report Layout
Developing formats for printed reports and screens to capture data and display information
are some of the common tasks associated with developing systems. Screens and reports
