requirements specification concepts notes. requirements specification 2 the focus of our attention...

34
Requirements Requirements Specification Specification Concepts Concepts Notes Notes

Upload: paula-moody

Post on 14-Dec-2015

223 views

Category:

Documents


0 download

TRANSCRIPT

Requirements Specification Requirements Specification ConceptsConcepts

NotesNotes

Requirements SpecificationRequirements Specification 22

The Focus of our Attention

Cognition

Representation

Social

FormalInformal

IndividualView

IntegratedView

Fuzzy

FullyUnderstood

DesiredOutput

Pohl, K. (1993) Pohl, K. (1993) The Three Dimensions of Requirements EngineeringThe Three Dimensions of Requirements Engineering , 5th International , 5th International Conference on Advanced Information Systems Engineering (CAiSE•93), C. Rolland, Conference on Advanced Information Systems Engineering (CAiSE•93), C. Rolland, F. Bodart and C. Cauvet (ed.), Springer-Verlag, Paris, France, 1993, pp. 275-292.F. Bodart and C. Cauvet (ed.), Springer-Verlag, Paris, France, 1993, pp. 275-292.

Requirements SpecificationRequirements Specification 33

R.E. Specification in I.S.D.

,

specification

REQUIREMENTS ENGINEERING

DESIGN ENGINEERING

knowledge

acquisition

design

validation

problems

informal requirementsdomain knowledge

information system

verification

part of specification to be computerised

Requirements SpecificationRequirements Specification 44

Key Elements of a R.E. Specification

EnterpriseRequirements

FunctionalRequirements

Non-FunctionalRequirements

RequirementsSpecification

Requirements SpecificationRequirements Specification 55

Types of RequirementEnterprise Requirements

Modelling the enterprise setting

Functional Requirements

Modelling the behaviour of the intended system

Non-Functional Requirements

Modelling the constraints that the intended system should obey

Requirements SpecificationRequirements Specification 66

Relationship Between Models

CaptureEnterprise

Goals

DevelopHigh-level

Architecture

DetailedNFR Model

DetailedFR Model

Distinguish I.S.

Goals

enterprise goals

IS-NFR goalsIS-FR goalsArch. reqs

Functions, data definitions

comp. definition

Requirements SpecificationRequirements Specification 77

The Euromethod Framework

Computer SystemComputer System

ActorsActors

Info ResourceInfo Resource

supportssupports

useuse performperform

ProcessesProcesses

useuse

BusinessInfo View

BusinessProcess View

WorkpracticeView

definesdefines

definesdefines

definesdefines

rep. ofrep. of

rep. ofrep. of

rep. ofrep. of

Comp. Sys.Data View

Comp. Sys.Function View

Comp. Sys.Arch. View

representsrepresents

representsrepresents

automatedautomatedpart ofpart of

automatedautomatedpart ofpart of

I.S. ViewI.S. View

represents structuring ofrepresents structuring of

Comp Sys ViewComp Sys View

representsimplementation of

‘‘World’ ViewWorld’ View

Requirements SpecificationRequirements Specification 88

R.E. is about ‘Change Management’

EnterpriseModelling

EnterpriseModel

ConceptualModel of

Existing System

ConceptualModel of

New System

ReverseModelling

ApplicationDevelopment

ExistingSystem

NewSystemTransition

Integration& Analysis

visualise existing functioning

visualise future functioning

shared understanding

evaluation of changes

Requirements SpecificationRequirements Specification 99

Representations for the R.E. Spec

A requirements specification constitutes a conceptual model

The specification represents the ontology of the Universe of Discourse

different viewpoints

different notations used

a single repository

The specification is considered as a ‘contract’

Two dimensions

the product i.e. the requirements specification

the process i.e. the rationale behind decisions and choices during R.E.

Requirements SpecificationRequirements Specification 1010

Two Dimensions of Modelling

ENTERPRISESUBMODEL

INFORMATION

SYSTEM AND

FUNCTIONAL

REQUIREMENTS

SUBMODEL

determinesexplains

links

ref.

THE DEVELOPMENTPROCESSPROCESS SUBMODEL

A Model of

CONTEXTSCONTEXTS

DECISIONSDECISIONS

ARGUMENTSARGUMENTS

and ACTIONSACTIONS

about the process

of developing

requirements

A Model of

CONTEXTSCONTEXTS

DECISIONSDECISIONS

ARGUMENTSARGUMENTS

and ACTIONSACTIONS

about the process

of developing

requirements

ref.

ref.

DESIGN SUBMODEL

DEVELOPMENT PRODUCTPRODUCT SUBMODEL

NON-

FUNCTIONAL

REQUIREMENTS

SUBMODEL

Requirements SpecificationRequirements Specification 1111

Objectives of E.M.

to improve and document the knowledge regarding the business enterprise

to provide a proper problem domain analysis to encourage real user involvement,

facilitating communication and co-operation among stakeholders

to develop a basis for designing adequate Information Systems to achieve business goals

Loucopoulos, P. & Kavakli, E (1995) Enterprise Modelling and the Teleological Approach to Requirements Engineering, Inernational Journal of Intelligent Cooperative Information Systems, Vol. 4, No. 1, 1995, pp. 45-79.

Also at http://www.mac.co.umist.ac.uk/Comp-ISG/ERET/RET-Publications.html (download filr ISE-95-1)

Requirements SpecificationRequirements Specification 1212

The Need for Enterprise Analysis

To assist in organisational transformation:

a clear view of the business purpose

a vision of what these relations can change

To allign I.S. to organisational perspectives:

explain why IS components behave the way they do

use IS as the enabling technology to bring about transformation

explain effects of IS changes to organisational phenomena

Morton, M.S. (1991) The Corporation of the 1990s: Information Technology and Organisational Transformation, Oxford University Press, Oxford, 1991.

Requirements SpecificationRequirements Specification 1313

The Term ‘Enterprise’

An enterprise is a social structure.

It includes agents that may be

individuals or even structural units.

All these participants share

resources (material and

information), and provide services

that contribute to the overall

objectives of the enterprise.

Requirements SpecificationRequirements Specification 1414

Different Views on Enterprise Modelling

how, when, where ?how, when, where ?

who, what ?who, what ?

Teleological Teleological ViewpointViewpoint whywhy

??

Organisational Viewpoint

Operational Viewpoint

Requirements SpecificationRequirements Specification 1515

The Teleological Viewpoint

provides an interpretation of the enterprise’s current and potential configuration

specifies the purpose of the enterprise and its components in the form of a goal network, that express the intents of the enterprise stakeholders and their relationships

explains the behaviour of the enterprise and its components as the realisation of specific enterprise goals

Requirements SpecificationRequirements Specification 1616

Goal Refinement - Example

services to all parts

OBJECTIVEOBJECTIVETo increase ourmarket share

GOALGOAL

To acquire newcustomers customers

GOALGOALTo begin

advertising campaign

GOALGOALTo be more reliable than our competitors

GOALGOALTo have a high service level to customers

GOALGOAL

To respond quickly to courier emergencies

GOALGOAL

To respond quickly to customers requests

GOALGOAL

To provide courier

of the world

GOALGOALTo maintain old

Requirements SpecificationRequirements Specification 1717

Correlation Links

Guarantee a highdegree of safety

Decrease risk ofhuman error

Facilitate APPcontroller work

Reduce controller stress

Visualise future

scenarios

Detect conflicts or divergences

Handle quickly the sequence of

aircraft

Compare plan with all aircraft paths to verify

possible conflicts

Monitor continously

aicraft evolution

Obtain high reaction time

Display scenario Provide real time

data

Improve air-traffic flow

Improve airport throughput

Reduce delays Reduce aircraft reparation time

Order aircraft in time and space

Handle problems and emergencies

Deal with changes of the

situation in time

Deal with airport limitations

The controller should validate

the plan

Easy and rapid system interface

Deal with changing meteorological

conditions

Deal with changes of the airport runway

Deal with conflicts and emergencies

User friendly and eficient system

interface

Obtain accurate plans

contributes (+)

contributes (+)

Replan best solution

contributes (-)

contributes (-)

contributes (-)

IS REQUIREMENTSIS REQUIREMENTS

contributes (+)

GOALs ModelGOALs Model

contributes (-)

Requirements SpecificationRequirements Specification 1818

Relationship between E.M. & I.S.M.

Operationalisation is the process of refining goals so that the resulting subgoals have an operational definition.

Operationalised goals can be assigned to organisation components, including automated systems.

Requirements SpecificationRequirements Specification 1919

The ATC Case Study - The IS Objectives (FR View)

GOALGOAL

Visualise air trafficscenarios

IS-FRIS-FR

Display tables

IS-FRIS-FR

Display mapsand airways

IS-FRIS-FRDisplay plots

IS-FRIS-FR

Display alerts andconflicts

IS-FRIS-FR

Display tracks

IS-FRIS-FR

Display positionand speed

IS-FRIS-FRDisplay track

history

IS-FRIS-FR

Display correlated flightplan and supplementary

info

IS-FRIS-FR

Display altitudetendency

IS-FRIS-FR

Display primarydata detections

IS-FRIS-FR

Display meteodata ftom radar

IS-FRIS-FR

Display ambiguousflight plans

IS-FRIS-FR

Display flight planscorresponding tolost tracks

IS-FRIS-FR

Display uncorrelatedflight plans

IS-FRIS-FR

Display correlated flight plans

IS-GOALIS-GOAL

The system shoulddisplay scenarios

OM

motivatesmotivates

motivates

motivates

motivates

The Display SystemThe Display System

Requirements SpecificationRequirements Specification 2020

Approaches to FR Modelling

Structural Viewpoint Modelling

define relationships between objects

Functional Viewpoint Modelling

process oriented view

Behavioural Viewpoint Modelling

specify the activities operating on the information structures, and the events that trigger these activities

Structural Viewpoint Modelling

define relationships between objects

Functional Viewpoint Modelling

process oriented view

Behavioural Viewpoint Modelling

specify the activities operating on the information structures, and the events that trigger these activities

Requirements SpecificationRequirements Specification 2121

Relationships Between Facts, Activities and Events

FACTS(propositions about the UoD)

ACTIVITIES(actions inducing change

on facts of the UoD)

EVENTS(state changes in the UoD)

modify acknowledge

trigger

Requirements SpecificationRequirements Specification 2222

Formalisms - Set of Concepts, Models

Framework of understanding Framework of understanding

[Olle et al - Addison Wesley]DataData

E/R

NIAMDADES

CIAM

ERAE

MERISE

SSADM

SADT

IE

ProcessProcess

PETRI Nets

EventEvent

Business Class

REMORA

TEMPORA

Olle, T., Hagelstein, J., Macdonald, I.G., Rolland, C., Sol, H.G., Van-Asche, F.J.M. Olle, T., Hagelstein, J., Macdonald, I.G., Rolland, C., Sol, H.G., Van-Asche, F.J.M. and Verrijn-Stuart, A.A. (1988) Information Systems Methodologies - A Framework and Verrijn-Stuart, A.A. (1988) Information Systems Methodologies - A Framework for Understanding, North Holland, Amsterdam, The Neteherlands, 1988.for Understanding, North Holland, Amsterdam, The Neteherlands, 1988.

Requirements SpecificationRequirements Specification 2323

Definition of NFRs

NFRs have been defined as:

restrictions or constraints placed on a system service [Sommerville 1992]

quality requirements [Boehm 1976; Deutsch and Willis 1988]

non behavioural requirements [Davis 1993]

According to the IEEE guide, NFRs are considered in terms of: performance, external interfaces, design constraints and quality attributes. [IEEE-Std. ‘830’ 1984]

NFRs have been defined as:

restrictions or constraints placed on a system service [Sommerville 1992]

quality requirements [Boehm 1976; Deutsch and Willis 1988]

non behavioural requirements [Davis 1993]

According to the IEEE guide, NFRs are considered in terms of: performance, external interfaces, design constraints and quality attributes. [IEEE-Std. ‘830’ 1984]

Requirements SpecificationRequirements Specification 2424

Relationships between User Needs and NFRs

User's Need User's concern Nonfunctional requirement

FUNCTIONAL

How easy is to use? USABILITY

How secure is it? INTEGRITY

How often will fail? RELIABILITY

How well utilise a resource? EFFICIENCY

How easy to verify its performance? VERIFIABILITY

Does it interface easily? INTEROPERABILITY

PERFORMANCE

CHANGE

How easy is to repair?

How easy is to change?

How easy is to transport?

How easy is to expand or upgrade

its capacity or performance?

MAINTAINABILITY

FLEXIBILITY

PORTABILITY

EXPANDABILITY

Requirements SpecificationRequirements Specification 2525

Classification of NFRs

NONFUNCTIONALREQUIREMENTS

PROCESSREQUIREMENTS

PRODUCTREQUIREMENTS

EXTERNALREQUIREMENTS

DELIVERYREQUIREMENTS

IMPLEMENTATIONREQUIREMENTS

STANDARDSREQUIREMENTS

LEGALCONSTRAINTS

ECONOMICCONSTRAINTS

INTEROPERABILITYREQUIREMENTS

USABILITYREQUIREMENTS

EFFICIENCYREQUIREMENTS

RELIABILITYREQUIREMENTS

PORTABILITYREQUIREMENTS

PERFORMANCEREQUIREMENTS

CAPACITYREQUIREMENTS

Requirements SpecificationRequirements Specification 2626

Approaches to Modelling NFRs

Unlike FRs, NFRs have been treated informally Approaches

product-oriented

develop formal definitions of NFRs according to the desired characteristics the system must posses

process oriented

define NFRs as constraints upon the development process

goal-driven

represent NFRs in terms of interrelated goals that drive design decisions during the development process

Requirements SpecificationRequirements Specification 2727

The ATC Case Study - The IS Goals (NFR View)

IS-NFRIS-NFR

The display must accommodate allnecessary data for the scenario

IS-NFRIS-NFR

Display radar datain real-time

IS-NFRIS-NFR

Aircraft position should be displayed in

less than 3/16 sec of the radar sweep period

GOALGOAL

Visualise air trafficscenarios

IS-GOALIS-GOAL

The system should perform in real-time

IS-NFRIS-NFR

Display 500 table symbols

IS-NFRIS-NFR

Display 200 vectors

IS-NFRIS-NFR

Display 100meteo plots

IS-NFRIS-NFR

Display100 tracks

OM

motivates

motivates

motivates

motivates

The Display SystemThe Display System

Requirements SpecificationRequirements Specification 2828

Expressing NFRs

NFRs must be associated with measurable properties of the system so that

all NFRs are objective and testable

Example of vague objective

“the system should be easy to use and organised in such a way that the user errors are minimised”

can be expressed as

“the user must be able to use the system within 3 days and must not make more than 2 errors per day”

Requirements SpecificationRequirements Specification 2929

Example of Measurable Properties

User's Need User's concern Nonfunctional requirement

FUNCTIONAL

How easy is to use? USABILITY

How secure is it? INTEGRITY

How often will fail? RELIABILITY

How well utilise a resource? EFFICIENCY

How easy to verify its performance? VERIFIABILITY

Does it interface easily? INTEROPERABILITY

PERFORMANCE

CHANGE

How easy is to repair?

How easy is to change?

How easy is to transport?

How easy is to expand or upgrade

its capacity or performance?

MAINTAINABILITY

FLEXIBILITY

PORTABILITY

EXPANDABILITY

Requirements SpecificationRequirements Specification 3030

RE Specifications as Descriptions

A specification is a description of some part of the UoD

the so-called MODEL

The way a specification can be build conforms

to another specification of a higher level

the so-called METAMODEL

Requirements SpecificationRequirements Specification 3131

Intension vs Extension

Separating knowledge concerning general principles in the UoD (intension) from actual occurrences of the UoD (extension)

e.g. the concept of employees vs the actual occurrence of the information that describes employees

Semantic Knowledge (infological) vs Syntactic Knowledge (datalogical)

The meaning TriangleThe meaning Triangle

CONCEPTCONCEPT

SYMBOLSYMBOL OBJECTOBJECTextensionextension(refers to)(refers to)

intensionintension(expresses)(expresses)

refers torefers to

Requirements SpecificationRequirements Specification 3232

C.M. for Methods & Applications

DATABASES CONCEPTUALMODELLING

Methods

SpecificationRepositories

Method

Schema Design

Transactions

Design

FR SpecificationNFR SpecificationEnterprise ModelProcess Model

Models forthe capture

of real-worldknowledge

Application DependentApplication Dependent

Method DependentMethod Dependent

Metamodels

Product

Process

the designof the

repository

Models forthe designof databaseapplications

Models for

Requirements SpecificationRequirements Specification 3333

Levels of Abstraction

Token Level

S-Class

M1

M2

InstanceReference

works_forworks_forEmployeeEmployee

EntityEntity

John Smith

ConceptConcept

DepartmentDepartment

RelationshipRelationship

BTBTworks_forworks_for

Requirements SpecificationRequirements Specification 3434

An Example of Levels of abstraction

leads_to

justifies

is_for

tested_by

postulated_in

M2

M1

S

T

postulated_intested_by

leads_to

justifies

is_for

leads_to

SUPPORTINGARGUMENT

justifies

is_for

tested_by postulated_in

leads_to

justifies

is_for

tested_by postulated_in

instance_of

DESIGNACTION

GOAL

INTENTION

HYPOTHESISPRODUCT

ARGUMENT

PROPOSEGOAL

OPERATIONALISEGOAL

ESTABLISHGOAL

ATC SUP. ARGUMENT

PROPOSE ATC GOAL

OPERATIONALISE ATC GOAL

Reject H1.3Accept H1.1, H1.2 as AND Goals G2, G3

H1.1

Operationalise G1Accidents due toseparation

standards violationG1

ATCGOAL

ESTABLISHATC GOAL