User Requirements Notation URN Daniel Amyot [email protected] http://www.UseCaseMaps.org/urn/ October 2002 Requirements Engineering & User Requirements Notation
Dec 14, 2015
Use
r R
equi
rem
ents
Not
atio
n
URNDaniel Amyot
[email protected]://www.UseCaseMaps.org/urn/
October 2002
Requirements Engineering & User Requirements Notation
© 2002
Page 2
User Requirements Notation
Objectives
Part I: Requirements Engineering– What is it?– A RE approach– Requirements characteristics
Part II: User Requirements Notation (URN)– Motivations and objectives– Goal-oriented Requirement Language (GRL)– Use Case Maps (UCMs)– MSC generation– Relationships with other languages– Tools
© 2002
Page 4
User Requirements Notation
You said “Requirements”?
A requirement is an expression of the ideas to be embodied in the system or application under development
Requirements engineering is the activity of development, elicitation, specification, and analysis of the stakeholder requirements, which are to be met by systems
– RE is concerned with identifying the purpose of a software system… and the contexts in which it will be used.
© 2002
Page 5
User Requirements Notation
Requirements Engineering
Requirements Engineering
Requirements Development
Requirements Management
Elicitation Analysis Specification Verification
Larry Boldt, Trends in Requirements EngineeringPeople-Process-Technology, Technology Builders, Inc., 2001
© 2002
Page 6
User Requirements Notation
About the steps…
• Requirements elicitation– Requirements discovered through consultation with
stakeholders
• Requirements analysis and negotiation– Requirements are analyzed and conflicts resolved through
negotiation
• Requirements specification– A precise requirements document is produced
• Requirements validation– The requirements document is checked for consistency
and completeness
© 2002
Page 7
User Requirements Notation
Vision and Scope Document
UserRequirements
Use Case Document
FunctionalRequirements
Software Requirements Specification
Constraints
QualityAttributes
SystemRequirements
1-7
BusinessGoals/Objectives
Adapted from Karl Wiegers, Software Requirements
A Requirements Engineering Approach
© 2002
Page 8
User Requirements Notation
So many requirements…! A goal is an objective or concern used to discover
and evaluate functional and non-functional requirements.
A functional requirement is a requirement defining functions of the system under development
A non-functional requirement is a requirement characterizing a system property such as expected performance, robustness, usability, maintainability, etc. Non-functional requirements capture business goals/objectives and product quality attributes.
A user requirement is a desired goal or function that a user and other stakeholders expect the system to achieve
© 2002
Page 9
User Requirements Notation
The Requirements Analyst Plays an essential communication role
– talks to users: application domain– talks to developers: technical domain– translates user requirements into functional requirements
and quality goals
Needs many capabilities– interviewing and listening skills– facilitation and interpersonal skills– writing and modeling skills– organizational ability
RE is more than just modeling… This is a social activity!
Karl Wiegers – In Search of Excellent Requirements
© 2002
Page 10
User Requirements Notation
(Martin & Leffinwell)
Distribution of Effort to Fix Defects
Code7% Other
10%
Design27%
Requirements56%
Code1%
Other4%
Design13%Requirements
82%
Why Manage Requirements ?
Distribution of Defects
© 2002
Page 11
User Requirements Notation
Time
Why?
What?
How?
Who?When?
If-Then
Does It?
Where?
Project Management Process
Quality Management Process
Component & Configuration Management Process
Risk Management Process
Identify Business Needs
Derive User & Functional Requirements
Design Solutions
TIME
RE Process and Related Activities
© 2002
Page 12
User Requirements Notation
Towards Good Requirements Specs!
Valid (or “correct”)– Expresses actual
requirements Complete
– Specifies all the things the system must do
– ...and all the things it must not do!
– Conceptual Completeness E.g. responses to all
classes of input
– Structural Completeness E.g. no TBDs!!!
Consistent– Doesn’t contradict itself
(satisfiable)– Uses all terms consistently– Note: inconsistency can be
hard to detect, especially in concurrency/timing aspects and condition logic
– Formal modeling can help
Source: Adapted from Blum 1992, pp164-5 and the IEEE-STD-830-1993
© 2002
Page 13
User Requirements Notation
Towards Good Requirements Specs!
Necessary– Doesn’t contain anything
that isn’t “required” Unambiguous
– Every statement can be read in exactly one way
– Clearly defines confusing terms
E.g. in a glossary
Verifiable– A process exists to test
satisfaction of each requirement
– “every requirement is specified behaviorally”
Understandable (Clear)
– E.g. by non-computer specialists
Modifiable– Must be kept up to date!
Source: Adapted from Blum 1992, pp164-5 and the IEEE-STD-830-1993
© 2002
Page 14
User Requirements Notation
Typical Mistakes Noise
– the presence of text that carries no relevant information to any feature of the problem.
Silence– a feature that is not covered by
any text. Over-specification
– text that describes a feature of the solution, rather than the problem.
Contradiction– text that defines a single feature in
a number of incompatible ways. Ambiguity
– text that can be interpreted in at least two different ways.
Forward reference– text that refers to a feature yet to
be defined.
Wishful thinking– text that defines a feature that
cannot possibly be validated. Jigsaw puzzles
– e.g. distributing requirements across a document and then cross-referencing
Inconsistent terminology– Inventing and then changing
terminology Putting the onus on the
development staff– i.e. making the reader work hard
to decipher the intent Writing for the hostile reader
– There are fewer of these than friendly readers
Source: Steve Easterbrook, U. of Toronto
© 2002
Page 15
User Requirements Notation
For Further Information… B. A. Nuseibeh and S. M. Easterbrook, Requirements Engineering: A
Roadmap. In A. C. W. Finkelstein (ed) The Future of Software Engineering, ACM Press, 2000
– http://www.cs.toronto.edu/~sme/papers/2000/ICSE2000.pdf INCOSE Requirements Working Group
– http://www.incose.org/rwg/ Tools Survey: Requirements Management (RM) Tools
– http://www.incose.org/tools/tooltax.html– See also http://www.systemsguild.com/GuildSite/Robs/retools.html
IEEE (1993) Recommended Practice for Software Requirements Specifications. IEEE Std 830-1993, NY, USA.
IEEE (1995) Guide for Developing System Requirements Specifications. IEEE Std P1233/D3, NY, USA.
RE Conference– http://conferences.computer.org/RE/
Software Product Line Bibliography – http://www.iese.fraunhofer.de/Pulse/Bibliography/index.html
© 2002
Page 17
User Requirements Notation
Requirements and Service Description
Stage 1
Message Sequence
Information
Stage 2
Protocols,Procedures,Behaviour
Stage 3
SDL orUML Statechart
diagrams
MSC orUML interaction
diagrams
Informal requirements?Use Cases?
URN!
Motivation for URN (ITU-T SG17 Question 18)
© 2002
Page 18
User Requirements Notation
URN - Initial Objectives
Focus on early stages of design, with scenarios Capture user requirements when little design detail is
available No messages, components, or component states
required Reusability of scenarios and allocation to
components– Evaluation of architectural alternatives
Dynamic refinement capabilities – Behaviour and structure
Early performance analysis Early detection of undesirable interactions
© 2002
Page 19
User Requirements Notation
URN - Additional Objectives
Express, analyse and deal with goals and non-functional requirements (NFRs)
Express the relationship between business objectives/goals and system requirements
Capture reusable analysis (argumentation) and design knowledge (patterns)
Traceabilty and transformations to other languages– Particularly MSC, SDL, TTCN, and UML
Connect URN elements to external req. objects Manage evolving requirements
© 2002
Page 20
User Requirements Notation
Current Proposal for URN
Draft documents for Z.150, Z.151, Z.152– http://www.UseCaseMaps.org/urn/
Combined use of two complementary notations:– Goal-oriented Requirement Language (GRL) for
NFRs (http://www.cs.toronto.edu/km/GRL/)– Use Case Maps (UCM) for Functional
Requirements (http://www.UseCaseMaps.org/)
Create ITU-T standard by end of 2003 (Z.150-153)
© 2002
Page 21
User Requirements Notation
GRL in a Nutshell
Goal-oriented Requirement Language — a graphical notation that allows reasoning about (non-functional) requirements
GRL is concerned with intentional elements, actors, and their relationships
Intentional elements model the “why” aspect — objectives, alternatives, as well as decision rationale and criteria — but not operational details
GRL may be mapped to scenario-based notations and thus supports reasoning about scenarios
GRL satisfies most of URN’s additional objectives
© 2002
Page 22
User Requirements Notation
Basic GRL Notation
Means-End
PasswordCardkey Biometrics
Correlation(side-effect)
Cost ofTerminal
Belief
Argumentation
Biometrics is noregular off-the-shelf
technology
Goal
Decomposition(AND)
IdentificationAuthentication
Task
Make..Access
Authorization Encryption
?Break Hurt Some- Unknown
Make Help Some+ Equal
Contribution
Security ofHost
Security ofTerminal
Softgoal SystemSecurity
© 2002
Page 23
User Requirements Notation
Evaluations with GRL
..
PasswordCardkey Biometrics
Identification
Cost ofTerminal
Biometrics is noregular off-the-shelf
technology
AccessAuthorization Encryption
Authentication
Satisficed
Weakly Satisficed
Undecided
Weakly Denied
Denied
Security ofHost
Security ofTerminal
SystemSecurity
© 2002
Page 24
User Requirements Notation
GRL Model with Actors
..
PasswordCardkey Biometrics
Identification
Cost ofTerminal
Biometrics is noregular off-the-shelf
technology
AccessAuthorization
Encryption
Authentication
Securityof HostSecurity of
Terminal
SystemSecurity
ActorBoundary
.
TaxPayer
Payment
ForwardTax Forms
ResourceDependency
ElectronicAccountant
Actor
Keep PasswordSecret
© 2002
Page 25
User Requirements Notation
Key Points - GRL Introduction & Notation
GRL (Goal-oriented Requirement Language) provides an intentional view of a system, focusing on the “why” aspect
Goals provide the right abstraction level for many requirements activities
The basic elements of the GRL notation are goals, softgoals, tasks, qualified contribution and correlation links, means-end links, and decomposition links
GRL graphs document rationale of subjective issues Evaluations of GRL graphs show the impact of
qualitative decisions on high level softgoals
© 2002
Page 26
User Requirements Notation
UCMs in a Nutshell
Use Case Maps – a graphical scenario notation for describing causal relationships between responsibilities
Scenario elements may (optionally) be linked to components, providing a grey-box view of systems
The intent of UCMs is to facilitate the integration, reusability, and analysis of scenarios, and to guide the design of high level architectures and detailed scenarios from requirements
UCMs satisfy most initial URN requirements
© 2002
Page 27
User Requirements Notation
Component
StartPoint
End Point
Responsibility
Stub
AND-Fork
Pool
a) Root UCM
Slot
b) Biometrics Plug-In c) PassWord Plug-in
Timer
OR-Fork
© 2002
Page 28
User Requirements Notation
Electronic Accountant: Highlight
Biometrics selected, Successful scenario
© 2002
Page 29
User Requirements Notation
UCM Scenario Definitions
Enhances the behavioral modeling capability of UCM paths and path elements
Requires a path data model– Currently, global and modifiable Boolean variables– Scenario definition: initial values and start points– Used in conditions for OR-forks and dynamic
stubs– Variables may be updated in responsibilities
Combined to a path traversal algorithm Mapping rules for transformations
© 2002
Page 30
User Requirements Notation
UserA AgentA AgentB UserB
req
msg1
ring
vrfy
upd
chk
UserA Switch SN UserBreq
chk
upd
msg2
ring
msg5
msg4msg3
vrfy
SN
req
chk
upd
User:BUser:A Switch
vrfy
ring
User:A Agent:A Agent:B User:B
req ringvrfy updchk
Refining UCMs with Messages
© 2002
Page 32
User Requirements Notation
Why Stop at MSCs?
UCMspec(XML)
MSC’2000
HMSCUMLcollaboration
diagrams
UMLsequencediagrams
ScenarioOutput(XML)
MSC ’96
LOTOStest cases
TTCN-3test cases
Performancemodels
Documentation(ps, pdf, cgm)
© 2002
Page 33
User Requirements Notation
UCMs and Performance
Response TimeRequirement• From T1 to T2• Name• Response time• Percentage
Security E_Accountant
ReadyContinueCheckBio
TaxPayer
Access
T1
Timestamp
T2
Device Characteristics• Processors, disks, DSP, external services…• Speed factors
Rejected
ArrivalCharacteristics• Exponential, or• Deterministic, or• Uniform, or• Erlang, or• OtherPopulation size
Responsibilities•Data access modes•Device demand parameters
•Mean CPU load (time)•Mean operations on other devices
OR Forks• Relative weights (probability)
Components• Allocated responsibilities• Processor assignment
Can generate Layered Queuing Networks (LQN) automatically!
© 2002
Page 34
User Requirements Notation
GRL - UCM Relationship
Goal-based approach– Focuses on answering “why” questions– Addresses functional and non-functional requirements
Scenario-based approach– Focuses on answering “what” questions
Goals are operationalized into tasks and tasks are elaborated in (mapped to) UCM scenarios
– Focuses on answering “how” questions
© 2002
Page 35
User Requirements Notation
?
?MSC, UML Use
Case Diagram & Activity Diagram
Informal Requirements,
Textual Use Cases
URN — Missing Piece of the Modelling Puzzle?
UCMs link to operationalizations
(tasks) in GRL models
Structural Diagrams
SDL, eODL, or UML class, object,
component, & deployment
diagrams
Testing and Performance Languages
TTCN, LQN, ...
Behavioral DiagramsMSC/SDL, or UML
sequence, collabor., & statechart diagrams
UCMs represent visually use cases in terms of causal
responsibilities
UCMs provide a framework for
making high level and detailed
design decisions
UCMs visually associate
behavior and structure at the
system level
URN-FR / UCMsSuperimpose visually system level behavior onto structures of abstract components. Can
replace UML use case & deployment diagams.
URN-NFR/GRLGoals, non-functional requirements, alterna-
tives, rationales
© 2002
Page 36
User Requirements Notation
GRL Tool: OME3
Java tool, developed by Prof. Eric Yu, Dr. Lin Liu, and others (University of Toronto)
Conceptual modeling tool and model analysis tool OME3 supports many frameworks
– NFR (Non-Functional Requirements Framework)– i* (Strategic Actor-based Modelling Framework)– GRL (Goal-Oriented Requirements Language)
Based on TELOS Exports to XML Version 3.10: http://www.cs.toronto.edu/km/GRL/
© 2002
Page 39
User Requirements Notation
UCM Tool: UCMNAV By A. Miga, D. Petriu, D. Amyot and others, since 1997 Editing and navigating of UCMs Supports UCM path and component notations Maintains bindings
– Plug-ins to stubs, responsibilities to components, sub-components to components, etc.
Editing is transformation-based– Operations maintain syntactic correctness – Enforce some static semantics constraints
Scenario definitions– Path highlighting and MSC generation (Z.120, textual)– XML scenario generation
Performance analysis– Performance annotations– Generation of Layered Queuing Networks (LQN)
© 2002
Page 41
User Requirements Notation
UCMNAV Facts
Load/save/import/export in XML Developed in C++, GUI in Xforms Requires an X-server
– E.g. Xfree86 freeware (http://xfree86.cygwin.com/)
Multiple platforms are currently supported– Solaris, Linux, and Windows (all)
Current stable version: 2.0.1– Freely available at http://www.UseCaseMaps.org
Free and Open Source:– http://ucmnav.sourceforge.net
© 2002
Page 42
User Requirements Notation
UCMNav Documents
XML file format (conforms to UCM DTD) Export of UCM figures
– Encapsulated PostScript (EPS)– Maker Interchange Format (MIF)– Computer Graphics Metafile (CGM) – Scalable Vector Graphics (SVG)
Flexible report generation– Content options– PostScript, with PDF hyperlink information
© 2002
Page 44
User Requirements Notation
URN – Emerging Projects
URN for Reverse-Engineering (KLOCwork Suite) UCM/XML Scenarios to MSC, UML, TTCN, Doc… URN and Requirements Management (DOORS) URN and Requirements-based Design (synthesis) URN and Performance Engineering (UCM2LQN) ASM-Based Semantics for URN
Socket
Logic
SendMsg
MsgSentToTool
ProcessMsg MsgToTool
GetRequest
SendMsg
LogicLayerLogicLayerLogicLayer
SocketLayerSocketLayerSocketLayer
BufferLayerBufferLayerBufferLayer
FILE ScenarioMessage48
6
1
18
34
9
32
1
8
32
MsgSentToTool
ProcessMsg MsgToTool
GetRequest
© 2002
Page 45
User Requirements Notation
Conclusion
URN – Combines goals and scenarios– Helps bridging the gap between requirements models and
design models GRL
– For incomplete, fuzzy, non-functional requirements– Capture goals, objectives, alternatives and rationales
UCM– For operational and functional requirements– Enables analysis and transformations– Architectural alternatives and dynamic systems
© 2002
Page 46
User Requirements Notation
Selected References URN: http://www.UseCaseMaps.org/urn ITU-T SG 17: Draft Recommendations Z.150, September 2002 ITU-T SG 17: Draft Recommendations Z.151 and Z.152, February 2002 D. Petriu and M. Woodside, Analysing Software Requirements Specifications for
Performance. In: Third International Workshop on Software and Performance (WOSP 2002), Rome, Italy, July 2002
D. Amyot and G. Mussbacher, URN: Towards a New Standard for the Visual Description of Requirements.In: 3rd SDL and MSC Workshop (SAM’02), Aberystwyth, U.K., June 2002.
G. Mussbacher, D. Amyot (2001), A Collection of Patterns for Use Case Maps. In: First Latin American Conference on Pattern Languages of Programming (SugarLoafPLoP 2001), Rio de Janeiro, Brazil, October 2001.
D. Amyot (2001), Specification and Validation of Telecommunications Systems with Use Case Maps and LOTOS. Ph.D. thesis, SITE, U. of Ottawa, Canada, September 2001.
A. Miga, D. Amyot, F. Bordeleau, D. Cameron, and M. Woodside (2001), Deriving Message Sequence Charts from Use Case Maps Scenario Specifications . In: Tenth SDL Forum (SDL'01), Copenhagen, Denmark, June 2001.
L. Liu and E. Yu (2001), From Requirements to Architectural Design –Using Goals and Scenarios. In: From Software Requirements to Architectures Workshop (STRAW 2001), Toronto, Canada, May 2001.
D. Amyot and G. Mussbacher (2000), On the Extension of UML with Use Case Maps Concepts. In: The 3rd International Conference on the Unified Modeling Language (<<UML2000>>), York, UK, October 2000.
R.J.A. Buhr (1999), Use Case Maps as Architectural Entities for Complex Systems. In: Trans. on Software Engineering, IEEE, Vol. 24, No. 12, December 1998, pp. 1131-1155.