System Analysis and Design

August 3, 2023

The analysis phase is so named because the term analysis refers

to breaking a whole into its parts with the intent of understanding
the parts’ nature, function, and interrelationships.

In the analysis phase, the systems analyst works extensively with

the business users of the new system to understand their needs from
the new system.

The basic process of analysis involves three steps:

■ Understand the existing situation (the as-is system).

■ Identify improvements.

■ Define requirements for the new system (the to-be system)

Sometimes the first step (understanding the as-is system) is

skipped or done in a limited manner. This happens when no current
system exists, if the existing system and processes are irrelevant to
the future system, or if the project team is using a agile development
methodology

Experience shows that it is useful to study the current situation

whenever possible. The insights gained from reviewing the existing
system can be quite valuable to the project team

To move the users “from here to there,” an analyst needs strong

critical thinking skills. Means moving the user from the existing
system to the new system

1|Page
Critical Thinking

- is the ability to recognize strengths and weaknesses and

recast an idea in an improved form.

- these skills are needed in order for the analyst to understand

issues and develop new and improved business processes that
are supported by information system technologies.

- these skills are essential in examining the results of

requirements discovery and translating those requirements into
a concept for the new system

Situational example:

The analyst could first have the users think about circumstances
leading to stock-outs and then describe the issues that lead to
these circumstances.

*stock-outs can be defined as the unavailability of specific items

or products at the point of purchase when the customer is ready to
buy

Example of stock-out Issues:

- supplier orders are not placed in a timely way

- on-hand inventory levels are updated only once a
week
- delays occur in identifying the best supply source
for the items
- delays occur in receiving approval of the supply
order

By focusing on these issues, the team is in a better position to

develop new business processes that address these concerns. The
new requirements will then be based on the issues that truly need
to be fixed. In this case, the requirements might include, in
part:

2|Page
 - The system shall update on-hand inventory levels twice
per day.

- The system shall produce an out-of-stock notification

immediately when an item quantity on hand reaches the
item reorder point.

- The system shall include a recommended supplier with

every out-of-stock notification.

- The system shall produce a supply purchase order that is

sent to the appropriate manager for approval.

- The system shall send an approved supply purchase order

to the supplier via secure electronic communication

As this situation example demonstrates, the analyst cannot

realistically expect that the true requirements for the new system are
easily gathered following a few conversations with the stakeholders.

The final deliverable of the analysis phase is the system

proposal, which compiles the detailed requirements definition
statement, use cases, process models, and data model together with a
revised feasibility analysis and work plan.

The system proposal is presented to the approval committee,

usually in the form of a system walk-through - is to explain the
system in moderate detail so that the users, managers, and key
decision makers clearly understand it, can identify any needed
modifications, and are able to make a decision about whether the
project should continue.

Before moving into the design phase, the project should be

reviewed to ensure that it continues to contribute business value to
the organization

If the system proposal was approved during the walk-through, the

system proposal components (requirements definition, use cases,
process models, and data model) are used as inputs to the steps in the
design phase, which further refine them and define in much more detail
how the system will be built

3|Page
Why do we need to determine the requirements when building a system?

▪ transform the system request’s high-level statement of

business requirements into a more detailed

▪ a precise list of what the new system must do to provide the

needed value to the business.

▪ This detailed list of requirements is supported, confirmed,

and clarified by the other activities of the analysis phase:
creating use cases, building process models, and building a
data model.

A requirement is simply a statement of what the system must do or

what characteristics it needs to have. During a systems development
project, requirements will be created that describe the following

▪ What the business needs (business requirements);

▪ what the users need to do (user requirements);

▪ what the software should do (functional requirements);

▪ what characteristics the system should have

(nonfunctional requirements);

▪ and how the system should be built (system

requirements).

We have already discussed the creation of the systems request in

the planning phase of the SDLC. In the system request, there are
statements that describe the reasons for proposing the systems
development project. These statements reflect the business
requirements that this system, if built, will fulfill.

These business requirements help define the overall goals of the

system and help clarify the contributions it will make to the
organization’s success.

4|Page
 Examples of business requirements include:

“Increase market share”;

“Shorten order processing time”;

“Reduce customer service costs”;

“Lower inventory spoilage”;

“Improve responsiveness to customer service requests”;

“Provide account access to mobile customers.”

When the systems development project is complete, success will be

measured by evaluating whether the stated business requirements have
actually been achieved; therefore, they provide the overall direction
for the project.

During the analysis phase, requirements are written from the

perspective of the business, and they focus on what the system needs
to do in order to satisfy business user needs. A good starting place
is to concentrate on what the user actually needs to accomplish with
the system in order to fulfill a needed job or task.

These user requirements describe tasks that the users perform as

an integral part of the business’ operations, such as:

“Schedule a client appointment”;

“Place a new customer order”;

“Re-order inventory”; “Determine available credit”;

“Look up account balances.”

Determining ways in which the new system can support user needs
leads to statements of the system’s functional requirements. A
functional requirement relates directly to a process the system has to
perform as a part of supporting a user task and/or information it
needs to provide as the user is performing a task. The International
Institute of Business Analysis (IIBA) defines functional requirements
as “the product capabilities, or things that a product must do for its
users.”

5|Page
 For example, assume the user requirement is “Schedule a client
appointment.”

The functional requirements associated with that task

include:

“Determine client availability,”

“Find available openings matching client availability,”

“Select desired appointment,”

“Record appointment,” and

“Confirm appointment.”

Notice how these functional requirements expand upon the user’s

task to describe capabilities and functions that the system will need
to include, allowing the user to complete the task.

Figure 1

As the analyst works with the business users of the system to

discover user and functional requirements, the user may reveal
processes that will be needed or information that will be needed.

6|Page
 For example, as shown in Figure 1, the user may state:

“The system must retain customer order history for three

years” (an information need).

The analyst should probe for the reasoning behind this

statement, such as:

“The system should allow registered customers to review

their own order history for the past three
years” (a process need).

Similarly, the user may state:

“The system should check incoming customer orders for

inventory availability” (a process need).

An alert analyst will recognize the related information need:

“The system should maintain real-time inventory levels at

all warehouses.”

User requirements and functional requirements defined in the

analysis phase will flow into the design phase, where they evolve to
become more technical, describing how the system will be implemented.

Requirements in the design phase reflect the developer’s

perspective, and they usually are called system requirements. These
requirements focus on describing how to create the software product
that will be produced from the project

7|Page
 The important thing to remember is that a requirement is a
statement of what the system must do, and the focus of requirements
will change over time as the project moves from planning to analysis
to design to implementation. Requirements evolve from broad statements
of overall business needs from the system to detailed statements of the
business capabilities that a system should support to detailed technical
statements of the way in which the capabilities will be implemented in
the new system.

The final category of requirements is nonfunctional requirements.

The IIBA defines this group of requirements as “the quality
attributes/feature/characteristics, design, and implementation
constraints, and external interfaces which a product must have.”

Although the term “nonfunctional” is not very descriptive, this

requirement category includes important behavioral properties that the
system must have, such as performance and usability.

The ability to access the system through a mobile device would be

considered a nonfunctional requirement. Nonfunctional requirements are
primarily used in the design phase when decisions are made about the
user interface, the hardware and software, and the system’s underlying
architecture.

Notice that the nonfunctional requirements describe a variety of

system characteristics: operational, performance, security, and
cultural and political. These characteristics do not describe business
processes or information, but they are very important in understanding
what the final system should be like.

8|Page
Figure 2

9|Page