1 5 C H A P T E R SYSTEMS ANALYSIS Overview of Remaining Chapters in Systems Analysis Chapters 6-10.

1

5C H A P T E R

SYSTEMS ANALYSIS

Overview of Remaining Chapters in Systems Analysis Chapters 6-10

2

Chapter Five Systems Analysis Define systems analysis and relate the term to the Preliminary Analysis (preliminary

investigation, problem analysis), requirements analysis, and decision analysis phases of the systems development methodology.

Describe a number of systems analysis approaches for solving business system problems.

Describe the Preliminary Analysis, Requirements Analysis, and decision analysis phases in terms of your information system building blocks.

Describe the Systems Analysis phases in terms of purpose, participants, inputs, outputs, techniques, and steps.

NOTE: This chapter teaches only the processprocess of systems analysis. The tools and techniques will be taught in the subsequent five chapters.

3

Chapter MapNote: PrimaryStakeholdersare Owners &Users – for PrelimAnalysis andRequirementsAnalysis – workwith Systems andBusiness Analysts

4

Systems Analysis vs. Systems DesignSystems Analysis is a problem-solving technique that decomposes a system into its component pieces for the purpose of studying how well those component parts work and interact to accomplish their purpose.

Systems Design (also called systems synthesis) is a complementary problem-solving technique (to systems analysis) that reassembles a system’s component pieces back into a complete system—hopefully, an improved system. This may involves adding, deleting, and changing pieces relative to the original system.

The Hows and the Whats

Problem-based; Solution-based.

5

Systems Analysis and Design Systems Analysis - early phases of software

development. All about Problem Solving!!!

Systems Analysis is defined as those development phases in a project that primarily focus on the businessbusiness problem, independent of any technology to implement a solution to that problem.

No industry-wide total acceptance of a definition of systems analysis or design either.

Systems Analysts serve as facilitators of systems analysis.

6

Context of Systems AnalysisNote the elements constituting traditional “Systems Analysis.”

Preliminary Analysis

First deliverable

Second thru fourthdeliverable

Fifth Deliverable= a system proposal

7

RepositoryA Repository is a location (or set of

locations) where systems analysts, systems designers, and system builders keep all of the documentation associated with one or more systems or projects.

Will contain all your materials – even worksheets used for decision making….

8

Model-Driven Analysis MethodsCommon approaches to solving problem include structured analysis, information engineering, object-oriented analysis, and rapid-application development (prototyping). The first three of these are Model-Driven Approaches to Analysis.

Model-driven analysis emphasizes the drawing of pictorial system models to document and validate both existing and/or proposed systems. Ultimately, the system model becomes the blueprint for designing and constructing an improved system.

A model is a (graphical) representation of either reality or vision. Just as “a picture is worth a thousand words,” most models use pictures to represent the reality or vision.

Nowadays almost always accommodated by automated tools.

9

Model-Driven Methods – Example 1Structured Analysis is a model-driven, process-centered technique used to either analyze an existing system, define business requirements for a new system, or both. The models are pictures that illustrate the system’s component pieces: processes and their associated inputs, outputs, and files.

. still one of the most widely used approaches today!!!

. Emphasis is on the Process Building Blocks – always been the primary focus.. Building blocks are processes and these are modeled

by Data Flow Diagrams (DFDs) . Show Processes and their inputs, outputs and files.

. Processes are ultimately implemented as programs.

10

More on Structured Analysis…Because of renewed emphasis on business process redesign, DFDs

are studying their fundamental processes to improve throughput, performance, and customer service while reducing waste and other inefficiencies.

DFDs are used to model business processes and data flow.

Information engineering is more complex and comprehensive than the oversimplified presentation in this edition’s chapter.

Few organizations that still practice pure IE. Many organizations still practice data-driven analysis and design.

11

A Simple Process Model

Data FlowDiagram

External Entity

A process

a data store

Annotated flowlines

Exist in varyingdegrees of detail (moreahead).Called Leveling

DFDs Chapter 6.

12

Model-Driven Approaches – Ex. 2 Information engineering (IE) is a model-driven and data-centered, but

process-sensitive technique to plan, analyze, and design information systems. IE models are pictures that illustrate and synchronize the system’s data and processes.

Here, data models are called Entity-Relationship diagrams IE still uses DFDs from structured analysis, but integrates and synchronizes

ERDs into the process so we have data and process models. IE is data centered because it emphasizes studying and modeling of data

PRIOR to that of Process and Interface. Data considerations (capture, storage, use, maintenance) actually drive the

process design. <That Structured Analysis also uses ERDs is not surprising. But this

approach uses ERDs AFTER process is captured.>

13

A Simple Data Model

Entity-RelationshipDiagram

Data Relationships: cardinality; modality; 1-1, 1-many, many to many, etc…strong entities; weak entities, … more…

ERDs in Chapter 7

14

Model-Driven Analysis – Ex. 3Object-Oriented Analysis (OOA) is a model-driven technique that integrates data and

process concerns into constructs called objects.

OOA models are pictures that illustrate the system’s objects from various perspectives such as structure and behavior.

OOA synthesizes data and process into objects as building blocks.

Uses new concepts such as encapsulation, information hiding, inheritance, polymorphism, and more to describe the features of working with objects…

Modeling technique uses models as building blocks and message-passing among objects which provide a service to each other.

UML (Unified Modeling Language) is a standard for using objects and all that deals with them.

15

A Simple Object Model

+Admit()+Regsiter for Classes()+Withdraw()+Change Address()+Calculate GPA()+Graduate()

-ID Number-Name-Grade Point Average

STUDENT

+Create a Course()+Delete from Course Master()+Change in Course Master()

-Subject-Number-Title-Credit

COURSE

+Add()+Drop()+Complete()+Change Grade()

-Semester-Division-Grade

TRANSCRIPT COURSE

11

has record for>0..*

0..*

Object DiagramClass (really, not an object)attributes; methods; visibilitycharacteristics (private, …)

See Module A

16

Accelerated Analysis Methods vis a vis Model-Driven…Accelerated Analysis approaches emphasize the construction of prototypes to more rapidly identify business and user requirements for a new system.

A prototype is a small-scale, incomplete, but working sample of a desired system. Prototypes cater to the “I’ll know what I want when I see it” thinking characteristic of many users and managers.

Can evolve into operational systems – sometimes;Dangers lurk here, though.

17

Accelerated Analysis Modeling Discovery Prototyping…two types

1. Discovery Prototyping – is requirements prototyping identify users’ business requirements by having

them react to quick and dirty implementations of those requirements.e.g. Might use Microsoft Access, VB, or other prototyping technology.Danger: elegant prototypes; premature focus and commitment to design.Often very inefficient for larger databases, numbers of users, network traffic, etc.Is the preferred and recommended approach. But be aware of real dangers.

18

Accelerated Analysis Modeling – Rapid Application Development (RAD)

2. Rapid Application Analysis Here, we derive system models often from existing system or prototypes

Lots of Reverse Engineering from existing models… “Reverse Engineering technology reads the program

code for an existing database, application program, and/or user interface and automatically generates the equivalent system model”

Discovery engineering using prototypes can be reversed engineered into system models. These models can then be forward engineered using same CASE tools into robust databases that might serve enterprise-level needs.

Normally software development nowadays is a blend of accelerated analysis and then model-driven approaches.

19

Requirements Discovery MethodsRequirements Discovery includes those

techniques to be used by systems analysts to identify or extract system problems and solution requirements from the user community.

Fact-finding (or information gathering) is a classical set of techniques used to collect information about system problems, opportunities, solution requirements, and priorities.

Sampling - Reading quarterly reports Research - Studying a corporation’s web page Observation - Questionnaires and surveys Interviews

20

Joint Application Development We are separating joint application development (JAD)

into its component parts, joint requirements planning (JRP) and joint application design (also JAD). Only JRP is applicable to this chapter.

Joint requirements planning (JRP) techniques use facilitated workshops to bring together all of the system owners, system users, systems analysts, and some systems designer and builders to jointly perform systems analysis.

21

Business Process Redesign MethodsBusiness Process Redesign (or business process reengineering) is the application of systems analysis methods to the goal of dramatically changing and improving the fundamental business processes of an organization, independent of information technology.

Reality: most systems nowadays are horribly inefficient and wasteful.

This industry-wide effort is triggered by Total Quality Management (TQM) and Continuous Process Improvement (CPI)

22

Business Process RedesignSome BPR focus on all business processes. After

redesigning the business processes, most BPR projects then conclude by examining how information technology might best be applied to the improved business processes. This may create new information systems and application development projects to implement or support the new business processes.

Sometimes BPR is needed to accompany purchase and integration of COTS. Generally, the business will have to adapt its processes to fit the software. So, an analysis of existing business processes during systems analysis is usual part of such projects.

23

Systems Analysis Phases Preliminary Analysis (my term)

Preliminary Investigation Phase Really a survey phases; learning…

Interviewing, questionnaires, face-to-face Gap analyses, research…

Problem Analysis Phase Really a ‘study phase’

(Enter: First Deliverable) (Enter: First Deliverable) Requirements Analysis Phase

Really, a definition / modeling phase Data Analysis and Modeling – Phase II Process Modeling – Phase III Interface Modeling - Phase IV

25

Preliminary Analysis Preliminary Analysis (my preference) (lots of other

terms… initial feasibility, initial study phase, problem statements and analysis, others; gathering of information; needs…

My definition of Preliminary Analysis includes all the items due for your first deliverable:

1. Project Description

Domain Modeling; Glossary

2. Use Case Collection

Brief Description of Actions/Use Cases

3. Project Scope - preliminary

4. Project Plan - preliminary

26

Preliminary Investigation activity in Preliminary Analysis

Deliverable from Preliminary Investigation is the Project Charter : the four components of the Preliminary Analyses your team undertook.

First, we need a formal (written) Request for Services!!! key user(s) (maybe), owners, key analyst(s) (those who

REALLY know the business) I have provided this… Can arise in many many ways.

Secondly, we need to identify the functionality that the application will solve (problem solving again…) this may consist of documented problems from existing systems (or new problems that have arisen functionally in the discipline), opportunities, directives, perceived constraints that precipitated the Request for Software Services. So, create your (Problem Statements) Use Cases.

27

Sample Request for System ServicesNot all projects start of with a written document.

Some are QUITE formal.

This is sufficient for your initial description.

28

Problem Statements

This can be / will be tailored to the individual project ALWAYS!Alternatively, could be provided in a report. Helps to get a handle on SCOPE!!!

29

Documenting Requirements with Use CasesA use case is a behaviorally related sequence of stepssequence of steps (a scenario), both automated and manual for the purpose of completing a single completing a single business taskbusiness task.

An actor represents anything that needs to interact with the system to exchange information. An actor is a user, a role, which could be an external system as well as a person.

Use Cases describe system functions

from the perspective of external users and

in the manner and terminology in which they understand.

result of decomposing the scope of system functionality into many smaller statements of system functionality.

30

Benefits of Using Use Cases Facilitates user involvementuser involvement. A view of the desired system’s functionalityfunctionality

from an external person’s viewpoint. An effective tool for validating requirementsvalidating requirements. An effective communication tool. Supports MANYMANY follow on activities needed

in systems analysis and design

31

Example of a High-Level Use Case

Author: S. Shepard Date: 03/01/2002

Use Case Name: New Member Order

Actors: MemberDescription: This use case describes the process of a

member submitting an order for Sound Stageproducts. On completion, the member will besent a notification that the order was accepted.

32

Author: S. Shepard Date: 10/05/2002

Use Case Name: Submit New Member OrderActor(s): MemberDescription: This use case describes the process of a member submitting an order for Sound Stage products. On completion, the member will be sent a notification thatthe order was accepted.References: MSS-1.0Typical Courseof Events:

Example of a Requirements Use Case

Actor Action

Step 1: This use case isinitiated when a member submits an order to beprocessed

Step 7: This use case concludes when the member receives the order confirmation notice.

System responseStep 2: The member’s personal information such as address is validated against what is currently recorded in member services.

Step 3: The member’s credit status is checked with Accounts Receivable to make sure no payments are outstanding.

Step 4: For each product being ordered, validate the product number and then check the availability in inventory and record the ordered product information.

Step 5: Create a picking ticket for the member order containing all ordered products that are available and route it to the warehouse for processing.Step 6: Generate an order confirmation notice indicating the status of the order and send it to the member.

1

2

33

Alternate Step 2: If the club member has indicated an address or telephone number change on theCourses: promotion order, update the club member’s record with the new information.

Step 3: If Accounts Receivable returns a credit status that the customer is in arrears, send anorder rejection notice to the member.

Step 4: If the product number is not valid, send a notification to the member requesting them tosubmit a valid product number. If the product being ordered is not available, record theordered product information and mark as “back-ordered.”

Pre-condition: Orders can only be submitted by members.

Post-condition:Member order has been recorded and the picking ticket has been routed to the warehouse.

Assumptions: None at this time.

Example of a Requirements Use Case (concluded)

3

4

5

6

1. A reference to a requirement use case can be traced to2. Basic course of events. Interaction with an actor3. Alternate course descriptions for exceptions and alternate actions4. Preconditions describing the state of the system before use case is activated.5. Post condition describing state of the system after use case is executed.6. Assumptions, which includes any non-behavioral issues, such as performance, Security,… that is associated with the use case but is difficult to model within the Use cases course of events.

34

More… Domain Model / Glossary. Use Cases should be accompanied by

(sometimes prior to their creation; sometimes accompanying them…) a domain model (Can be class diagram if going into OOSE) - perhaps a complete Use Case context diagram – with actors…the business model restricted to the application domain.

Glossary – essential. Common definitions all agree upon.

Actor Description. Every identified actor should have a brief description of the actor and his/her/its connection to the system. Actors trigger the system; The system provides the use cases.

Supplementary Specifications. Statements of non-functional needs (generally declarative). Constraints (operating environment, language), regulatory issues, standards of development; paradigms, performance, usability, persistence, distribution, security….provide the remainder (most (not all) of the non-functional requirements individually not appropriate to put into a single Use Case (often global requirements…)

35

Preliminary Investigation activity in Preliminary Analysis

Thirdly, Create a Preliminary Project Scope Sometimes called Statement of WorkStatement of Work, and other name This (guaranteed!) will change later. Essential that we have a baseline starting position.

Defined in terms of: (Most significant parts follow Data that describe the system

(like, Products, Orders, Customers – entities….) Business Processes

(like business processes for management, customer relations, order management, order entry, etc.)

Interfaces with Users, Locations, other Systems like (customers, sales reps, sales clerks, managers,

regional offices, etc.)

36

Preliminary Investigation activity in Preliminary Analysis Project Scope (continued) Items from project scope can also be inferred

from the domain model, from the glossary (part of Deliverable #1), Use Cases, and the supplementary specifications.

Entire idea behind scope is to BOUND the system.

But you need this common understanding of what the application is to provide and to whom. (Thus the domain model and glossary)

37

Preliminary Investigation activity in Preliminary Analysis

Fourth: Create a Project Plan Baseline Plan – update at end of each phase..

Contains schedule, resource assignments, for entire project.

Plan for Next Phase – the Requirements Analysis Phase

Done by project manager (for us, team leader in total coordination with team members. Team leader (here) is not in charge; rather, a ‘facilitator.’)

OPTIONAL – Create a project websiteContains project charter and links to project

documentation

38

End of Preliminary Investigation of Preliminary Analysis – Kickoff the System

Deliverable from Preliminary Analysis are the deliverables listed earlier

These contain:Project Request / Description Transmittal letterProblems Statements / Use Cases - (opportunities,

directives, constraints, domain model/glossary, supplementary specification (contains standards and environment; platforms, etc.), …

Project Scope – project boundariesProject Plan – for tracking and management

Project may create a project website

39

Problem Analysis Phase Context

Focus is on both system owner and system user perspectives.

Looking at the building blocks of the existing system.

40

Problem Analysis Phase Goal: Study and understand the problem domain well

enough to thoroughly analyze its problems, opportunities, and constraints. Sometimes detailed knowledge of current system is

needed and modeled (physical DFDs) (Chapter 8) Main idea: need to be able to refine our understanding of

project scope and problem statement to define a common vocabulary for the system.

Generally create a Domain Model / Glossary / or Both

Final Deliverable – Produce System Improvement Objectives that address problems, opportunities, and directives or alternatively a collection of revised Use Cases.

Update Project Plan (in repository) if necessary. Create Domain Model (Physical DFD; Perhaps a set of Use

Cases and Actors )

41

Problem Analysis Phase

Team Activities (as opposed to owners, ….) Really must study the problem domain in more detail Learn about current system Owners, users, analysts bring different levels of understanding to

the system – different detail, vocabulary, perceptions, opinions. This is the domain within which all these improvements,

opportunities, etc. exist! Very important that Users be available to the project as full-time

business analystsbusiness analysts; SMEs… Seek out the experts; get their opinions! Oftentimes, current documentation does not exist.

42

Problem Analysis – Current Systems: If there is a current system:

list all reports, transactions, purposes of each; frequency, descriptions business events for which a business response is currently implemented, locations of current system users (e.g. regional offices; office managers) Can be quickly done.

Don’t shortchange the business vocabulary – great way for communications between developers and users.

Might want short data model (single page); one or two-page functional model w/decomposition; a one-page context model or updated use-case diagrams that show the system’s inputs and outputs locally or with other organizations (interface)

Stay away from “We need to…” “We want to..” which are solution-based statements. Concentrate on understanding the problems – their causes and effects in the existing system.

Update Project Plan as necessary following Problem Analysis

44

Cause-and-Effect AnalysisCause-and-effect analysis is a technique in which problems are studied to determine their causes and effects. In practice, effects can be symptomatic of more deeply rooted or basic problems which, in turn, must be analyzed for causes and effects until such a time as the causes and effects do not yield symptoms of other problems. Discuss! What causes a system to be enhanced / redesigned / replaced?

45

System Improvement ObjectivesAn objective is a measure of success. It is something that you expect to achieve, if given sufficient resources.

Reduce the number of uncollectible customer accounts by 50 percent within the next year.

Increase by 25 percent the number of loan applications that can be processed during an eight-hour shift.

Decrease by 50 percent the time required to reschedule a production lot when a workstation malfunctions.

A constraint is something that will limit your flexibility in defining a solution to your objectives. Essentially, constraints cannot be changed.

46

Cause-and-Effect / System Improvement Objectives

PROBLEMS, OPPORTUNITIES, OBJECTIVES, AND CONSTRAINTS MATRIX

47

Requirements Analysis Phase Context

Requirements can be expressed in narrative, and prototype forms, or any combination thereof.

48

Requirements Analysis Sometimes called the Definition Phase or Logical Design

Phase We must define the business requirements for the

solution! – No considerations of technology Sometimes, development teams are created at this time and

NOW the work starts…. Some development models start with Requirements Analysis

Previous work has been done; maybe backlogged. Sometimes Problem Analysis included here (if current

system is a consideration – usually the case) So, we discover the WHATs of the required system.

Functional Requirements may be captured in Use Cases Non-functional and other requirements captured in Supplementary

Specification Document. Assuming project is approved, this is usually

considered the most critical part of a project!

49

Recall our previous drawing: Preliminary Analysis (my term)

Preliminary Investigation Phase Problem Analysis Phase – current system; causes/effects; opportunities; constraints;

system improvements… (Enter: First Deliverable)(Enter: First Deliverable)

Requirements Analysis Phase ===== Data Analysis and Modeling – Deliverable #2 Process Modeling – Deliverable #3 Interface Modeling – Deliverable #4

All about REQUIREMENTS … at the process, data, interface levels Remember: these are impacted by preferences, constraints, managerial approaches,

schedule, ….. That is, ‘scope’ items….(statement of work…)

50

Identification of Business RequirementsA functional requirement is a description of activities and services a system must provide. usually defined in terms of inputs / outputs / processes / stored data needed to support this

requirement. May be expressed as a Use Case

A nonfunctional requirement is a description of other features, characteristics, and constraints that define a satisfactory system.

normally deal with performance, usability, budget, costs, deadlines, constraints, security,

etc...

51

Requirements Analysis – Continued… While desirable, rarely will all the functional requirements

and non-functional requirements be identified. Framework for changes. They WILL happen. Not complete, usually ambiguous, not sufficient, perhaps not all

necessary, perhaps not all testable… Use Cases (modern approach) helps a great deal.

Much better than ‘Requirements Lists.’

These are draft requirements… Accommodated/documented by systems analysts Critical need: access to system stakeholders (various) for

business requirements. Discuss ‘willingness’ of some vis a vis others….

Usually CASE tools used to document process, data, interface, stored data to the dictionary, encyclopedia and repository.

52

Requirements Analysis – Continued… The SYSTEMS ANALYSTS MUST identify and analyze functional

(and supplementary) requirements so that they can be communicated both to the users and to the technical people…

Business may need to prioritize requirements for many reasons. Verify that analysts understands needs.

Technical people need to fully understand all requirements in order to design solutions that are traceable to requirements.

We typically capture requirements by: Requirements Lists – old way; difficult to deal with; boring!

Ambiguous, Charts/graphs, tables (DLTs), etc… Models, such as Use Case Model w/domain and

supplementary descriptions and/or combination of models such as ERDs, DFDs, and prototypes.

53

1..Requirements Analysis – Capturing Requirements via Logical System Models

LOGICAL models (Logical Design)– no hint of ‘how’ Logical system models depict what a system is or what a system must do—not how the system will be do it. Because logical models depict the essential requirements of a system, they are sometimes called essential system models.

Recall: Physical DFDs were used to model existing systems – these have implementations already. Used in Problem Analysis Phase

54

1..Requirements Analysis – Capturing Requirements via Logical System Models

Process models (e.g., data flow diagrams – starting point for program design)

Data models (e.g., entity relationship diagrams – starting point for designing a database)

Interface models (e.g., context diagrams – starting point for designing user interfaces – shows system as a box plus external ‘entities’

Object models (e.g., Uniform Modeling Language diagrams) Logical modeling (Logical Design) (data, process,

interface) express business requirements.(LDFD) Physical modeling (Physical Design) addresses

solution (PDFD) Physical system models, introduced in the

systems design chapter – later…

55

2. Requirements Analysis – Capturing Requirements via Prototyping

Building prototypes – particularly valuable when requirements not fully understood (by user and/or developer or both) and in developing the interfaces.

Systems Analysts deal with system end-users a great deal in verifying requirements

via the prototypes Sometimes, creation of the prototypes as well as

databases might be supported by reverse engineering Depends on the approach and tools used…. Then, a model-driven approach can be continued…

56

Requirements Analysis Modeling techniques generally use

DFDs, ERDs, Biggest new trend is to emphasize Use Cases.

Fewer advocates of DFDs; but in common use…especially for domain modeling and information flow depicting current and/or desired system.

CASE Tools such as Visio, System Architect, Visible Analyst, and several others.

some simple CASE ranging to iCASE tools. Prototyping tools often include Microsoft Access or Visual Basic –

even those these are used in courses dealing with application development.

There are a number of tools to support prototyping

57

After requirements accomplished and captured via modeling or prototyping, the requirements capture ABSOLUTLEY NEED TO BE VERIFIED BY THE USER.

How so? Discuss…. Use Cases for verification of proposed functionality?? DFDs and ERDs Prototypes

Requirements Tracing refers to verifying the system models / prototypes against the requirements. May require some rework – VERY worth the effort!!!! Also associate the non-functional requirements with the functional requirements so

that they will be accommodated in system design

58

…leaving Requirements Analysis

General Rule of software development:General Rule of software development:Provide the maximum functionality in the Provide the maximum functionality in the

minimum time on schedule and within minimum time on schedule and within budgetbudget

Oftentimes business requirements may be prioritized. ‘mandatory requirements ‘ for any increment – ‘dead

without it.’ ‘desirable requirements’ (can be ranked) for

subsequent versions.

59

Parting Comments If trouble (and OFTEN if not) Timeboxing

(Versioning) is a mechanism of developing and implementing a key subset (one that provides immediate functionality and utility) in a small development timeframe. Do this successively with different subsets / increments.’

Oftentimes called ‘incremental development’ Naturally, any of these activities require Project

Plan updating. “Sign-Off” - get a signature. Realize ‘changes’

in requirements will come…

61

Requirements StatementSample Software Requirements Specification document.

62

Decision Analysis Phase Context

This phase deals with possiblecandidate solutions,or a comparison ofpossible solutionswith recommendations

Phase ends with aSystem ProposalSystem Proposalfor design…(later…)(5th Deliverable)