requirements specification concepts notes. requirements specification 2 the focus of our attention...
TRANSCRIPT
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