SFDV2002 - Principles of Information Systems Lecture 4: Understanding the Problem.

SFDV2002 - Principles of Information

Systems

Lecture 4:Understanding the Problem

2

Overview

Revisit analysis phaseRole of systems analystSourcing enterprise informationUnderstanding through modelsThe project requirementsTypes of requirementsRepresenting requirements

3

Objectives: Understand user needs Develop requirements

Learn as much as possible about problem domain

Main activities:1. Gather information2. Define system requirements3. Build prototypes4. Prioritise requirements

SDLC: Analysis Review

5. Generate and evaluate alternatives

6. Review recommendations with management

requirements

requirements

requirements

4

A Poor Analysis Phase

Domain not well understoodDoes not reflect the real needs of the

customerMisunderstanding between various

stakeholdersClients do not understand what they wantHow to enhance the existing system is not

clearInadequate requirements discovery,

management, and validation processes

discovery

5

Discover as much as possible about problem domain

Facilitate communication between all groups with a stake in the project

Elicit requirements from as many sources as possible

Document requirements accurately and consistently

Manage future revisions of requirements to meet evolving needs of system

The Role of Systems Analyst

requirements

requirements

requirements

6

Systems Analyst Relationships[S

ource

: Sta

ir and R

eynold

s, 20

03

]

7

Elicitation Techniques – Process by which analysts gather information

1. Interview users: Comprises 3 Steps –

prepare, conduct interview, and follow up

Discover issues Confirm requirements Can interview individuals

and groups Can have closed

(prepared questions) and open (no questions) interviews

Use: Really valuable method to get requirements and understand domain in detail

2. Survey stakeholders: Questionnaire construction &

Distribution Can distribute to entire

organisation relatively quickly even over a large geographical area

Allows anonymous responses Allows Big sample size Qualitative (open questions) are

more descriptive and Quantitative (closed-questions) is measurable assign some values

Use: To discover preliminary issues and requirements

8

4. Examine source documents: Reports Forms Policies Mission statements Procedure manualsUse: To see concrete

examples of information use in the organisation

3. Observe business processes: Document observations Can be difficult to Get

approvalUse: To gain a deeper

understanding of how a user performs their work

9

Interviews are Great, however …

1. Users unable to articulate requirements2. Users ignorant of relevant technology3. User reluctant to discuss requirements4. Language barriers between analyst and user

5. Multiple user sources required

6. Analyst has insufficient skills to obtain requirements

7. Analyst too assertive

10

Examining a Source Document[S

ource

: Satzin

ger e

t al., 2

00

4]

CUSTOMER

ADDRESS

PRODUCTORDER DETAIL

ORDER DETAIL

PAYMENT

ORDER HEAD

ORDER HEAD

11

Domain Model (ERD)

12

Modelling Business Activities

Used in early analysis right through to formal design

Shows: Main activities Who or what initiates

activitiesDoes not show:

Order of processing Trigger events Flow of data!

Models the functionality of the proposed system (eventually)

Use Case Diagrams

Use cases: Business activity that comprises a series of smaller actions to support a goal. Effectively a function the system should provide1.Actors: role a user plays, or external systems, sometimes databases2.Associations:

Communication between an actor and a use case to represent that actor initiates or receives some kind of value from a use case

<<Include>>: Association between a primary use case (main activity) and a secondary use case that indicates that the secondary activity be must performed as part of the primary (base) activity.

<<extend>> (not shown): Association between a primary use case (main activity) and a secondary use case that indicates that the secondary activity may be performed as part of the primary (base) activity (usually as a result of some condition that you can represent in a more detailed model).

3.Systems boundary box: grouped functionality or the set of activities for a particular scenario

13

14

What are Requirements?

“They are descriptions of how the system should behave, application domain information, constraints on the system’s operation, or specifications of a system property or attribute.”

“A requirement is a statement of need, something that some class of user or other stakeholder wants.”

Cf. architectural brief[Source: Alexander and Stevens, 2002]

[Source: Kotonya and Sommerville, 2001]

15

Effects of Poor Requirements“Once your software hits the field, removing

a requirements defect costs at least a hundred times as much, assuming you can fix it at all.”

Consequences: Affects later stages of SDLC through

exponentially increasing costs Recall examples of project failures

[Source: Lawrence, Wiegers, and Ebert, IEEE Software, 2001]

1.Requirements related costs much greater.Why? Investment far greater during design and coding.Poor or incorrect requirements affects later stages of SDLC through exponentially increasing costs

Therefore, investing time in effective requirements analysis early saves time, effort, and money

16

Characteristics of Good Requirements

Consistent

Correct

AtomicFeasible

Testable

Traceable

Unambiguous

Complete

Concise

Precise

Include descriptions of all facilities required

Exact and accurate

No redundant words, diagrams etc.

Should be able to implement

Should met in test version of system

Must know who suggested it, why it exists, etc

No conflicts or contradictions

Match needs to users

Can not be decomposed further

Should have a single interpretation

17

Types of RequirementsFunctional requirements:

“… describes an activity or process that the system must perform”

Non-functional: describes all other aspects of system such as

performance, reliability, usability, portability, data, implementation, etc.

“… characteristics of the system other than the activities it must perform or support”

Examples: data, performance, operational, …

[Source: Satzinger et al., 2004]

[Source: Satzinger et al., 2004]

The system shall allow users to search for an item by title, author, or ISBN

18

Types of Requirements (cont’)

General requirements: in broad terms “what the system should do”

Data requirements: define the type of data the system shall operate upon

or produce

Usability requirements: state user interface and system availability constraints

The system shall maintain records of all library materials including books, journals, newspapers and magazines, ...

The ISBN is a 5-part item: the ISBN tag and a 4-part identifier

Should use a hierarchical menu structure for navigation

19

Types of Requirements (cont’)

Implementation requirements: states how the system must be implemented

Performance requirements: specify the minimum acceptable performance of the

system

Operational requirements: specify constraints that should be satisfied during

system usage

The system’s user interface shall be implemented using a WWW browser

The system shall support at least 20 transactions per second

Reliability in terms of mean-time to failure (MTTF)

20

Expressing Requirements

Natural language descriptions: Text descriptions Scenarios

Models: DFDs ERDs Use Case Diagrams Class Diagrams …

Published standards / in-house templates: ISO 9000 IEEE/ANSI 830-1993

Prototyping: Evolutionary Revolutionary

Formal mathematical notation: Z

21

Summary

The analysis phase seeks to understand the problem and the related context in as much detail as possible

The systems analyst plays a crucial role through the diversity of interactions and activities

Requirements can determine the likelihood of success or failure of a systems development project

There are numerous techniques available for discovering then specifying requirements

-------------------------------------------------NOTE: START Tutorial 2 & Practical Sessions 2