SystemsAnalyst

Robertson-Howard Consultants

Copyright © 2002 Robertson-Howard Consultants, Lincoln, NE 68504

A General Overview

The Systems Analyst



Agenda

• General Definitions

• The Job

• Requirements Analysis

• Systems Analysis



System

• A set of interacting components with relationships established between them.

• A set of variables selected by an observer together with the constraints across variables he either discovers, hypothesises or prefers.



System

• An organism or a social institution and a constraint is the logical complement of a relation, an equivalent definition of system is that it represents a set of components together with the relations connecting them to form a whole unity.

• Describes, simulates or predicts a portion of his environments it may be regarded as a model of that portion. The model and the modeled "world" share the same organization but because of their different material realizations they are likely to differ in structure.



Model

• Models are constructed to answer specific questions about a proposed system.

– Will it Work?

– How can we make it work better?

• A model is a device, scheme, or procedure typically used in systems analysis to predict the consequences of a course of action.



Model

• A model consists of a set of objects, described in terms of variables and relations defined on these and either– Embodies a theory of that portion of reality which it claims to

represent

– Corresponds to a portion of reality by virtue of an explicit homomorphism (many to one) or isomorphism (one to one)

between the model's parameters and given DATA.



Four kinds of Models • Sampling Models

• Iconic Models

• Behavioral Models

• Symbolic Model



Models

• Formal - A mathematical expression.

– Analytic Model

– Simulation Model

• Causal - Cause-effect relationships.

– Correlational

– Deterministic

– Stochastic

– Dynamic

– Static



Systems Analysis

• Formal inquiry to ID COA’s

• Problem Situation to evaluate COA’s

• Systems analysis combination of

– Identification of objectives

– Examination of probable consequences

– Presentation of the results



The Job

• Interface…Interface…Interface

• Technical Generalist

• Systems Expert

• Projects mostly IT Related

• Requirements Analysis*

• Systems Analysis

• Design the project *depends on project manning



The Systems Analyst

• Work is up front.

• Project complexity is proportional to Interface complexity.

• Interfaces between project and existing systems must be rigorously documented.

• Interfaces don't work the project will fail to meet expectations.



Requirements Analysis

• Understand the customer’s desires

– Drawing diagrams

– Writes Scenarios

– Questions the Customer

– Gathers Samples

• Document the specifications



Requirements Analysis requires

• Clarity

• Functional area estimates and pertinent facts

– Personnel

– Training

– Documentation

– Overall Corporate Mission

– Internal Logistics

– External Logistics

– Facilities requirements • All assumptions stated in writing.



Requirements Analysis will provide

• Restated Mission Statement

• Project End State

• Preliminary Preparation Required

• Deliverables by functional area



Requirements Analysis Sequence

• Review the Project Specifications

– Determine what is required

– Identify the Systems

– Determine Concept of the Project

– First-cut Timeline

• Determine specified, implied, and essential Task.



Tasks

• Specified - are specifically assigned

• Implied - must be performed to accomplish a specified task

• Essential Task - those task that are essential to meet the specifications (composed of Specified and Implied)



Requirements Analysis Sequence (cont.)

• Review the available assets

• Determine constraints.

• Identify critical facts and assumptions.

• Conduct a Risk Assessment.

• CCIR’s



Requirements Analysis Sequence (cont.)

• Plan the use of the available time

• Write a restated Mission

• Approval for the restated Mission

• Requirements Analysis briefing



Risk Assessment

• Determine Hazards that will result from the project.

– Physical Hazards

– Asset Hazards

– Operational hazard

– Collateral Hazard

• Assess each hazard

– severity

– potential loss



Risk Assessment

• Develop controls

– Training

– Standards

– Leadership

– Personnel

• Implement Controls

• Supervise and Evaluate.



Risk Assessment

Hazard Probability

Frequent Likely Occasional Seldom UnlikelyCatastrophic

Critical

Marginal

S

eve

rity

Negligble

Risk LevelsE (Extremely High) - loss of the ability to accomplish the MissionH (High) - Significantly degrades mission capabilities in terms of required mission standardM (Moderate) - Degrades mission capabilities in terms of required mission standardL (Low) - Little or no impact on accomplish of mission



Risk Assessment

Hazard Probability

Frequent Likely Occasional Seldom UnlikelyCatastrophic L L L L L

Critical L L L L L

Marginal L L M H H

S

eve

rity

Negligble L L M H H


This Hazard would not effect the mission



Risk Assessment

Hazard Probability

Frequent Likely Occasional Seldom UnlikelyCatastrophic L M H L L

Critical L M M M L

Marginal L L M L L

S

eve

rity

Negligble L L L L L


This Hazard can cause problems



Risk Assessment

Hazard Probability

Frequent Likely Occasional Seldom UnlikelyCatastrophic H H M L L

Critical H H M L L

Marginal M M M M L

S

eve

rity

Negligble L L M M L


Need to find another way to do this one



The Systems Analyst

• Knows systems and understands systems.

• Is not overly concerned with how the project system implementation details.

• Is very concerned with how the project interfaces with existing system interfaces.

• Will know the exact specifications of the existing system.

• Is concerned with the internal system aspects of the project.



Interface…Interface…Interface

• Two physical devices must interface with each other, share data, react to data from another, and be under control.

• Software or Database that must share data with each other.

• Multiple Users must communicate with each other.



The Systems Analyst • Determines the system elements

• Assigns systems elements to– Software

– Hardware

– Users

– Databases

– Documents

– Procedures

• Provides Focus



Get it Right up Front

• Spend as much time as necessary to get the analysis done correctly.

• Make sure that you understand both the specifications and requirements

• Spend as much time as necessary to get the design done correctly, test your design.

• If your design is done properly, the programming should be the easiest part.



3%

5%

7%

5%

7%

6%

67%

Requirements

Specification

Design

Coding

Testing

Integration

Maintenance

Software Life Cycle Cost



Get it Right the First Time

• 60 to 70 percent of all faults in large-scale project are specification and design faults.

• Cost of Errors, every dollar spent in Specification Phase– $2.00 when caught in the design phase

– $10.00 will be required in the coding phase

– $100.00 to repair a fault caught in the Maintenance Phase.



If your design doesn't work

• Analyze the design, looking for missing possible inputs, controls, and physical requirements.

• If your design cannot be adjusted, revisit your requirements analysis.

• If the design is still incapable, get with the customer and redo the requirements phase.



Characteristics of a Good Design

• Understandable by ALL parties involved in the project.

• Maps onto the requirements specifications.

• Is modular has

– High Cohesion

– Low Coupling

• It can be tested, e.g. a Software Program compiles, it binds with all libraries, and the interfaces work.

• Can it be easily translated to code.

SystemsAnalyst

Documents

Transcript of SystemsAnalyst