University of Toronto at Scarborough © Kersti Wain-Bantin CSCC40 systems analysis 1

what is systems analysis?

preparation of the system’s requirements/definition,with focus on: what, why, who, when, where, and for whom

functional requirements• what does the new/revised system do?• what activities are supported by the system?• what information is maintained? • what interfaces are supported?

non-functional requirements• what are the global constraints on the system? (resources, security, reliability…)• what are the operational constraints on the system? (hardware, personnel…)• what are the life cycle constraints on the system's development? (schedule, methodologies, tools…)

University of Toronto at Scarborough © Kersti Wain-Bantin CSCC40 systems analysis 2

and when you complete the analysis?

you have:• statement of problem to be solved

i.e. a complete set of requirements• communication between analysts and users/clients• support for system evolution• input to design• system feasibility statement

in the form of:• text, diagrams, charts…

University of Toronto at Scarborough © Kersti Wain-Bantin CSCC40 systems analysis 3

knowledge area breakdown

engineering process: process models, process actors, process support and management, process quality and improvement

elicitation: requirements sources, elicitation techniques

analysis: requirements classification, conceptual modeling, architectural design and requirements allocation, requirements negotiation

specification: requirements definition document, software requirements specification, document structure and standards, document quality

validation: conduct of requirements reviews, prototyping, model validation, acceptance tests

management: change management, requirements attributes, requirements tracing

University of Toronto at Scarborough © Kersti Wain-Bantin CSCC40 systems analysis 4

process models: how you conduct the project,configuration management,marketing and feasibility studies

process actors: stakeholders, their goals and constraints

process support and management:cost, resources, schedule, training, tools

process quality and improvement:software quality attributes and measurementsimprovement planning and implementationimprovement standards and models

requirements engineering process

University of Toronto at Scarborough © Kersti Wain-Bantin CSCC40 systems analysis 5

users: management and workers who will use the system

customers/clients: those who pay for the system

market analysts: for systems for sale

regulators: government, professional organizations

system developers: development and maintenance

requirements engineering stakeholders(the sources of the requirements)

University of Toronto at Scarborough © Kersti Wain-Bantin CSCC40 systems analysis 6

sources of requirements

current system

system objectives,critical success factors

the “competition”

domain knowledge

stakeholders

operationalenvironment

organizationalenvironment

requirements elicitation

elicitation techniques

interviewsscenariosprototypesfacilitation meetingsobservation

University of Toronto at Scarborough © Kersti Wain-Bantin CSCC40 systems analysis 7

conceptual modeling

data and control flowsstate modelsevent tracesobject modelsetc. architectural design

and requirements allocation

requirements negotiation (conflict resolution)

University of Toronto at Scarborough © Kersti Wain-Bantin CSCC40 systems analysis 8

vali

dat

ion • conduct of requirements reviews by stakeholders

• prototyping, esp. for any dynamic system behaviour• model validation, checking for completeness, accuracy… • acceptance test planning

man

agem

ent • change management:

handling proposed changes • requirements attributes:

source, rationale, change history…• requirements tracing:

impact analysis when requirement change

• requirements definition document (aka concept of operations) includes software requirements specification, • completed with formal document structure and standards, to ensure document qualitysp

ecif

icat

ion

req

uir

emen

ts

University of Toronto at Scarborough © Kersti Wain-Bantin CSCC40 systems analysis 9

how is design different from analysis?

• analysis identifies what the system must do

• design states how the system will be constructed without actually building it

• design is done in two stages:

• logical design (technology independent)

• physical design (technology dependent)