Tag Archive: Systems Analysis & Design
Tasks:
System Enhancement:
8.1.1 Validate the problem
8.1.2 Benchmark program
8.1.3 Study & debug the program
8.1.4 Test the program
System Maintenance:
8.4.1 Analyse Enhancement Request
8.4.2 Make the quick fix
8.4.3 Recover existing physical system
Purpose of phase is to:
- Deliver the system into operation (production)
Tasks:
-
Smooth transition from old system to new system
Participants:
- System Builders
- System Analysts
- System Users
Deliverables:
- Operational System
- Post-Audit Review
Reference: SAD pg 88
Purpose of phase is to:
- Build & test system that fulfills Business Requirements & Physical Design Specifications
- Implement interfaces between new & existing systems
Tasks:
Construction:
6.1 Build & Test Networks (if necessary)
6.2 Build & Test Databases
6.3 Install & Test New Software Packages (if necessary)
6.4 Write & Test New Programs
Implementation:
7.1 Conduct System Test
7.2 Prepare Conversion Plan
7.3 Install Databases
7.4 Train Users
7.5 Convert to New System
Participants:
- System Builders
- System Analysts
- System Users
- Project Managers
- System Designers
Deliverables:
- Functional System
- Final Documentation
Reference: SAD pg 87, 684 – 694
Purpose of phase is to:
- Transform Business Requirements into Physical Design specifications
- How technology will be used in system (will be constrained by architectural model from previous phase)?
Tasks:
Systems Design (Integrating Commercial Software – Buy Solution)
4.1 Research Technical Criteria & Options
4.2 Solicit Proposals or Quotes from Vendors
5A.1 Validate Vendor Claims & Performances
5A.2 Evaluate & Rank Vendor Proposals
5A.3 Award (or Let) Contract & Debrief Vendors
Systems Design (In-house Development – Build Solution)
5.1 Design the Application Architecture
5.2 Design the System Databases
5.3 Design the System Interface
5.4 Package Design Specifications
5.5 Update the Project Plan
Technology based views of a System:
- Physical database Design Specifications
- Physical business process & software design specifications
Feasibility Checkpoint: GO or NO-GO?
Participants:
- System Designers
- System Analysts
- System Users
Deliverables:
- Combination of:
- Physical Design Models & Specifications
- Design Prototypes
- Redesigned Business Processes
Reference: SAD pg 86, 453 – 466
Purpose of phase is to:
- Identify Candidate Technical Solutions
- Analyse Candidate Solutions for feasibility
- Recommend Candidate System as target solution to be designed
Tasks:
5.1 Identify Candidate Solutions
5.2 Analyse Candidate Solutions
5.3 Compare Candidate Solutions
5.4 Update the Project Plan
5.5 Recommend a system solution
Methodologies:
- Candidate Systems Matrix
- TELCOS feasibility
Feasibility Checkpoint: GO or NO-GO?
Participants:
- System Users
- System Designers (System Builders)
- System Analysts
- System Owners
Deliverables:
- System Proposal (or Request for System Proposal)
Reference: SAD pg 84, 194
Purpose of phase is to:
- Translates Business Requirements into System Models (Data Flow Diagrams)
- Technology independent (translate words into pictures)
Tasks: First task can be broken into 2 separate functional requirements categories: Structure & Prototype
4.1a Structure Functional Requirements
4.1b Prototype Functional Requirements
4.2 Validate Functional Requirements
4.3 Define acceptance test cases
Methodologies (Agile Modelling):
- Architected Rapid Application Development
- Extreme Programming
Models:
- Logical DATA Models = Data & Info Requirements
- Logical PROCESS Models = Business Requirements
- Logical INTERFACE Models = Business & System Interface Requirements
Participants:
- System Analysts (draw models)
- System Users (validate models)
- Project Managers
Deliverables:
- Logical System Models & Specifications
Reference: SAD pg 84, 189
Purpose of phase is to:
-
Define & prioritise the Business Requirements
- Most IMPORTANT phase
- Analyst finds out what users want or need out of new system
Tasks:
3.1 Identify & express system requirements
3.2 Prioritise system requirements
3.3 Update or refine the Project Plan
3.4 Communicate the Requirements Statement
Participants:
- System Users
- System Owners (if they use system)
- System Analysts
- Project Managers
Deliverables:
- Business Requirements Statement
- BUILDING BLOCKS:
- Business Data Requirements
- Business Process Requirements &
- Business & System Interface Requirements
Reference: SAD pg 83, 185
Purpose of phase is to:
-
Study existing system & analyse findings.
-
Will the benefit of solving the problem exceed costs of building system?
Tasks:
2.1 Understand the problem domain
2.2 Analyse problems & opportunities
2.3 Analyse business processes
2.4 Establish system improvement objectives
2.5 Update or refine the Project Plan
2.6 Communicate findings & recommendations
Feasibility Checkpoint: Go or NO-GO?
Participants:
- System Owners
- Project Managers
- System Analysts
- System Users
Deliverables:
- A Set of System Improvement Objectives (grading criteria)
DO NOT define I/Ps, O/Ps or processes during this phase as further understanding of business problems is required.
Reference: SAD pg 82, 175
Purpose of phase:
-
Is the problem worth looking at?
-
If problem worth looking at, the following needs to be established …
- Size & boundaries of project
- Project vision
- Constraints or limitations
- Required project participants
- Budget & Schedule
Tasks:
1.1 Identify baseline problems & opportunities
1.2 Negotiate baseline scope
1.3 Assess baseline project worthiness
1.4 Develop baseline schedule & budget
1.5 Communicate the Project Plan
Feasibility Checkpoint: Go or NO-GO?
Participants:
- System Owners
- Project Managers
- System Analysts
Deliverables:
- Problem Statement (PIECES Framework)
- Scope Statement
- Statement of Work
Reference: SAD pg 79, 167