advance information systems development (sd3043) lecture 3: requirements elicitation /...

Advance Information Systems Development (SD3043)Lecture 3: Requirements Elicitation / Analysis/Design

Dr. Haris [email protected]

10th October 2006

© H. Mouratidis 2006 2

Last Week

Notation An introduction to the Unified Modeling

Language (UML) An overview of UML

Use Case Diagrams Class Diagrams Interaction diagrams Statechart Diagrams Activity Diagrams


Learning Objectives

At the end of the lecture students will be able to: Understand the concepts related to

requirements elicitation/analysis/design Understand the activities involved during

requirements elicitation, analysis and design stages

Understand the difference between analysis and desing models


Lecture Layout

Software Lifecycle Requirements Engineering

Requirements Elicitation Activities, Scenarios

Requirements Analysis models

Design Refinement of analysis

Conclusions


Software Lifecycle

Different activities necessary to develop a software system

Lifecycle model represents all these activities and the relationships to each other

The main activities are: (Software Specification) Requirement Engineering Software Design Software Implementation Software Testing (validation) Software Evolution


Object Oriented Software Engineering activities

Application

Domain Objects

SubSystems

class...class...class...

Solution Domain Objects

SourceCode

Test Cases

?

Expressed in Terms Of

Structured By

Implemented

ByRealized By Verified By

SystemDesign

ObjectDesign

Implemen-tation

Testing

class....?

RequirementsElicitation

Use CaseModel

RequirementsAnalysis

Requirements Engineering Design


Requirements Engineering

RequirementsAnalysis

systemspecification

analysis

model

Problem StatementGeneration

RequirementsElicitation

ProblemStatement


Requirements Elicitation

Process of deriving the system requirements Results in a specification of a system that the

client understand Very challenging activity Requires collaboration of people with different

backgrounds Users with application domain knowledge Developers with solution domain knowledge

(design knowledge, implementation knowledge)


Requirements Elicitation concepts

Requirements have to be validated Completeness

All possible scenarios are described Consistency

Does not contradict itself Clarity

It is unambiguous Correctness

It represents accurately the system to be Realistic, verifiable, traceable


Requirements Elicitation Activities

Identifying actors Identifying scenarios Identifying use cases Refining use cases Identifying relationships among use cases Identifying non functional requirements


Identifying actors

It is not easy, especially in initial stages Database

Define the system boundary Useful questions

Which user groups are supported by the system to perform their work?

Which user groups execute main, secondary functions of the system?

What other systems interact with this system?


Identifying Scenarios

“Narrative description of what people do and experience as they try to make use of computer systems and applications” [Carroll, 1995]

Informal description of a single feature of the system used by a single actor

Do not replace use cases (complementary) Focus on specific instance

Describe the outcome of a decision Two scenarios


Types of scenarios

As-is scenarios Used to describe the current situation How the current system works?

Visionary scenarios Used to describe a future system Usually contribution of both user and developers is

needed Evaluation scenarios

Used to describe user tasks against which the system can be evaluated

Training scenarios Step by step instructions that guide a novice user

through a system


Identifying Use Cases

A use case specifies all possible scenarios for a given piece of functionality

Describe each of these use cases in more detail Participating actors Describe the Entry Condition Describe the Flow of Events Describe the Exit Condition Describe Exceptions Describe Special Requirements (Constraints,

Nonfunctional Requirements


Identifying non functional requirements

Usability: how easy the system is to operate Conventions adopted by the user interface

Reliability Acceptable mean time to failure

Performance Response time, availability, accuracy

Supportability: how easy is to change the system Adaptability, maintainability

Security Security constraints

Non-functional requirements often conflict!! Prioritise them


Requirements Analysis

Transition between real world and machine world Requirements elicitation is the input Analysis focuses on producing a model of the

system Analysis model consistent with requirements Main question to answer: what?

What functions must the system perform? Different approaches

Structured Object Oriented


Use Case vs Analysis Models (from Jacobson et al., 1999) Use Case

Described in the language of the customer

External view of the system Structured by use cases Used primarily as a contract

between customers and developers

May contain redundancies or inconsistencies between requirements

Captures System Functionality

Defines use cases that are furthered analysed during analysis

Analysis ModelDescribed in the language of the developerInternal view of the systemStructured by classes and packagesUsed primarily by developers to understand how to design the systemShould not contain inconsistencies or redundancies between requirementsOutlines a first-cut designDefines use case realisation


O-O Analysis activities

Identify classes Data Driven Responsibility Driven

Identify associations aggregates, attributes, inheritance

Review the model


Identifying classes

Rational Unified Process approach: Entity classes

Persistent information tracked by the system Boundary classes

Interactions between the actors and the system

Control classes Realising use cases


Identifying Entity Classes

(Data Driven) Natural language analysis

Limitations Depends on the style of writing More nouns than relevant classes

Part of speech Model Component Examples

Proper noun Instance Alice

Common noun Class FieldOfficer

Doing verb Operation Creates, selects

Being verb Inheritance Is a kind of

Having verb Aggregation Has, consists of

Modal verb Constraints Must be

Adjective Attribute Incident description


Identifying Boundary Classes

In each use case, each actor interacts with at least one boundary class

“translator” between actors and classes Do not describe in detail visual aspects To find boundary classes

Identify forms the user needs to enter info into the system

Identify messages, notes the system uses to respond to the user

Identify user interface controls that the user needs to initiate a use case


Identify Control Classes

Coordinate entity and boundary classes They do not have a concrete counterpart in

the real world Some useful tips for control classes

Identify one control class per use case Identify one control class per actor in the use

case The life span of the control class should cover

the extend of the use case


Responsibility Driven

Identify responsibilities in the system Class, Responsibilities, Collaborators (CRC) cards


Identifying associations

Properties Name: describe the association between two

classes Role at each end: function of each class multiplicity at each end: number of instances

Aggregates composition

Attributes Name, type


Reviewing the analysis model

Several iterations required Built incrementally and iteratively

Any changes should be reflected on the requirements Add/ extend use cases in requirements

Two main ways to review the model Checklist Questions


Ensuring the model is correct

Is the glossary of objects understandable by the user?

Do the classes correspond to user-level concepts?

Are all descriptions in accordance with the users’ definitions?

Are all error cases described and handled?


Ensuring the model is complete

Classes Is it needed by any use case? In which use case it is created?

Attributes When is it set? What is its type?

Associations Why was the specific multiplicity chosen?


Is the model consistent / realistic?

Consistent Are there multiple classes or use cases with

the same name? Are there objects with similar attributes and

associations that are not in the same generalisation hierarchy?

Realistic Any novel features on the system? Feasible? Can all the requirements be met?


System Design

System Design

2. System

Layers/PartitionsCohesion/Coupling

5. Data

1. Design Goals

DefinitionTrade-offs

4. Hardware/

Special purpose

Software

Buy or Build Trade-offAllocationConnectivity

3. Concurrency

Data structure

Persistent ObjectsFilesDatabases

ManagementAccess controlSecurity

6. Global Resource Handling

8. BoundaryConditions

InitializationTerminationFailure

Decomposition

Mapping

7. Software Control

Identification of Threads

MonolithicEvent-DrivenThreadsConc. Processes


Using Previous Knowledge

Nonfunctional requirements => Activity 1: Design Goals Definition

Functional model => Activity 2: System decomposition (Selection of subsystems

based on functional requirements, cohesion, and coupling) Activity 8: Boundary Conditions

Object model => Activity 4: Hardware/software mapping Activity 5: Persistent data management

Dynamic model => Activity 3: Concurrency Activity 6: Global resource handling Activity 7: Software control


Decomposition

Increasing number of complex systems The best way to deal with it, decompose them

Makes development easier, faster Difficult to modify / correct weak

decomposition once development has started Software architecture

Architectural styles


Basic Decomposition Concepts

Subsystem Smaller parts of the system

Service Set of related operations that share a common

purpose E.g. subsystem to provide notification service:

defines operations to send notices

Subsystem interface Set of operations of a subsystem that are

available to other subsystems


Coupling

Number of dependencies between two subsystems

Loosely coupled: almost independent Modifications on one have little impact on

the other Target: as loosely coupled as possible

Minimises the impact that errors or future changes might have

It is not easy to reduce coupling Introduce many unnecessary layers


Cohesion

Number of dependencies within a subsystem High/low cohesion Target: subsystems with high cohesion

Cohesion versus Coupling Increase cohesion by decomposing the

system into subsystems Increase coupling


Identify Boundary Conditions

How the systems is started, initialised and shut down Define how to deal with major failures (e.g. data

corruptions) Boundary use cases

Configuration If objects are not created or destroyed in normal

use cases Start-up and shutdown Exception handling

How the system should react in failures


Object Oriented Design

Design Classes are refined versions of the analysis classes

Include implementation details Full spec of attributes (visibility, type, etc) Full spec of operations (return type,

exceptions, visibility, etc) Full definition of relationships (navigability, etc)

Not an 1-to-1 mapping 1 analysis class could result in many design

classes


Visibility

A mechanism that specifies whether an attribute or an operation can be used by other classes or not. Private

Only in the class it is defined Denoted by -

Protected In the class it is defined and any descendant of this

class Denoted by #

Public By any class Denoted by +


Analysis vs Design Class (agilemodeling.com)


Analysis vs Design Class Diagram (Mouratidis, 2005)

TournamentControl

Player

players1..*

Tournament

name

1

1

applyForTournament()

Match

playMove()getScore()

matches1..*

startstatus

selectSponsors()advertizeTournament()acceptPlayer()announceTournament()

startend

11

1..*

matches 1..*

TournamentForm

1..*

1..*

acceptPlayer()removePlayer()schedule()

Advertiser

sponsors 1..*1..*

1..*

1..*

1..*


Analysis vs Design Class Diagram (Mouratidis, 2005)

TournamentControl

Player

players1..*

Tournament

1

1

+applyForTournament()

Match

+playMove(p,m)+getScore():Map

matches1..*

+start:Date+status:MatchStatus

+name:String+start:Date+end:Date

11

1..*

matches 1..*

TournamentForm

1..*

1..*

+acceptPlayer(p)+removePlayer(p)+schedule()

Advertiser

sponsors 1..*1..* 1..*

1..*

1..*

+selectSponsors(advertisers):List+advertizeTournament()+acceptPlayer(p)+announceTournament()+isPlayerOverbooked():boolean


Class Diagram (Booch, 1999)


Object Diagram (Booch, 1999)


Conclusions

Software Lifecycle Requirements Engineering

Requirements Elicitation Requirements Analysis

Reading: Chapters 4, 5 (essential)


Assignment Groups

Group members are allocated only by the module team!

All group members need to be registered Group members must belong to the same

tutorial groups If you have a preference send it by

Wednesday the latest You need to do the requirements elicitation

and analysis.

advance information systems development (sd3043) lecture 3: requirements elicitation /...

Documents

current system

system requirementsresults

functional requirements

use of computer systems

user tasks

use cases complementaryfocus

software systemlifecycle

otherthe main activities