View
14
Download
0
Category
Preview:
Citation preview
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
3www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
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)
Specification & documentation:as introduced in Chapter 1 ...
�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
4www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
- 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
Specification & documentation:as introduced in Chapter 1 ...
� Organization of the statements in a coherent structure (see
chapter 1)
� Documentation in a form understandable by all parties
5www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
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
6www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
– 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
7www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
– History-based specification
– State-based specification
– Event-based specification
– Algebraic specification
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
8www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
– 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
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.
����
9www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
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
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.
����
10www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
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
Free documentation in unrestricted natural language(2)
� 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.”
����
11www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
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
Free documentation in unrestricted natural language(3)
� Frequent confusions among logical connectives in NL
– e.g. case analysis:
����
12www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
– 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>
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
13www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
– 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
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
����
14www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
− 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
����
15www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
− Use standardized statementstatement templatestemplates
Disciplined documentation in structured NL:local rules on writing statements
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?
����
16www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
− 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
Disciplined documentation in structured NL:local rules on writing statements
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
−
17www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
− 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
����
18www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
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
����
19www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
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)
����
20www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
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
Disciplined documentation in structured NL:
local rules on writing statements (3)
����
RationaleRationale --of the statement. For better understanding &
traceability
21www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
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
22www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
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
Disciplined documentation in structured NL:
global rules on organizing the RD
Global rules to organize document:
�� GroupingGrouping rules
Global templatestemplates for standardizing the RD structure
23www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
� Global templatestemplates for standardizing the RD structure
Disciplined documentation in structured NL:
global rules on organizing the RD
A.A. GroupingGrouping rules: Put in same section all items related tocommon factor ...
– system objective
– system component
– task
24www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
– 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
25www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
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
26www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
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
27www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
☺☺☺☺ provides guidance in writing documentation and ensures documentstandardization
���� absence of formalized information still precludes any form ofautomated analysis
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
28www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
– 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
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)
29www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
– 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
30www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
– 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
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
31www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
– System scope: context, problem, frame 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
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
32www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
� 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
33www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
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
34www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
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:
–
35www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
–nameMachine we need to build
nameComponent to be designed (like a repository)
This component controls the phenomena in the declared set This component! { }
System scope: problem diagrams(2)
– Notation (con.):
Requirement
36www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
Connect requirement to a component. Means requirement
refers to it
The requirement constrains a component
System scope: problem diagrams(3)
� 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
37www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
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
38www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
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
39www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
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
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
40www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
– System scope: context, problem, frame 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
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
41www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
� 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)
42www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
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
43www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
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,
44www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
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”
Entity-relationship diagrams (4)
� 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
45www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
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 »
Entity-relationship diagrams (5)
���� 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
46www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
���� When a conceptual item is felt necessary, should it representedas: entity, relationship or an attribute?
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
47www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
– 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
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
48www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
– 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
49www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
SADT diagrams: actigram example
meeting Constraints
Handling Constraints
Ask
meeting Request
dateRange
dateRange
copyInitiator allConstraints
Received
dateRange Deadline meeting Request
refinement
activity
50www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
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
51www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
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
52www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
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
53www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
Repository Resource as memory
support
The tool would detect that a CheckValidity activity is missingin the refining actigram---the latter rule is violated
data
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
54www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
– Conceptual structures: entity-relationship diagrams
– Activities and data: SADT diagrams
– Information flows: dataflow diagrams(DFD)
– 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
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
55www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
– 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)
Information flows: dataflow diagrams(2)
� The origin and termination of a flow can be specified as
System components or data repositories
Consistency/completeness rules checkable by tools, cf. SADT
56www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
� 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
Information flows: dataflow diagrams(3)
57www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
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
58www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
constraintRequestmeeting
Constraints
individualConstraints
CollectConstraints
Participant
MergeConstraints
participantConstraints
DetermineSchedule
Request
data repositorysystem component
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
59www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
– 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
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)
60www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
– 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
61www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
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
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
62www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
– System scope: context, problem, frame 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
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
63www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
– 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
64www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
! 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)
65www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
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
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
66www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
– System scope: context, problem, frame 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
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
67www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
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
System behaviors: state machine diagrams(2)
� 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
68www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
– 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
System behaviors: state machine diagrams(3)
� 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)
69www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
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
70www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
notification
[Noconflicts]
ConstraintsRequested
Planning
Resolving
MeetingNotified
[All available]
[Conflicts]
MeetingScheduled
weakeningRequest
scheduleDetermination
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 ......
71www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
– 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
72www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
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:
73www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
� 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)
74www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
OK-constr
scheduleDetermination
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’
75www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
‘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 !
76www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
– 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
77www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
� 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.,
78www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
If we dont have this guard
doorsClosed doorsOpen
opening
closing
[speed = 0]
tra inStopped trainMoving
trainStart
[speed = 0]
[doorsState = ‘closed’]
Statechart example(3)
doorsClosed doorsOpen
opening
closing
[speed = 0]
tra inStopped trainMoving
trainStart
[speed = 0]
[doorsState = ‘closed’]
doorsClosed doorsOpen
opening
closing
[speed = 0]
tra inStopped trainMoving
trainStart
[speed = 0]
[doorsState = ‘closed’]
1111 2222
79www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
doorsClosed doorsOpen
opening
closing
[speed = 0]
tra inStopped trainMoving
trainStart
[speed = 0]
[doorsState = ‘closed’]
doorsClosed doorsOpen
opening
closing
[speed = 0]
tra inStopped trainMoving
trainStart
[speed = 0]
[doorsState = ‘closed’]
3333 4444
����
Statechart example(4)
80www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
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
☺
81www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
�Diversity of semantics of different Sm notation-even sometimesof the same notation
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
82www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
– System scope: context, problem, frame 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
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-
83www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
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
Stimuli and responses: R-net diagrams(2)
� R-net provides a partial, operational view of a full SM; itfocuses on the required responses to one specific input stimulus
84www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
Stimuli and responses: R-net diagrams(2)
meetingRequest
OK-request
GatheringMeeting
Data
[All available]
[Unauthorized] RequestDenied
KO-request
ValidatingMeeting
Data
[Authorized]
mac
hine
85www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
notification
[Noconflicts]
ConstraintsRequested
Planning
Resolving
MeetingNotified
[All available]
[Conflicts]
MeetingScheduled
weakeningRequest
scheduleDetermination
C.f.
stat
em
achi
ne
R-net diagram: example of
Check that initiator is authorized
meetingRequest
begininput stimulus
precedence
response operation
86www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
end
Check dateRange, withWhom
Ask revised meeting dataAsk constraints
Deny meeting
OK KO
end
end
Authorized Unauthorized
decision point
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
87www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
– System scope: context, problem, frame 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
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
88www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
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
89www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
– 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
90www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
� 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
91www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
�� 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)
92www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
� 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
93www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
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
94www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
–– 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
95www.wileyeurope .com/college/van lamsweerde Chap.4: Requirements Specification & Documentation © 2009 John Wiley and Sons
� State-based specification
� Event-based specification
� Algebraic specification
Recommended