System Analysis Overviewapproaches, phases and requirements discovery
Karolina Muszyńska
Based on http://www.csun.edu/~dn58412/IS431/IS431_SP13.html
Systems Analysis vs. Systems Design Systems Analysis Phases and Tasks User Requirements Discovery Systems Analysis Approaches
2
Systems Analysis Overview
3
System Analysis
4
Systems Analysis vs. Systems Design
Systems Analysis: development phases in a project that primarily focus on the business problems, i.e., WHAT the system must do in terms of Data, Processes, and Interfaces, independent of any technology that can or will be used to implement a solution to that problem.
Systems Design: development phases focus on the technical construction and implementation of the system - HOW technology will be used in the system.
5
Context of System Analysis
Scope Definition Phase – WHAT PROBLEM
• Is the project worth looking at to solve problem?
Problem Analysis Phase – WHAT ISSUES
• Is a new system worth building?
Requirements Analysis Phase – WHAT REQUIREMENTS
• WHAT do the users need and want from the new system?
Logical Design Phase – WHAT TO DO
• WHAT must the new system do to satisfy users’ needs?
Decision Analysis Phase – WHAT SOLUTION
• WHAT is the best solution among others?
6
Classic Systems Analysis Phases
7
Scope Definition Phase
8
Scope Definition Tasks
Task 1.1: Identify Problems, Opportunities, and Directives◦ Deliverable: Preliminary Problem Statement
Task 1.2: Negotiate Preliminary Scope◦ Deliverable: Statement of Project Scope (boundary of
the project) what types of DATA to be studied,
what business PROCESSES to be included,
how the system INTERFACE with users, locations, and other systems
9
1. Scope Definition Tasks…
Task 1.3: Assess Project Worthiness◦ Cost/benefit analysis
◦ Decision: approve, cancel, renegotiate the scope
Task 1.4: Schedule and Budget Plan for Project◦ Deliverables: Project Charter – schedule and resource
assignment
Task 1.5: Present the Project and Plan◦ Deliverable: Project Charter (participants, problems,
scope, methodology, statement of work to be completed, deliverables, quality standards, schedule, budget)
10
1. Scope Definition Tasks…
11
Problem Analysis Phase
12
Problem Analysis Tasks
Task 2.1: Study the Problem Domain
◦ DATA: currently stored data, their business terms
◦ PROCESSES: current business events
◦ INTERFACES: current locations and users
◦ Deliverable: definition of system domain/models of Current System
Task 2.2: Analyze Problems and Opportunities
◦ Deliverables: updated problem statements and the cause-effect analyses for each problem and opportunities
Task 2.3: Analyze Business Processes
◦ Deliverable: current business process models
13
2. Problem Analysis Tasks…
Task 2.4: Establish System Improvement Objectives◦ Deliverable: System Improvement Objectives and
Recommendations Report
Task 2.5: : Update the Project Plan◦ Deliverable: updated project plan
Task 2.6: Present Findings and Recommendations◦ Deliverable: system improvement objectives
◦ Decision: continue/adjust/cancel current project
14
2. Problem Analysis Tasks…
15
Requirements Analysis Phase
16
Requirements Analysis Tasks
17
3. Requirements Analysis Tasks
Task 3.1: Identify System Requirements
◦ Functional requirements: activities and services provided by a system: business functions, inputs, outputs, stored data.
◦ Nonfunctional requirements: features, characteristics defining a satisfactory system: performance, documentation, budget, ease of use and learn, cost saving, time saving, security
◦ Deliverable: draft functional and nonfunctional requirements: improvement objectives and related input, output, processes, stored data to fulfill the objectives
18
3. Requirements Analysis Tasks
Task 3.2: Prioritize Requirements
◦ Mandatory vs. desirable requirements
◦ Time boxing: deliver the system in a set of subsequent versions in a time frame. The first version satisfies essential and highest prioritized requirements.
Task 3.3: Update the Project Plan
◦ If requirements exceed original vision: reduce the scope or increase the budget
◦ Deliverable: consolidated system requirements (completed requirements and priorities)
19
Logical Design Phase
20
Logical Design Tasks
21
4. Logical Design Tasks Task 4.1: Analyze Functional Requirements
◦ Logical systems models: WHAT the system must do (not HOW)
◦ Build prototypes to establish user interface requirements
◦ Deliverables: Data models (ERD), Process models (DFD), Interfaces models (Context diagram, Use case diagram), Object models (UML diagrams) of the Proposed System
Task 4.2: Validate Functional Requirements
Completeness check, revisit, make changes and additions to system models and prototypes to assure that requirements are adequately defined.
Associate nonfunctional requirements with functional requirements
22
Decision Analysis Phase
23
Decision Analysis Tasks
24
5. Decision Analysis Tasks
Task 5.1: Identify Candidate Solutions
o Deliverable: candidate systems (solutions) matrix
Task 5.2: Analyze Candidate Solutions
o Feasibility analysis is performed on each individual candidate without regard to the feasibility of other candidates - technical, operational, economic, schedule feasibilities (TOES)
25
5. Decision Analysis Tasks
Task 5.3: Compare Candidate Solutionso Deliverable: recommended solution
Task 5.4: Update the Project Plano Review and update the latest project
schedule and resource assignments
o Deliverable: updated project plan
Task 5.5: Recommend a Solution Deliverable: System Proposal
The system may cost more than projected. The system may be delivered later than promised. The system may not meet the users’ expectations
and that dissatisfaction may cause them not to use it.
Once in operation, the costs of maintaining and enhancing the system may be excessively high.
The system may be unreliable and prone to errors and downtime.
The reputation of the IT staff of the team is tarnished because any failure, regardless of who is at fault, will be perceived as a mistake by the team.
26
Results of Incorrect Requirements
Consistent – requirements are not conflicting or ambiguous.
Complete – requirements describe all possible system inputs and responses.
Feasible – requirements can be satisfied based on the available resources and constraints.
Required – requirements are truly needed and fulfill the purpose of the system.
Accurate – requirements are stated correctly. Traceable – requirements directly map to the
functions and features of the system. Verifiable – requirements are defined so they can
be demonstrated during testing.
27
Criteria to Define System Requirements
Problem discovery and analysis Requirements discovery Documenting and analyzing requirements Requirements management to handle
changes
28
The Process of Requirements Discovery
Analyzing requirements to resolve problems of:◦ Missing requirements◦ Conflicting requirements◦ Infeasible requirements◦ Overlapping requirements◦ Ambiguous requirements
Formalizing requirements◦ Requirements definition document◦ Communicated to stakeholders or steering body
29
Analyzing Requirements
A requirements definition document should consist of the following:◦ The functions and services that the system
should provide.◦ Nonfunctional requirements including the
system’s features, characteristics, and attributes.
◦ The constraints that restrict the development of the system or under which the system must operate.
◦ Information about other systems that the system must interface with.
30
Documenting Requirements
Sampling of existing documentation, forms, and databases.
Research and site visits. Observation of the work environment. Questionnaires. Interviews. Discovery Prototyping. Joint requirements planning (JRP) / Joint
application development (JAD)
31
Fact-Finding Methods
Joint requirements planning (JRP) – a process whereby highly structured group meetings (having defined agenda, key representatives) are conducted for the purpose of analyzing problems and defining requirements.
(JRP is a subset of a more comprehensive joint application development or JAD technique that encompasses the entire systems development process).
32
Joint Requirements Planning
Model-driven Analysis• Structured analysis• Information engineering• Object-oriented analysis
Accelerated Systems Analysis• Discovery prototyping• Rapid Architected Analysis
33
Systems Analysis Approaches
Model-driven Analysis emphasizes the drawing of graphical 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.
34
Model-Driven Analysis
35
Model-Driven Methods Structured Analysis: a PROCESS-centered technique to
analyze an existing system and define business requirements for a new system. The models illustrate the system’s components: processes (functions, tasks) and their associated inputs, outputs, and files
Information Engineering (IE): a DATA-centered, but process-sensitive technique to plan, analyze, and design information systems. IE illustrate and synchronize the system’s data and processes.
Object-oriented Analysis (OOA): a technique that integrates data and process concerns into constructs called OBJECTS. OOA illustrate the system’s objects from various perspectives such as structure and behavior.
36
Accelerated Systems Analysis
Accelerated Systems Analysis approaches emphasize the construction of prototypes to more rapidly identify business and user requirements for a new system
• Discovery Prototyping
• Rapid Architected Analysis
37
Discovery Prototyping
Discovery Prototyping – a technique used to identify the users’ business requirements by building a small-scale, representative or working model of the users’ requirements in order to discover or verify them.
Advantages• Prototypes cater to the “I’ll know what I want when I see it”
way of thinking that is characteristic of many users and managers
Disadvantages• Can become preoccupied with final “look and feel”
prematurely• Can encourage a premature focus on, and commitment to,
design• Users can be misled to believe that the completed system
can be built rapidly using prototyping tools
38
Rapid Architected Analysis
Rapid Architected Analysis – derive system models from existing systems or discovery prototypes.
Reverse Engineering – the use of technology that reads the program code for an existing database, application program, and/or user interface and automatically generates the equivalent system model.