Chapter 1: The Systems Analyst and Information Systems Development

partly my own notes, and partly notes shamelessly stolen from the Old Testament (praise be).

The Systems Analyst

Primary goal of a systems analyst is to create value for the organization (Not just create a wonderful system). The larger and higher budget a project is, the more vulnerable it is to failure due to organizational problems. Systems Analysts mitigate this risk.

They do this by helping their team develop the right system in an effective way

They are change agents, who identify problems in an organization, design solutions, and convincing and train people to use them.

A good system analyst will fulfill 6 main skill categories in order to successfully lead projects:

Technical in order to understand the organization’s existing technical environment, the new system’s technology, and how they will both fit together in a solution
Business in order to communicate effectively with users and business managers, or with programmers and other technical specialists.
Analytical in both the project and organization level. Analysts must be able to see business patterns and understand financial numbers.
Interpersonal in order to effectively give presentations to large and small groups, and to write reports
Management in order to manage people with whom they work; they must manage the pressure and risks associated with unclear situations
Ethical in order to ensure honesty and fairness in the project team. Analysts often deal with confidential information and must maintain trust with all people

In large organizations, there can be multiple complimentary analyst roles:
- systems analyst: working with technical departments to develop systems.
- business analyst: helps identify business value that a system can create.
- requirements analyst: elicits requirements from stakeholders associated with a new system.
- infrastructure analyst: focuses on technical issues to do with how new systems will interact with existing infrastructure. This role requires a in-depth understanding of various software and hardware products and can potentially transition to a software architect role.
- change management analyst: focuses on people and management issues surrounding system installation. Interested in documentation and support.
- project manager: manages projects, ensuring they are on time and on budget.

The Systems Development Life Cycle

The Systems Development Life Cycle (SCLC) is a 4 step process for building an information system (IC):

planning: Why build the system? How can this Information System can support the business needs? How to structure the project? Delivers project plan.
analysis: Who, what, where, and when for the system. Delivers requirements definition.
design: How will the system work? Delivers system specification.
implementation: Building it! Focus on delivery and ongoing support.

Each phase is itself composed of a series of steps, which rely on techniques that produce deliverables. The phases can be iterative and non-linear.

SDLC is a process of gradual refinement. Each phase refined and elaborates on the work done previously.

This process of system development leads to gradual refinement, with each step producing a more specific output.

The Planning Phase

Focus in this phase is on why an information system (IS) should be built and how the team should build it.

Two steps:

**project initiation:** the system’s business value is identified. Often the origin of an IS project is a project sponsor (person/department who produced the request, ranging from a single manager to the entire senior management team) who submits a system request. If approved, The IS department works with the project sponsor to conduct a feasibility analysis.
System request and feasibility analysis are presented to an IS approval committee (aka steering committee). If approved, it enters project management and is handed off to a project manager, who staffs the project and initiates the analysis phase.

System Requests

Most system requests include five elements: project sponsor, business need, business requirements, business value, and special issues.

Project sponsor ****- the primary contact person for the project

Business need - the reason for prompting the project

Business requirements - the business capabilities that the system must have

Business value - the benefits that the organization should expect from the system

Special issues - a catchall category for other information that should be considered in assessing the project (for example, a specific deadline). All circumstances that could affect the outcome of the project must be clearly defined

Feasibility Analysis

Feasibility analysis helps determine whether or not to continue with the project by identifying important risks.

Technical Feasibility: Can We Build It?

First and foremost source of risk: familiarity with business application area (the domain of business the project applies to). An analyst who is unfamiliar with the application area generates risk, and doubly so if users have no familiarity.
Familiarity with technology: Less familiarity within the organization generates more risk. The risk increases further if the technology is emerging (and therefor less mature and documented)
Project size: Large projects (in terms of completion time and/or manpower) have more risk. Large systems are typically highly integrated with other systems, increasing project complexity.
Compatibility: The harder it is to integrate the system with the company’s existing technology, the higher the risk will be.