PASSI CITY COLLEGE

City of Passi, Iloilo

SCHOOL OF INFORMATION AND COMMUNICATION TECHNOLOGY

COURSE NUMBER: IT ELECT 1

COURSE TITLE: System Analysis and Design
MODULE: 3

OVERVIEW:

Systems Analysis and Design (SAD) is an exciting, active field in which analysts continually
learn new techniques and approaches to develop systems more effectively and efficiently.
However, there is a core set of skills that all analysts need to know no matter what approach
or methodology is used. All information systems projects move through the four phases of
planning, analysis, design, and implementation; all projects require analysts to gather
requirements, model the business needs, and create blueprints for how the system should be
built; and all projects require an understanding of organizational behavior concepts like change
management and team building.

MODULE OUTCOMES

At the end of this module, the students must have:

 Explain the analysis phase of the SDLC

 Describe the content and purpose of the requirements definition statement
 Classify requirements correctly as business, user, functional, or nonfunctional requirements
 Employ the requirement elicitation techniques of interviews, JAD sessions, questionnaires,
document analysis, and observation
 Define the role that each requirement elicitation technique plays in determining requirements
 Describe several analysis strategies that can help the analyst discover requirements

INSTRUCTOR: EFREN B. LAZARTE PAGE NO. 1

IT ELECT 1 – SYSTEM ANALYSIS AND DESIGN MODULE NO. 3
THE ANALYSIS PHASE

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 context of
the SDLC, the outputs of the planning phase (the system request, feasibility study, and project plan),
outline the business goals for the new system, define the project’s scope, assess project feasibility,
and provide the initial work plan. These planning phase deliverables are the key inputs into the
analysis phase. 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 (i.e., 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 RAD or agile development methodology in which the
as-is system is not emphasized. Tra¬ditional methods such as waterfall and parallel development (see
Chapter 2) typically allot significant time to understanding the as-is system and identifying
improvements before moving to capture requirements for the to-be system. Newer RAD and agile
methodologies, such as iterative development, system prototyping, throwaway proto¬typing, and
extreme programming (see Chapter 2), focus almost exclusively on improvements and the to-be

INSTRUCTOR: EFREN B. LAZARTE PAGE NO. 2

IT ELECT 1 – SYSTEM ANALYSIS AND DESIGN MODULE NO. 3
system requirements, and they devote little time for investigating the current as-is system. 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 think-

ing skills. 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 exam¬ining the results of requirements discovery and translating those requirements
into a concept for the new system.

As an example, let’s say that a user states that the new system should “elimi-nate inventory stock-
outs.” While this might be a worthy project goal, the analyst needs to think about it critically in order
to formulate the statement in terms of use¬ful requirements. The analyst could first have the users
think about circumstances leading to stock-outs (e.g., supplier orders are not placed in a timely way),
and then describe the issues that lead to these circumstances (e.g., 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, etc.). 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:

■ 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.

INSTRUCTOR: EFREN B. LAZARTE PAGE NO. 3

IT ELECT 1 – SYSTEM ANALYSIS AND DESIGN MODULE NO. 3
As this 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 analyst
must be prepared to dig into the situation and dis¬cover requirements. This is not often an easy
process.

A number of techniques and tools can be used by the analyst to facilitate this process of discovering
requirements. In this chapter, we will describe those tech¬niques and tools so that you can learn how
to use them during the analysis phase. We will also explain the critical role that requirements play in
defining the new system. As mentioned above, the analyst also employs tools during this phase that
are the subject of complete chapters: use cases (Chapter 4), process models (Chapter 5), and data
models (Chapter 6).

The final deliverable of the analysis phase is the system proposal, which com¬piles the detailed
requirements definition statement, use cases, process models, and data model together with a revised
feasibility analysis and work plan. At the con¬clusion of the analysis phase, the system proposal is
presented to the approval com¬mittee, usually in the form of a system walk-through. The goal of the
walk-through is to explain the system in moderate detail so that the users, managers, and key
deci¬sion 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
approved, 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.

The line between the analysis and design phases is very blurry, because the

deliverables created in the analysis phase are really the first step in the design of the new system.
Many of the major design decisions for the new system are found in the analysis deliverables. In fact,
a better name for the analysis phase would really be “analysis and initial design,” but because this
name is rather long and because most organizations simply call this phase “analysis,” we will, too.
Nonetheless, it is important to remember that the deliverables from the analysis phase are really the
first step in the design of the new system.

INSTRUCTOR: EFREN B. LAZARTE PAGE NO. 4

IT ELECT 1 – SYSTEM ANALYSIS AND DESIGN MODULE NO. 3
In many ways, determining requirements is the single most critical aspect of the entire SDLC. Although
many factors contribute to the failure of systems devel¬opment projects, failing to determine the
correct requirements is a primary cause.1 A 2008 study of Fortune 500 company software projects
found just 37% of survey respondents felt the project met users’ needs.2 Therefore, analysts should
devote considerable attention to the work performed in the analysis phase. It is here that the major
elements of the system first begin to emerge. If the requirements are later found to be incorrect or
incomplete, significant rework may be needed, adding sub¬stantial time and cost to the project.

During requirements determination, the to-be system concept is easy to change because little work
has been done yet. As the system moves through the sub¬sequent SDLC phases (design and
implementation), it becomes harder and harder to return to requirements determination and make
major changes because of all of the rework that is involved. This is why the iterative approaches of
many RAD and agile methodologies are so effective—small batches of requirements can be identi¬fied
and implemented in incremental stages, allowing the overall system to change and evolve over time.
Also, methodologies such as the V-model stress that tests for the system should be defined at the
same time that the requirements are being defined. That way, testing is not just a last-minute,
thrown-together process, but instead is based directly on the requirements of the system as they are
being defined.

REQUIREMENTS DETERMINATION

Requirements determination is performed to transform the system request’s high-level statement of

business requirements into a more detailed, 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. We first explain what a requirement is and discuss the process of creating a
requirements definition statement.

What Is a Requirement?

A requirement is simply a statement of what the system must do or what characteris¬tics it needs to
have. During a systems development project, requirements will be cre¬ated that describe what the

INSTRUCTOR: EFREN B. LAZARTE PAGE NO. 5

IT ELECT 1 – SYSTEM ANALYSIS AND DESIGN MODULE NO. 3
business needs (business requirements); what the users need to do (user requirements); what the
software should do ( functional require¬ments); characteristics the system should have (nonfunctional
requirements); and how the system should be built (system requirements). Although this list of
requirement categories may seem intimidating at first, the categories merely reflect the purpose of the
requirements and the stage in the SDLC in which they are defined.

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 rea¬sons for proposing the systems
development project. These statements reflect the business requirements that this system, if built, will
fulfill. These business require¬ments help define the overall goals of the system and help clarify the
contributions it will make to the organization’s success. Examples of business requirements include:
“Increase market share”; “Shorten order processing time”; “Reduce cus¬tomer service costs”; “Lower
inventory spoilage”; “Improve responsiveness to customer service requests”; and “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 busi¬ness 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 cus¬tomer order”;
“Re-order inventory”; “Determine available credit”; and “Look up account balances.” Use cases
(discussed in Chapter 4) are tools used to clarify the steps involved in performing these user tasks. By
understanding what the user needs to do in terms of tasks to perform, the analyst can then determine
ways in which the new system can support the users’ needs.

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.”3
Functional requirements begin to define how the system will support the user in com¬pleting a task.

INSTRUCTOR: EFREN B. LAZARTE PAGE NO. 6

IT ELECT 1 – SYSTEM ANALYSIS AND DESIGN MODULE NO. 3
For example, assume the user requirement is “Schedule a client appointment.” The functional
requirements associated with that task include: “Deter-mine 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.

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 infor¬mation that will be needed.
For example, as shown in Figure 3-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

Functional
Requirement Description Exam ples

Process-oriented A process the system must perform; ■ The system must allow registered customers to review their own
a process the system must do order history for the past three years.
■ The system must check incoming customer orders for inventory
availability.
■ The system should allow students to view a course schedule while
registering for classes.
maintain real-time inventory
Information-oriented levels
Information at must
the system all warehouses.”
contain ■ TheAll of must
system theseretainrequirements arefornecessary
customer order history three years. to fully
understand the system that is being developed. ■ The system must include real-time inventory levels at all warehouses.
■ The system must include budgeted and actual sales and expense
amounts for current year and three previous years.
Process models (Chapter 5) are used to explain the relationship of functions/ processes to the system
users, how3-1the functions/processes relate to each other, how data is entered and produced by
FIGURE
Functional Requirements and how functions/processes create and use stored data. Process models help
functions/processes,

INSTRUCTOR: EFREN B. LAZARTE PAGE NO. 7

IT ELECT 1 – SYSTEM ANALYSIS AND DESIGN MODULE NO. 3
clarify the software components that will be needed to accomplish the functional requirements. In
addition, the functional requirements begin to define the data that must be kept track of in order to
accomplish the user tasks. The data component of the system is defined in the data model (Chapter
6).

YOUR 3-1 IDENTIFYING REQUIREMENTS

T U R N

One of the most common mistakes 7. have 2-second maximum response time for prede-made
by new analysts is to confuse functional and non- fined queries and 10-minute maximum response time
functional requirements. Pretend that you received the fol- for ad hoc queries.
lowing list of requirements for a sales system: 8. include information from all company subsidiaries.
Requirements for Proposed System: 9. print subsidiary reports in the primary language of
The system should… the subsidiary.
10. provide monthly rankings of salesperson performance.
1. be accessible to Web users.
2. include the company standard logo and color scheme. QUESTIONS:
3. restrict access to profitability information. 1. Which requirements are functional business require-
4. include actual and budgeted cost information. ments? Provide two additional examples.
5. provide management reports. 2. Which requirements are nonfunctional business
6. include sales information that is updated at least requirements? What kind of nonfunctional require-
daily. ments are they? Provide two additional examples.

References :
1) System Analysis and Design, Fifth Edition by Alan Dennis, Barbara Haley Wixom and Roberta M. Roth
2) Systems Analysis and Design: An Object-Oriented Approach with UML
by Alan Dennis & Barbara Haley Wixom & David Tegarden
3) Systems Analysis and Design in a Changing World by John W. Satzinger & Robert B. Jackson
& Stephen D. Burd

Sugested Readings :
1) https://www.projectmanager.com/blog/project-selection-for-better-strategic-results
2) https://www.geeksforgeeks.org/software-engineering-functional-point-fp-analysis/

INSTRUCTOR: EFREN B. LAZARTE PAGE NO. 8

IT ELECT 1 – SYSTEM ANALYSIS AND DESIGN MODULE NO. 3
 3) https://www.investopedia.com/terms/g/gantt-chart.asp
4) https://www.villanovau.com/resources/project-management/controlling-process-project-management/

SCHOOL OF INFORMATION AND COMMUNICATION TECHNOLOGY

Last Name : ______________________________________ First Name :_________________ M.I.: _________

Course, Year & Section : _______________________

INSTRUCTOR: EFREN B. LAZARTE PAGE NO. 9

IT ELECT 1 – SYSTEM ANALYSIS AND DESIGN MODULE NO. 3
 Module 3

I. Answer the following questions.

1. Which requirements are functional business requirements? Provide two additional examples.

________________________________________________________________________________
________________________________________________________________________________
________________________________________________________________________________
________________________________________________________________________________
________________________________________________________________________________
________________________________________________________________________________
________________________________________________________________________________
________________________________________________________________________________
________________________________________________________________________________
________________________________________________________________________________
________________________________________________________________________________
________________________________________________________________________________
________________________________________________________________________________
________________________________________________________________________________
________________________________________________________________________________
________________________________________________________________________________
________________________________________________________________________________
________________________________________________________________________________
________________________________________________________________________________
________________________________________________________________________________
________________________________________________________________________________
________________________________________________________________________________
________________________________________________________________________________
________________________________________________________________________________

INSTRUCTOR: EFREN B. LAZARTE PAGE NO. 10

IT ELECT 1 – SYSTEM ANALYSIS AND DESIGN MODULE NO. 3
 ________________________________________________________________________________
________________________________________________________________________________
________________________________________________________________________________
________________________________________________________________________________
________________________________________________________________________________
________________________________________________________________________________

2. Which requirements are nonfunctional business requirements? What kind of nonfunctional

requirements are they? Provide two additional examples.

___________________________________________________________________________________
___________________________________________________________________________________
___________________________________________________________________________________
___________________________________________________________________________________
___________________________________________________________________________________
___________________________________________________________________________________
___________________________________________________________________________________
___________________________________________________________________________________
________________________________________________________
________________________________________________________________________________
___________________________________________________________________________________
___________________________________________________________________________________
___________________________________________________________________________________
___________________________________________________________________________________
___________________________________________________________________________________
___________________________________________________________________________________
___________________________________________________________________________________
___________________________________________________________________________________
___________________________________________________________________________________
___________________________________________________________________________________
___________________________________________________________________________________

INSTRUCTOR: EFREN B. LAZARTE PAGE NO. 11

IT ELECT 1 – SYSTEM ANALYSIS AND DESIGN MODULE NO. 3
___________________________________________________________________________________
___________________________________________________________________________________
___________________________________________________________________________________
___________________________________________________________________________________
___________________________________________________________________________________

INSTRUCTOR: EFREN B. LAZARTE PAGE NO. 12

IT ELECT 1 – SYSTEM ANALYSIS AND DESIGN MODULE NO. 3