Where have all the

systems analysts

gone?

James Cadle

© BAIQ

James Cadle: career progression

1970: Bank clerk

1975: Work Study Engineer

1978: Organisation & Methods Analyst

1983: Systems Analyst

1984: IT Project Leader

1985: IT Project Manager

1987: Account Manager

1990: Consultant/Project Manager

1995: Independent Consultant/ Project

Manager/ Trainer

© BAIQ

Systems analyst - definition

A systems analyst is a problem-solving specialist who works with

users and management to gather and analyze information on

current and/or future computer-based systems. With this

information, the systems analyst, working with other I/S personnel,

defines the requirements that are used to modify an existing

system, or to develop a new system. The systems analyst identifies

and evaluates alternative solutions, makes formal presentations,

and assists in directing the coding, testing, training, conversion,

and maintenance of the proposed system.

Misic and Graf, The Journal of systems and Software, 2004

© BAIQ

The problem

Business

users Developers

<

<

© BAIQ

The solution

Systems analyst

Business

users Developers

<

<

© BAIQ

Systems analyst’s role

Analyse: the business and its rules

business users’ requirements/needs

technical possibilities

Produce: functional specification (requirements

specification)

Liaise with designers/developers for solution

Also: user training and documentation

assistance with testing and implementation

© BAIQ

Systems analyst’s task

Ideas

Problems

Needs

Processing

models

Data

model

Current system LDS (basic)

composed of

on

the subject of

for

the recipient of

for

TYPE TRAININGrostered to perform

performed by perfomed as

to perform

implemented as

in conformance withthe subject of

for

VEHICLE

SERVICE

assigned

assigned to

the subject of

for

JOURNEY

the type for

classified into

JOB

MAINTENANCE

PROGRAMME

SERVICE

VEHICLE TYPE

ENGINEER

DRIVER

VEHICLE

Completed Purchase Orders

Purchase Orders

Deliveries

Supplier

b

Copy Purchase Orders

Purchase

OrdersM3

Purchase Order

Requests & Quotations

Quotations

Requests For Quotations

Quotation

RequestsM2

Request For Quotation

Supplier

b

Order Request

Order Request

Order

RequestsM1

Order Request

Workshop

Foreman

a

Issue Purchase

Orders

3 Order Dept

Receive Delivery

Notes

4 Order Dept

Request

Quotations

2 Order Dept

Receive Order

From Works

1 Order Dept

Requirements

catalogue

Functional or Requirements Specification

aaaaaaaaaaaaaaa

bbbbbbbbbbbbbbb

ccccccccccccccccc

xxxxxxxxxxxxxxxxx

yyyyyyyyyyyyyyyyy

zzzzzzzzzzzzzzzzz

Business

users

© BAIQ

Systems analysis techniques

‘Traditional’ approach: Each person does their own thing

Outputs largely textual (though flowcharts used)

Structured methods: Structural model (for example, SSADM)

Separation of physical and logical views

Separation of data and process

Outputs largely diagrammatic

Today: No ‘standard’ approach

UML/UP has become a de facto standard?

Agile/RAD/’Extreme’ programming used

Packaged solutions sought

© BAIQ

SA career progression

Majority of analysts

followed main path

Result: bias towards technology, not business

Operator ProgrammerSystems

analyst

Project

leader

Business

role

IT manager /

director

© BAIQ

1980s dissatisfaction

Businesses still not getting what they

want…

…or perhaps need

ICT still seen as remote from business

and focused on technology

Solution: new role of Business Analyst

© BAIQ

Business analyst’s role

Analyse: the business and its rules

business users’ requirements/needs

business processes

Produce: improved business processes

requirements specification for ICT components

Liaise with designers/developers for solution

Also: user training and documentation

assistance with testing and implementation

© BAIQ

BA career progression

Software

engineer

Business

analyst

Project

manager?

Business

role

Senior

business

analyst?

Change

manager?

?

© BAIQ

Business analysis techniques

No defined methods

No generally agreed techniques

Each person makes their own way

Some approaches (for example, Rummler-Brache) quite widely used

Some SA techniques appropriate:flowcharts

use cases

Data modelling often not seen as BA function

Some guidance available – but only that – no formal methods

© BAIQ

SA project lifecycle

Users

Ideas / business

needs

Systems Analyst

Detailed

requirements

Process models

Data models

Designer

System

architecture

Module

specifications

Database schemas

Developers

Coded & tested

software modules

© BAIQ

BA project lifecycle

Users

Ideas / business

needs

Business Analyst

Business

requirements

Designer

System

architecture

Module

specifications

Database schemas

Developers

Coded & tested

software modules

So who is defining the (IT) processes and data requirements?

© BAIQ

It gets worse...

Users

Ideas / business

needs

Business Analyst

Business

requirements

Developers

Coded & tested

software modules

So who is designing the IT system?

© BAIQ

But what about packages?

Users

Ideas / business

needs

Package

vendors

Selected /

customised

package

Business

Analyst

Business

requirements

© BAIQ

Conclusion

Many (most?) BAs not from IT

Good for business focus

Not so good for interface with ICT

Sometimes, in effect, ‘super users’

Is the business/IT gap back again?