Fundamentals of RE - Zohoiau-tnb.zohosites.com/files/Slides 04A - Requirements...Requirements specification & documentation: outline Free documentation in unrestricted natural language

Fundamentals of REFundamentals of RE

www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons 1

Fundamentals of REFundamentals of RE

Chapter 4

Requirements Specification

& Documentation

Chap. 2:Elicitationtechniques

Chap. 3:Evaluationtechniques

alternative options

Chap.1: RE products and processes

2www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons

start agreedrequirements

documented requirements

consolidatedrequirements

Chap. Chap. 44: : Specification &Specification &documentationdocumentationtechniquestechniques

Specification & documentation:as introduced in Chapter 1 ...

� Input of this phase:

– A bunch of agreed statements of different types

– Different types of ststement: Objectives, concept definitions,relevant domain properties, system/software requirements,assumptions, responsibilities


assumptions, responsibilities

– The above statements refer to system-to-be; some of the domain

properties and definitions may aise from the system-as-is

� Output of htis phase:

Resulting product: RequirementsRequirements DocumentDocument (RD)


�RD provides a precise definition of all features of the agreed

system in an appropriate specification language

-The language should support communication with stakeholders

and software engineers

- Parts of it should ideally be amenable to analysys by software


- Parts of it should ideally be amenable to analysys by software

tools for specification validation and verification in the next

phase pf RE process

�RD has:

– Rationale for options taken, satisfaction arguments

– Likely system evolutions & variants


� Organization of the statements in a coherent structure (see

chapter 1)

� Documentation in a form understandable by all parties


Documentation in a form understandable by all parties

– Often in annex: costs, workplan, delivery schedules

Requirements specification & documentation: outline

� Free documentation in unrestricted natural language

� Disciplined documentation in structured natural language– Local rules on writing statements– Global rules on organizing the Requirements Document

� Use of diagrammatic notations– System scope: context, problem, frame diagrams– Conceptual structures: entity-relationship diagrams


– Conceptual structures: entity-relationship diagrams

– Activities and data: SADT diagrams

– Information flows: dataflow diagrams

– System operations: use case diagrams

– Interaction scenarios: event trace diagrams

– System behaviors: state machine diagrams

– Stimuli and responses: R-net diagrams

– Integrating multiple system views, multi-view spec in UML

Requirements specification & documentation: outline (2)

� Formal specification

– Logic as a basis for formalizing statements

– History-based specification


– History-based specification

– State-based specification

– Event-based specification

– Algebraic specification














Free documentation in unrestricted natural language(1)

� Unconstrained prose writing in natural language (NL) ...

☺☺☺☺ Unlimited expressiveness, communicability, no training needed

�� Prone to many of the spec errors & flaws (cf. Chap.1): ambiguities,noises, forward references, remorse, unmeasurable statement andopacity.

��


RememberRemember ::

�� NoiseNoise: RD item yielding no information on any problem world feature (Variant:

uncontrolled redundancy)

�� ForwardForward referencereference: RD item making use of problem world features not defined

yet

�� RemorseRemorse: RD item stating a problem world feature lately or incidentally


� Unconstrained prose writing in natural language (NL) ...

☺☺☺☺ Unlimited expressiveness, communicability, no training needed

�� Prone to many of the spec errors & flaws (cf. Chap.1): ambiguities,noises, forward references, remorse, unmeasurable statement andopacity.

��


RememberRemember ::

�� OpacityOpacity: RD item whose rationale, authoring or dependencies are invisible

�� AmbiguityAmbiguity: RD item allowing a problem world feature to be interpreted in

different ways

�� UnmeasurabilityUnmeasurability: RD item stating a problem world feature in a way precluding

option comparison or solution testing


� In particular, ambiguitiesambiguities are inherent to NL; can be harmful

“Full braking shall be activated by any train that receives an outdatedacceleration command oror that enters a station block at speed higherthan X m.p.h. andand forfor whichwhich the preceding train is closer than Y yards.”

��


The safety-critical requirement might be interpreted in two ways.In case of a train entering a station block too fast:

1. The full braking to be activated when an outdated commandis received or when the preceding train is too close

2. The full braking to be activated in a case where thepreceding train is too close


� Frequent confusions among logical connectives in NL

– e.g. case analysis:

��


– e.g. case analysis:people write If Case1 then <Statement1>

or if Case2 then <Statement2> (amounts to true!)

instead If Case1 then <Statement1>and if Case2 then <Statement2>














Disciplined documentation in structured NL

� Solution to overcome the problems with free documentationin unrestricted natural language:

− Follow local rules: how statements should be written in natural

��


− Follow local rules: how statements should be written in natural

language , and

− Follow global rules: how the requirements document should beorganized

Disciplined documentation in structured NL:local rules on writing statements

� Local rules on writing statements:

− Use stylisticstylistic rulesrules for good NL spec

− Use decisiondecision tablestables for complex combinations of conditions

��


− Use standardized statementstatement templatestemplates


A. Use stylistic rulesstylistic rules for good NL spec, e.g.

− Identify who will read this; write accordingly

− Say what you are going to do before doing it

− Motivate first, summarize after

− Make sure every concept is defined before use

− Keep asking yourself: “Is this comprehensible? Is this enough?

��


− Keep asking yourself: “Is this comprehensible? Is this enough?Is this relevant?”

− Never more than one req, assumption, or dom prop in a singlesentence. Keep sentences short.

− Use “shall” for mandatory, “should” for desirable prescriptions

− Avoid unnecessary jargon & acronyms

− Use suggestive examples to clarify abstract statements

− Supply diagrams for complex relationships among items


A. Use stylistic rulesstylistic rules for good NL spec, e.g.

��

− Annotate text with diagrams to express complex relationships

among them

− Use tables to collect related facts

−


− Avoid complex combinations of conditions with nested orambiguously associated conditions

− Introduce figures to provide visual overviews and emphasize keypoints

Disciplined documentation in structured NL:local rules on writing statements (2)

B. Use decision tablesdecision tables for complex combinations of conditions

Train receives outdated acceleration command T T T T F F F F

Train enters station block at speed ≥ X mph T T F F T T F F

Preceding train is closer than Y yards T F T F T F T F

Full braking activated X X X

input ifif-conditions binary filling with truth values

��


Full braking activated X X XAlarm generated to station computer X X X X

output thenthen-conditionsone case = AND-combination

� Systematic, simple, additional benefits ...

– Completeness and redundancy check: 22NN columns required for full table . If the number is less than 22N N there is incompleteness, and if greater than 22N N there is redundant

Disciplined documentation in structured NL:local rules on writing statements (2)

B. Use decision tablesdecision tables for complex combinations of conditions

Train receives outdated acceleration command T T T T F F F F

Train enters station block at speed ≥ X mph T T F F T T F F

Preceding train is closer than Y yards T F T F T F T F

Full braking activated X X X

input ifif-conditions binary filling with truth values

��


Full braking activated X X XAlarm generated to station computer X X X X

output thenthen-conditionsone case = AND-combination

� Systematic, simple, additional benefits …

– Provide acceptance test data for free : each column defines aclass of input-output test data (cause-effect coverage on black-box testing)

C. Use standardized statement templatesstatement templates to present various types of statements in standardize form

IdentifierIdentifier --for unique reference through the RD. it might be asuggestive name or a hierarchically numbered identifier toexpress the decomposition of statement Si to Sij

CategoryCategory --to make it clear whether the statement is functional or

quality req, assumption, domain property, definition, scenario

Disciplined documentation in structured NL:

local rules on writing statements (3)

��


quality req, assumption, domain property, definition, scenario

example, ...

SpecificationSpecification --statement formulation according to stylistic rules

FitFit criterioncriterion --helps to determine whether the statement is

satisfactorily satisfied in the system-to-be. For measurability (see

next slide)

SourceSource --from which the statement was elicited. For traceability to

elicitation sources


local rules on writing statements (3)

��

RationaleRationale --of the statement. For better understanding &

traceability


InteractionInteraction --positive or negative interactions with other

statements. In contribution to or conflict with other statements

PriorityPriority level --For comparison & prioritization

StabilityStability, CommonalityCommonality levels --For change management

Fit criteria make statements measurable

� Complement statements by quantifying the extent to which theymust be satisfied [Robertson, 1999]

� Especially important for measurability of NFRs

��

SpecSpec:: The scheduled meeting dates shall be convenient to participants


SpecSpec:: Info displays inside trains shall be informative & understandable

FitFit criterioncriterion: A survey after 3 months of use should reveal that at least 75%of travelers found in-train info displays helpful for finding their connection

SpecSpec:: The scheduled meeting dates shall be convenient to participants

FitFit criterioncriterion: Scheduled dates should fit the diary constraints of at least90% of invited participants in at least 80% of cases


global rules on organizing the RD

Global rules to organize document:

�� GroupingGrouping rules

Global templatestemplates for standardizing the RD structure


� Global templatestemplates for standardizing the RD structure


global rules on organizing the RD

A.A. GroupingGrouping rules: Put in same section all items related tocommon factor ...

– system objective

– system component

– task


– task

– conceptual object

– software feature

– ...

B. Global templatestemplates for standardizing the RD structure (i.e.,

IEEE Std-830)

– domain-specific, organization-specific, company-specific

IEEE Std-830 template for organizing the RD

1. Introduction

1.1 RD purpose

1.2 Product scope

1.3 Definitions, acronyms, abbreviations

1.4 References

1.5 Overview sw-environment boundary:

glossary of terms

domain, scope, purposeof system-to-be

elicitation sources


2. General Description

2.1 Product perspective

2.2 Product functions

2.3 User characteristics

2.4 General constraints

2.5 Assumptions & Dependencies

2.6 Apportioning of requirements

3. Specific Requirements

sw-environment boundary:interfaces with users, devices, other sw

functionalities of software-to-be

assumptions about users

development constraints(hw limitations, implem platform, ...)

environment assumptions(subject to change)

Which RE is optional, deferrable reqs

IEEE Std-830 template for organizing the RD (2)

33.. Specific RequirementsSpecific Requirements3.1 Functional requirements

3.2 External interface reqs

3.3 Performance reqs

3.4 Design constraints

3.5 Software quality attributes

NFRs: development reqs

NFRs: interoperability

alternative templates for alternative templates for specific types of systemspecific types of system

NFRs: time/space performance


3.5 Software quality attributes

3.6 Other requirements

Appendices

Index

NFRs: quality reqs

NFRs: security, reliability, maintainability

� Another variant: of IEEE Std-830: VOLERE template [Robertson,1999]– Make explicit distinction between users, clients and other stakeholders

– Provide sections for domain properties, costs, risks, developmentworkplan, ...

☺☺☺☺ addresses some of the problems with free documentation inunrestricted natural language

☺☺☺☺ preserve expressive power and high accessibility

provides guidance in writing documentation and ensures document

��Disciplined documentation in structured NL


☺☺☺☺ provides guidance in writing documentation and ensures documentstandardization

�� absence of formalized information still precludes any form ofautomated analysis














Use of diagrammatic notations

� To complement or replace NL prose

� Dedicated to specificspecific aspectsaspects of the system (as-is or to-be)

� Graphical: to ease communication, provide overview

� Semi-formal ...

– Declaration of items in formal language (syntax, semantics)


– Declaration of items in formal language (syntax, semantics)

=> surface checks on RD items, machine-processable

– Informal spec of item properties in NL

�� ThisThis chapterchapter: typical sample of frequently used diagrams,showing complementarities

�� PartPart 22: in-depth study + systematic method for buildingcomplex models using integrated set of diagrams

Use of diagrammatic notations

� Why we use the semi-formal notations(i.e., diagrammatic

notation) that introduce in this chapter for documenting

specific aspects of the system-to-be in the RD:

– They support abstractions that are relevant to RE


– They support abstractions that are relevant to RE

– Cover complementary aspects to be documented in RD

– Fairly standard and widely used

– Significant portion of them is standardize in the UMLsubset




� Use of diagrammatic notations– System scope: context, problem, frame diagrams


– System scope: context, problem, frame diagrams– Conceptual structures: entity-relationship diagrams








System scope: context, problem and frame diagrams

� First type of diagram allows us to:

‘Delimit the problem world by declaring its components and theirshared phenomena’

� Components can annotated by NL specifications of requirementsthat constraint them or refer to them


� Componenets include : business units or people playing specificrules, physical device including sensors and actuators, softwarecomponents, data repositories, communication infrastructure,…

� Phenomena at their interface can be: events, messages,transmitted date,..

Phenomena are controlled by some component and monitored by others

System scope: context diagrams(1)

� Declare system componentscomponents & their interfacesinterfaces [DeMarco ’78]

=> --system structure

--what is in system, what is not

--environment of each component: set of neighborscomponents with which it interact, their respective


components with which it interact, their respectiveinterfaces

--nodes represent system components and edge representconnections through shared phenomena declared by thelabels

System scope: context diagrams(2)

HandbrakeController

Carhandbrake.Sw

motor.Regime

pedalPushed

buttonPressed


Driversystem component

connection through sharedphenomenon (data, event)

Driver controll the phenomenawhile HandbrakerController

monitor it

System scope: problem diagrams(1)

� More detailed form of context diagram: highlights...

– the MachineMachine among system components

– for shared phenomenon: who controlscontrols it, who monitorsmonitors it

– Which components are affected by which requirementsrequirements,

– Notation:

–


–nameMachine we need to build

nameComponent to be designed (like a repository)

This component controls the phenomena in the declared set This component! { }


– Notation (con.):

Requirement


Connect requirement to a component. Means requirement

refers to it

The requirement constrains a component


� More detailed form of context diagram: highlights...

– the MachineMachine among system components

– for shared phenomenon: who controlscontrols it, who monitorsmonitors it

– Which components are affected by which requirementsrequirements,

CarHC ! handbrake.Sw

C ! motor.RegimeHandbrakeController


Driver

CarC ! motor.Regime

DR ! {pedalPushed, buttonPressed}

Handbrake shall be ... activated if the brake button is pressed,released if the acceleration pedal is pushed

{pedalPushed, buttonPressed}

{BrakeActivation, BrakeRelease}

controlling component

Controller

Machine

constrains

refers to

requirement

System scope: frame diagrams

� Capture frequent problem patternsproblem patterns

– typed phenomena (CC: causal, EE: event, YY: symbolic)

– typed components (CC: causal, BB: biddable, XX: lexical)

� E.g. Simple Workpieces, Information Display, Commanded Behavior(see book)

Commanded


Commanded Behavior frameCommanded Behavior frame

Control Machine

Operator

Commanded World

Component

CM ! C1

CWC ! C2

OP! E4

Command-basedcontrol rules

E4

C3

B

C

biddable

causal

event

Reusing problem frames

� Candidate system-specific problem diagram can be obtained by instantiation, in matching situations (cf. Chap. 2)

– under typing constraints

– mutiple frames reusable for same problem world

CarHC ! handbrake.SwHandbrake


InstantiatedInstantiatedCommandedCommanded BehaviorBehavior frameframe

Driver

CarC ! motor.Regime

DR ! {pedalPushed, buttonPressed}

Handbrake shall be activated if the brake button is pressed,released if the acceleration pedal is pushed

{pedalPushed, buttonPressed}

{BrakeActivation, BrakeRelease}

Controller














Conceptual structures: entity-relationship diagrams(1)

� ER diagrams are a classical notation for declaring conceptualitems and their structural properties

� System-to-be and system-as-is involve conceptual items thatare generally structured from finer items and inter-relatedwith each other


� Class diagram notation found in the UML standard is aculminated variant of ER diagram

� ER diagram is made from three core constructs:

-entities

- attributes

-relationship

Conceptual structures: entity-relationship diagrams(2)

�� EntityEntity: class of concept instances ...– having distinct identities– sharing common features (attributes, relationships)

e.g. Meeting, Participant

� N-ary relationshiprelationship: feature conceptually linking N entities,each playing a distinctive role (N ≥ 2)


each playing a distinctive role (N 2)

–– MultiplicityMultiplicity, one one side: min & max number of entity instances,on this side, linkable at same time to single tuple of entityinstances on the other sides

e.g. Invitation linking Participant and Meeting

�� AttributeAttribute: is an intrinsic feature of an entity or a relationship

(like association class) regardless of others– has range of values

e.g. Date of Meeting

Entity-relationship diagram: example

entity

attribute

binary relationshiprole

specialization


attributes ofrelationship

A meeting invites at least 1 up toan arbitrary number of participants

Entity-relationship diagrams (3)

� Entity specializationspecialization: subclass of concept instances, furthercharacterized by specific features (attributes, relationships)

– by default, inherits attributes & relationships from superclass

– rich structuring mechanism for factoring out structuralcommonalities in superclasses

e.g. ImportantParticipant, with specific attribute Preferences

Inherits relationships Invitation, Constraints, attribute Address,


Inherits relationships Invitation, Constraints, attribute Address,Name and Email

� Diagram annotationsannotations: to define elements precisely

– essential for avoiding spec errors & flaws

e.g. annotation for Participant:

“Person expected to attend the meeting, at least partially, under somespecific role. Appears in the system when the meeting is initiated anddisappears when the meeting is no longer relevant to the system”


� Multiplicities may capture requirements oror domain properties. Nodistinction between prescriptive & descriptive

e.g.,

the Loan relationship between a Patron and bookCopy entities in the Library system


A 0..m multiplicity on the bookCopy side would capture aprescriptive statement that:

« A patron may not borrow more than max book copy at a time »

Whereas 0..1 multiplicity on the Patron side would capture thedescriptive statement that:

« A book cannot physically be borrowed by more than one patron at a time »


�� Practical difficulty of buiding adequate ER diagrams for complexapplications

�� Which conceptual item should appear in an ER diagram, which oneshould not and why

�� When a conceptual item is felt necessary, should it represented


�� When a conceptual item is felt necessary, should it representedas: entity, relationship or an attribute?














Activities and data: SADT diagrams(1)

� Capture activities & data in the system (as-is or to-be)

� SADT(structured analysis and design technique) is a graphicallanguage that provides two kinds of diagram that are inter-related:

�� ActigramActigram: declare activities by 1) their input/output data andinterconnected them through 2)data dependency links

– East →→ : input data; West →→ : output data


– North →→ : controlling data/event; South →→ : processor

– Activities refinable into sub-activities

�� DatagramDatagram: declare system data by 1) theirproducing/consuming activities and interconnected themthrough 2) control dependency links

– East →→ : producing activity; West →→ : consuming activity

– North →→ : validation activity; South →→ : needed resources

– Data refinable into sub-data

Activities and data: SADT diagrams(2)

� Data-activity duality:

– data in actigram must appear in datagram

– activities in datagram must appear in actigram


SADT diagrams: actigram example

meeting Constraints

Handling Constraints

Ask

meeting Request

dateRange

dateRange

copyInitiator allConstraints

Received

dateRange Deadline meeting Request

refinement

activity


Ask Constraints

Return Constraints

copyInitiator

constraint Request

Received

Scheduler

Participant Merge Constraints

Request

meeting Constraints

individual Constraints

Scheduler

input data

output dataprocessor

controlling data

Sub-activities

SADT diagrams: actigram example

meetingConstraints

Handling Constraints

Ask

meetingRequest

dateRange

dateRange

copyInitiatorallConstraints

Received

dateRange DeadlinemeetingRequest

refinement

activity


AskConstraints

ReturnConstraints

copyInitiator

constraintRequest

Received

Scheduler

Participant MergeConstraints

Request

meetingConstraints

individualConstraints

Scheduler

input data

output dataprocessor

controlling data

Sub-activities

SADT diagrams: datagram example

MergeConstraints meeting

Constraints

constraintsRepository

CheckValidity

PlanMeeting

producing activity

controlling activity consuming activity

Resource as memory data


RepositoryResource as memorysupport

� Consistency/completeness rules checkable by tools

– Every activity must have an input and an output

– All data must have a producer and a consumer

– I/O data of an activity must appear as I/O data of subactivities

– Every activity in a datagram must be defined in an actigram, ...

data

SADT diagrams: datagram example

Merge Constraints meeting

Constraints

constraints Repository

Check Validity

Plan Meeting

producing activity

controlling activity consuming activity

Resource as memory data


Repository Resource as memory

support

The tool would detect that a CheckValidity activity is missingin the refining actigram---the latter rule is violated

data








– Information flows: dataflow diagrams(DFD)






Information flows: dataflow diagrams(1)

� Capture system operations linked by data dependencies

– simpler but less expressive than actigrams

� Operation = data transformation activity

� Input, output links = data flows


– operation needs data flowing in to produce data flowing out

(≠≠≠≠ control flow !)

� The rules according to which an operation transforms input

data into output data are specified by:

– by an annotation (structured NL)

–– OrOr another DFD (operation refinement, cf. SADT)


� The origin and termination of a flow can be specified as

System components or data repositories

Consistency/completeness rules checkable by tools, cf. SADT


� Consistency/completeness rules checkable by tools, cf. SADT

�DFD captures data dependencies among operation withoutprescribing any ordering of events or sequencing of operations

☺The simplicity of DFD diagrams explains their popularity for thecommunication and documentation of operational aspects of the



communication and documentation of operational aspects of thesystem in a structured, summarized way

Dataflow diagram: example

Initiator

AskConstraints

copyOfconstraints

RequestmeetingRequest

Participant

meetingNotificationCheck

Request

invalidRequest

validRequest operation

input data flow output data

flow


constraintRequestmeeting

Constraints

individualConstraints

CollectConstraints

Participant

MergeConstraints

participantConstraints

DetermineSchedule

Request

data repositorysystem component














System operations: use case diagrams

� Capture operations to be performed by a system component &interactions with other components

– yet simpler, provide functional outline of the system-to-be... but

vague

– Operation and components are just captures by their name

– What interaction consist of is unclear (ET in next part can use)


– What interaction consist of is unclear (ET in next part can use)

– The semantic of Include & extend is not very clear either

– to be made precise by annotations, interaction scenarios, ...

– introduced in UML to replace DFDs

� Structuring mechanisms ...

– <<include>>: to specify “suboperation”

– <<extend>> + precondition: to specify “variant” operationin exception case

Use case diagram for meeting scheduler: example

CollectConstraints

Check Request

InitiatorParticipant

<<extend>>Unauthorized

Deny Request

AskConstraints

operation interactionenvironment component

variantoperation


DetermineSchedule

Constraints

Scheduler

ConflictResolver

<<include>>

Deny Request

MergeConstraints

ResolveConflictsParticipant

software component

variantoperation

suboperation

every thing good in UML is not new,

every thing new in UML is not good operation performer














Interaction scenarios: event trace diagrams(1)

� Complete the outline view provided by a use case diagram

� Capture positive scenarios by sequences of interactions amonginstances of system components (cf. Chap. 2)

– variants: MSC (ITU), sequence diagrams (UML)

� Parallel composition of timelines

– Each timeline is associated with the behavior of a


– Each timeline is associated with the behavior of acomponent instance in the scenario

� Pairwise directed interactions down timelines

– information transmission through event attributes

� Interaction event synchronously controlled by source instance& monitored by target instance

– total order on events along timeline (event precedence)

– partial order on all diagram events

Event trace diagram: example

SchedulerInitiator ParticipantmeetingRequest

(dateRange, withWhom)

OK-request? constraints

! constraints

interaction event attribute component instance


! constraints

OK-constr

scheduleDetermination

notification (date, location)notification (date, location)

controlsinteraction

monitorsinteraction

self-interactiontimeline

�ET diagrams can represent the dynamic of system components butonly very partially

�A ET timeline specifies a particular bevahior of a specific componentinstance along a partial sequence of interactions

e.x.,

the example diagram does not tell us what should happen if themeeting request is invalid

Interaction scenarios: event trace diagrams(2)


meeting request is invalid

This diagram refers to a specific Participant instance; it doesnot tell us that the constraints of all Participant instancesinvited to the meeting should be available before the meetingdate is determined

nor, What should happen in the case of conflicting constraintsamong multiple Participant instances

�state information is left implicit in ET diagrams














System behaviors: state machine diagrams(1)

� Capture the admissible behaviors of system components

�� BehaviorBehavior of component instance =

sequence of state transitions for the items it controls

� SM statestate = set of all situations where some variablecharacterizing the controlled item always has the same value


characterizing the controlled item always has the same valueregardless of other characterizing variables, whose values maydiffer from one situation in this set to the other

these variables may correspond to attributes or relationships controlled by the component and declared in an associated ER

diagram


� SM statestate (con.)

– e.g. state MeetingScheduled corresponds to the set of all

situations where the meeting has determined value for its

attributes Date and Location regardless of other characterizing

variables, such as who is invited to that meeting

– e.g. state doorsOpen for train controlled by train controller


– e.g. state doorsOpen for train controlled by train controller

corresponds to the set of all situations where the controlled

attribute DoorsState has the value ‘open’ regardless of other

train attributes such as Speed, which might be ‘0 m.p.h’ in one

situation of this set and ‘30 m.p.h’ in another

–– InitialInitial, finalfinal states = states where item appears, disappears

– States may have some duration


� SM statestate transitiontransition: caused by associated event

–– ifif the controlled item is in source state and event ev occursthenthen this item moves to target state

– Events are instantaneous phenomena

– They may correspond to external stimuli from thecomponent’s environment (e.g., meetingRequest event)


component’s environment (e.g., meetingRequest event)

– They may corresponds to applications of some operation bythe component (e.g., the ScheduleDetermine operation)

Example of state machine diagram:meeting controlled by a meeting scheduler

meetingRequest

OK-request

GatheringMeeting

Data

[All available]

[Unauthorized] RequestDenied

KO-request

ValidatingMeeting

Data

[Authorized]

initial state final state

statetransition


notification

[Noconflicts]

ConstraintsRequested

Planning

Resolving

MeetingNotified

[All available]

[Conflicts]

MeetingScheduled

weakeningRequest


state

event

guard

transition

State machine diagrams: transitions and guards(1)

� Event occurrence is a sufficient condition for transition firing

– Event can be external stimulus (e.g. meetingRequest) or

application of internal operation (e.g. determineSchedule)

� Guard = necessary condition for transition firing

– Item gets to target state ......


– Item gets to target state ......

ifif item is in source state and event ev occurs and and only if only if guard condition is true

– Guarded transition with no event label: fires as soon as guard gets true (= trigger condition)

� Non-deterministic behavior: multiple outgoing transitions with same event and no or overlapping guards

– often to be avoided for safety, security reasons

State machine diagrams: transitions and guards(2)

� Non-deterministic behavior: (con.)

– often to be avoided for safety, security reasons


Scenarios and state machines(1)

� SM tracetrace = sequence of successive SM states up to some point

– e.g. < GatheringMeetingData, RequestDenied >

– always finite, but SM diagram may have infinitely many traces

� A SM diagram generalizesgeneralizes ET diagram scenarios:


� A SM diagram generalizesgeneralizes ET diagram scenarios:

– from specific instances to any component instance

– trace coverage: SM traces include ET traces, and (many) more

e.g. scenario/SM trace from previous slides:

< ValidatingMeetingData; ConstraintsRequested; Planning;

MeetingScheduled; MeetingNotified >

SchedulerInitiator ParticipantmeetingRequest

(dateRange, withWhom)

OK-request? constraints

! constraints

Scenarios and state machines (2)


OK-constr


notification (date, location)notification (date, location)

Concurrent behaviors and state charts(1)

� Components often control multiple items in parallel

� Problems with flat SM diagram ...

– N item variables each with M values => MN states !

– Possible values for the variable DoorsState are ‘open’,‘openinEmergency’ and ‘closed’


‘openinEmergency’ and ‘closed’

– Possible values for the variable MovementState are‘stopped’, ‘accelerating’’ and ‘decelerating’

– Two variables DoorsState and MovementState and eachhas three values; MN states = 32 to present all possiblecombinations of values

– same SM state mixing up different variables

Concurrent behaviors and state charts(2)

�� StatechartStatechart = parallel composition of SM diagrams [Harel, 1987]

– one per variable evolving in parallel

– statechart statestate = aggregation of concurrent substates

– from MN explicit SM states to M ×××× N statechart states !


– from MN explicit SM states to M ×××× N statechart states !

� Statechart trace = sequence of successive aggregated SM states up to some point

� Interleaving semantics: for 2 transitions firing in same state, one is taken after the other (non-deterministic choice)

Statechart example (1)

doorsClosed doorsOpenopening

closing

[speed = 0]

[speed = 0]

parallelcomposition

variabledoorsState

variabletrainSpeed


� Trace example:< (doorsClosed, trainStopped); (doorsClosed, trainMoving);

(doorsOpen, trainStopped); (doorsOpen, trainMoving) >

trainStopped trainMovingtrainStart

[doorsState = ‘closed’]

variabletrainSpeed

Statechart example(2)

� Model-checking tools can generate counterexample traces leading to violation of desired property

E.g., E.g.,


If we dont have this guard

doorsClosed doorsOpen

opening

closing

[speed = 0]

tra inStopped trainMoving

trainStart

[speed = 0]




opening

closing

[speed = 0]


trainStart

[speed = 0]



opening

closing

[speed = 0]


trainStart

[speed = 0]


1111 2222



opening

closing

[speed = 0]


trainStart

[speed = 0]



opening

closing

[speed = 0]


trainStart

[speed = 0]


3333 4444

��



Provide convenient notation for specifying the system’s dynamics

�Identifying the right states and the right level of granuality forstates and transitions can be difficult

�Diversity of semantics of different Sm notation-even sometimes

State machine diagram

☺


�Diversity of semantics of different Sm notation-even sometimesof the same notation














Stimuli and responses: R-net diagrams(1)

� Capture all required responses to single stimulus [Alford, 1977]

– chain of response operations to be performed by a systemcomponent

– operation may generate stimuli for other R-nets

– Operation in R-net may evaluate data or condition, produce

an output, generate events to be considered as stimuli in R-


an output, generate events to be considered as stimuli in R-

net for other components

� Decision points, operation application under conditions

� Good for visualizing ...

– answers to WHATWHAT IFIF ?? Questions (i.e., questions that thestakeholders might ask about external stimuli)

– required software reactions to environment events


� R-net provides a partial, operational view of a full SM; itfocuses on the required responses to one specific input stimulus



meetingRequest

OK-request

GatheringMeeting

Data

[All available]

[Unauthorized] RequestDenied

KO-request

ValidatingMeeting

Data

[Authorized]

mac

hine


notification

[Noconflicts]

ConstraintsRequested

Planning

Resolving

MeetingNotified

[All available]

[Conflicts]

MeetingScheduled

weakeningRequest


C.f.

stat

em

achi

ne

R-net diagram: example of

Check that initiator is authorized

meetingRequest

begininput stimulus

precedence

response operation


end

Check dateRange, withWhom

Ask revised meeting dataAsk constraints

Deny meeting

OK KO

end

end

Authorized Unauthorized

decision point














Integrating multiple system views

� Diagrams of different types cover different, complementary views ofthe system (as-is or to-be)

– components & interfaces, conceptual structures, operations,flows, interaction scenarios, behaviors, ....

� Overlapping aspects => integration mechanism needed for ensuringcompatibility & complementarily among diagrams


compatibility & complementarily among diagrams

� Standard mechanism for integrating diagrams of different types:interinter--viewview consistencyconsistency rulesrules the specifier should meet

– cf. static semantics rules enforced by compilers (static semanticschecks automated by programming language compiler)

“every used variable must be declared”

“every declared variable must be used”, ...

– can be used for inspection checklists

Integrating multiple system views

� Standard mechanism : interinter--viewview consistencyconsistency rulesrules (con.)

– enforceable by tools: means check automatically by query tools ona multi_view specification DB

– constrain diagram evolution- provide explicit constrains that are


– constrain diagram evolution- provide explicit constrains that areto be maintained when changes are made to items to which theyrefer

Inter-view consistency rules: examples

� Every component & interconnection in a problemproblem diagramdiagram mustbe further specified in an ETET diagramdiagram

� Every shared phenomenon in a problemproblem diagramdiagram must appear asevent in an ETET diagramdiagram or as entity, attribute, or relationship inan ERER diagramdiagram


� Every data in a flow or repository of a DFDDFD diagramdiagram must bedeclared as entity, attribute, or relationship in an ERER diagramdiagram

� Every state in a SMSM diagramdiagram must correspond to some value forsome attribute or relationship in an ERER diagramdiagram

� Every interaction event in an ETET scenarioscenario must appear in acorresponding SMSM diagramdiagram

Multi-view specification in UML

The Unified Modeling Language (UML) has standardized notations

for diagrams relevant to RE

�� Class diagramsClass diagrams: ER diagrams for structural view

�� Use case diagramsUse case diagrams: outline of operational view


�� Use case diagramsUse case diagrams: outline of operational view

�� Sequence diagramsSequence diagrams: ET diagrams for scenarios

�� State diagramsState diagrams: SM diagrams for behavioral view

Further studied in Chaps. 10-13 in a systematic method for building multi-view models

Diagrammatic notations: pros & cons(1)

� Formal declaration of different system facets+ informal annotations of properties for higher precision

� Graphical declaration for formal part =>

☺☺☺☺ overview & structuring of important aspects

☺☺☺☺ easy to understand, communicate

☺☺☺☺ surface-level analysis, supported by tools (e.g. query engines)


� Semi-formal specification =>

� language semantics may be vague (different interpretations)-Easy to use ‘box-and-arrow’ semantics of graphical notations inthe wrong way. The same specification can be interpreted indifferent ways by different people

� limited forms of analysis

� functional and structural aspects only- there are other importantaspect like system objective, non-functional req., assumptionabout environment,…that should be considered

Diagrammatic notations: pros & cons(2)

� Semi-formal specification (con.) =>

� only surface-level aspects formalized, not item properties

e.g.,

what are the invariant properties of an entity or arelationship?

What is the precise meaning of an SM state beyond its


What is the precise meaning of an SM state beyond itsname and incoming/outgoing event labels?

What is the precise effort of the application of anoperation?

⇒ The deep semantics of RD items has to be stated formally

⇒ formal specification needed for mission-critical aspects

Requirements specification & documentation (1) :

summary� Free documentation in unrestricted NL is subject to errors & flaws

� Disciplined documentation in structured NL is always necessary

– Local rules on statements: stylistic rules, decision tables, statement templates

– Global rules on RD organization: grouping rules, structure templates

� Diagrams for graphical, semi-formal spec of complementary aspects

–– System scopeSystem scope: context, problem, frame diagrams


–– System scopeSystem scope: context, problem, frame diagrams–– Conceptual structuresConceptual structures: entity-relationship diagrams

–– Activities and dataActivities and data: SADT diagrams

–– Information flowsInformation flows: dataflow diagrams

–– System operationsSystem operations: use case diagrams

–– Interaction scenariosInteraction scenarios: event trace diagrams

–– System behaviorsSystem behaviors: state machine diagrams

–– Stimuli and responsesStimuli and responses: R-net diagrams

– Integrating multiple viewsmultiple views, multi-view spec in UML

Requirements specification & documentation (2) :

formal specification

� Logic as a basis for formalizing statements

� History-based specification

State-based specification


� State-based specification

� Event-based specification

� Algebraic specification

Documents

Fundamentals of RE - Zohoiau-tnb.zohosites.com/files/Slides 04A - Requirements...Requirements specification & documentation: outline Free documentation in unrestricted natural language