SYSTEM ANALYSIS AND DESIGN

http://www.saigontech.edu.vn/faculty/huynq/SAD/Systems_Analysis_Design_UML_5th%20ed.pdf

https://drive.google.com/open?id=1Pw1WUkyO3J57kS8b61K8Zyxb2M9AROK9

FIGURE 1-3 Systems Development Life Cycle Phases

Planning 

Focus: 

Why build this system? 

How to structure the project? 

The planning phase is the fundamental process of understanding why an information system should be built and determining how the project team will go about building it. 

The technical feasibility (Can we build it?)

The economic feasibility (Will it provide business value?)

The organizational feasibility (If we build it, will it be used?)

A system request presents a brief summary of a business need, and it explains how a system that supports the need will create business value. 

Analysis

The analysis phase answers the questions of who will use the system, what the system will do, and where and when it will be used.

study of the current system

requirements gathering

The analyses, system concept, and models are combined into a document called the system proposal, which is presented to the project sponsor and other key decision makers (e.g., members of the approval committee) who will decide whether the project should continue to move forward.

Design

The design phase decides how the system will operate in terms of the hardware, software, and network infrastructure that will be in place; the user interface, forms, and reports that will be used; and the specific programs, databases, and files that will be needed. Although most of the strategic decisions about the system are made in the development of the system concept during the analysis phase, the steps in the design phase determine exactly how the system will operate. 

The design strategy must be determined. 

This leads to the development of the basic architecture design for the system that describes the hardware, software, and network infrastructure that will be used. 

The database and file specifications are developed.

The analyst team develops the program design, which defines the programs that need to be written and exactly what each program will do.

This collection of deliverables (architecture design, interface design, database and file specifications, and program design) is the system specification that is used by the programming team for implementation. At the end of the design phase, the feasibility analysis and project plan are reexamined and revised, and another decision is made by the project sponsor and approval committee about whether to terminate the project or continue.

Implementation

The final phase in the SDLC is the implementation phase, during which the system is actually built (or purchased, in the case of a packaged software design and

installed). This is the phase that usually gets the most attention, because for most systems it is the longest and most expensive single part of the development process. 

System construction is the first step. The system is built and tested to ensure that it performs as designed. 

The system is installed. Installation is the process by which the old system is turned off and the new one is turned on.

The analyst team establishes a support plan for the system. 

System Request

A system request is a document that describes the business reasons for building a system and the value that the system is expected to provide. The project sponsor usually completes this form as part of a formal system project selection process within the organization. Most system requests include five elements: project sponsor, business need, business requirements, business value, and special issues. 

Technical Feasibility

The first technique in the feasibility analysis is to assess the technical feasibility of

the project, the extent to which the system can be successfully designed, developed,

and installed by the IT group. Technical feasibility analysis is, in essence, a technical

risk analysis that strives to answer the question: “Can we build it?”7

Economic Feasibility

The second element of a feasibility analysis is to perform an economic feasibility

analysis (also called a cost–benefit analysis). This attempts to answer the question

“Should we build the system?” 

Cash Flow Analysis and Measures

Return on Investment

Break-Even Point

Net Present Value (NPV)

Organizational Feasibility

The final technique used for feasibility analysis is to assess the organizational feasibility of the system: how well the system ultimately will be accepted by its

users and incorporated into the ongoing operations of the organization. There are many organizational factors that can have an impact on the project, and seasoned developers know that organizational feasibility can be the most difficult feasibility dimension to assess. In essence, an organizational feasibility analysis attempts to answer the question “If we build it, will they come?”

Project Executive Summary

FIGURE 1-15 Feasibility Analysis Executive Summary for Tune Source

PROJECT SELECTION

Size What is the size? How many people are needed to work on the project?

Cost How much will the project cost the organization?

Purpose What is the purpose of the project? Is it meant to improve the technical infrastructure? support a current business strategy? improve operations? demonstrate a new innovation?

Length How long will the project take before completion? How much time will go by before value is delivered to the business?

Risk How likely is it that the project will succeed or fail? Scope How much of the organization is affected by the system? a department? a division? the entire corporation?

Economic Value How much money does the organization expect to receive in FIGURE 2-1 return for the amount the project costs? 

Throwaway prototyping6 includes the development of prototypes, but uses the

prototypes primarily to explore design alternatives rather than as the actual new system

(as in system prototyping). As shown in Figure 2-7, throwaway prototyping has a

fairly thorough analysis phase that is used to gather requirements and to develop

ideas for the system concept. Many of the features suggested by the users may not

be well understood, however, and there may be challenging technical issues to be

solved. Each of these issues is examined by analyzing, designing, and building a

design prototype. A design prototype is not intended to be a working system. It contains only enough detail to enable users to understand the issues under consideration.

For example, suppose that users are not completely clear on how an order

entry system should work. The analyst team might build a series of HTML pages

to be viewed on a Web browser to help the users visualize such a system. In this

case, a series of mock-up screens appear to be a system, but they really do nothing.

Or, suppose that the project team needs to develop a sophisticated graphics program

in Java. The team could write a portion of the program with artificial data to ensure

that they could create a full-blown program successfully.

A system that is developed by this type of methodology probably requires several design prototypes during the analysis and design phases. Each of the prototypes

is used to minimize the risk associated with the system by confirming that important

issues are understood before the real system is built. Once the issues are resolved,

the project moves into design and implementation. At this point, the design prototypes are thrown away, which is an important difference between this approach and

system prototyping, in which the prototypes evolve into the final system.

Throwaway prototyping balances the benefits of well-thought-out analysis

and design phases with the advantages of using prototypes to refine key issues before

a system is built. It may take longer to deliver the final system compared with

system prototyping (because the prototypes do not become the final system), but

the approach usually produces more stable and reliable systems.

FIGURE 2-9 Criteria for Selecting a Methodology

REQUIREMENTS DETERMINATION

During the analysis phase, the analyst determines the functional requirements for the new system. This chapter begins by describing the analysis phase and its primary deliverable, the system proposal. The concept of a requirement is explained and several categories of requirements are defined. The purpose and structure of the requirements definition statement is outlined.

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

REQUIREMENTS DETERMINATION

Requirements determination is performed to transform the system request’s highlevel 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 characteristics it needs to have. During a systems development project, requirements will be created that describe what the business needs (business requirements); what the users need to do (user requirements); what the software should do ( functional requirements); characteristics the system should have (nonfunctional requirements); and how the system should be built (system requirements). 

Document Analysis

Project teams often use document analysis to understand the as-is system. Under

ideal circumstances, the project team that developed the existing system will have

produced documentation, which was then updated by all subsequent projects. In

this case, the project team can start by reviewing the documentation and examining

the system itself.

Unfortunately, most systems are not well documented, because project teams

fail to document their projects along the way, and when the projects are over, there is

no time to go back and document. Therefore, there may not be much technical documentation about the current system available, or it may not contain updated information about recent system changes. However, there are many helpful documents that do

exist in the organization: paper reports, memorandums, policy manuals, user training

manuals, organization charts, and forms. Problem reports filed by the system users

can be another rich source of information about issues with the existing system.

But these documents (forms, reports, policy manuals, organization charts)

only tell part of the story. They represent the formal system that the organization

uses. Quite often, the “real,” or informal system differs from the formal one, and

these differences, particularly large ones, give strong indications of what needs to

be changed. 

REQUIREMENTS ANALYSIS STRATEGIES

Problem Analysis

The most straightforward (and probably the most commonly used) requirements analysis strategy is problem analysis. Problem analysis means asking the users and managers to identify problems with the as-is system and to describe how to solve them in

the to-be system. 

Root Cause Analysis

The ideas produced by problem analysis tend to be solutions to problems. All solutions make assumptions about the nature of the problem, assumptions that may or may not be valid. In our experience, users (and most people in general) tend to jump quickly to solutions without fully considering the nature of the problem. Sometimes the solutions are appropriate, but many times they address a symptom of the problem, not the true problem or root cause itself.

Root cause analysis focuses on problems first rather than solutions.

Duration Analysis

Duration analysis requires a detailed examination of the amount of time it takes to

perform each process in the current as-is system. 

Activity-Based Costing

Activity-based costing is a similar analysis that examines the cost of each major

process or step in a business process rather than the time taken.1

Informal Benchmarking

Benchmarking refers to studying how other organizations perform a business

process in order to learn how your organization can do something better. Benchmarking helps the organization by introducing ideas that employees may never have

considered, but that have the potential to add value.

Informal benchmarking is fairly common for “customer-facing” business

processes (i.e., those processes that interact with the customer). 

Outcome Analysis

Outcome analysis focuses on understanding the fundamental outcomes that provide

value to customers. 

Technology Analysis

Many major changes in business over the past decade have been enabled by new

technologies. Technology analysis therefore starts by having the analysts and managers develop a list of important and interesting technologies. Then the group systematically identifies how each and every technology could be applied to the business process and identifies how the business would benefit.

Activity Elimination

Activity elimination is exactly what it sounds like. The analysts and managers work together to identify how the organization could eliminate each and every activity in the business process, how the function could operate without it, and what effects are likely to occur. Initially, managers are reluctant to conclude that processes can be eliminated, but this is a “force-fit” exercise in that they must eliminate each activity. In some cases the results are silly; nonetheless, participants must address each and every activity in the business process.

Outline of the Tune Source System Proposal

USE CASE ANALYSIS

A use case represents how a system interacts with its environment by illustrating the activities that are performed by the users of the system and the system’s

responses. The goal is to create a set of use cases that describe all the tasks that users need to perform with the system. Use cases are often thought of as an external or functional view of a business process, showing how the users view the process rather than the internal mechanisms by which the process operates. Since use cases describe the system’s activities from the user’s perspective in words, user involvement is essential in their development. Therefore, creating use cases helps ensure that users’ insights are explicitly incorporated into the new system.

Elements of a Use Case

FIGURE 4-1

Request a Chemical Use Case

Basic Information 

Each use case has a name and number. The name should be as simple, yet descriptive, as possible. 

Use Case Name:

ID:

Priority:

Actor:

Description:

Trigger:

Type:

Preconditions:

Normal Course:

Information for Steps:

Alternative Courses:

Postconditions:

Exceptions:

Summary

Inputs

Source

Outputs

Destination

Use Cases and the Functional Requirements

As we stated earlier in the chapter, use cases are very helpful tools to use to understand user requirements. 

Building Use Cases

Use cases can be used for both the as-is and the to-be systems; as-is use cases focus

on the current system, whereas to-be use cases focus on the desired new system. 

ARCHITECTURE DESIGN

ELEMENTS OF AN ARCHITECTURE DESIGN

The objective of architecture design is to determine how the software components of the information system will be assigned to the hardware devices of the system. In this section, we first discuss the major functions of the software to understand how the software can be divided into different parts. Then we briefly discuss the major types of hardware onto which the software can be placed. Although there are numerous ways in which the software components can be placed on the hardware components, the most common architecture is the client–server architecture, so we focus on it here.

Architectural Components

The major architectural components of any system are the software and the hardware. 

Operational Requirements

Operational requirements specify the operating environment(s) in which the system must perform and how those may change over time. 

Technical Environment Requirements 

Technical environment requirements specify the type of hardware and software on which the system will work.

System Integration Requirements 

System integration requirements are those that require the system to operate with other information systems, either inside or outside the company. 

Portability Requirements 

Information systems never remain constant. Business needs and operating technologies change, so the information systems that support them and run on them must change, too. Portability requirements define how the technical operating environments may evolve over time and how the system must respond

Maintainability Requirements 

Maintainability requirements specify the business requirement changes that can be anticipated. Not all changes are predictable, but some are. 

Performance Requirements 

Performance requirements focus on performance issues such as response time, capacity, and reliability. 

Speed Requirements 

Speed requirements are exactly what they say: how fast the system must operate. First and foremost, this is the response time of the system: How long does it take the system to respond to a user request? 

Capacity Requirements 

Capacity requirements attempt to predict how many users the system will have to support, both in total and simultaneously. 

Availability and Reliability Requirements 

Availability and reliability requirements focus on the extent to which users can assume that the system will be available for them to use.

Security Requirements

Security is the ability to protect the information system from disruption and data loss, whether caused by an intentional act (e.g., a hacker or a terrorist attack) or a random event (e.g., disk failure, tornado).

System Value 

The most important computer asset in any organization is not the equipment; it is the organization’s data. 

Cultural and Political Requirements

Cultural and political requirements are specific to the countries in which the system will be used. 

HARDWARE AND SOFTWARE SPECIFICATION

The design phase is also the time to begin selecting and acquiring the hardware and software that will be needed for the future system.