User Requirements Notation

R N
Requirements Engineering &
User Requirements Notation

U
Daniel Amyot

damyot@[Link]
[Link]

October 2002
Page 2

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 User Requirements Notation

Page 3

Part I

Requirements
Engineering

© 2002 User Requirements Notation

Page 4

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 User Requirements Notation

Page 5

Requirements Engineering
Requirements Engineering

Requirements Requirements
Development Management

Elicitation Analysis Specification Verification

Larry Boldt, Trends in Requirements Engineering

People-Process-Technology, Technology Builders, Inc., 2001

© 2002 User Requirements Notation

Page 6

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 User Requirements Notation

Page 7

A Requirements Engineering
Business
Goals/Objectives Approach
Vision and Scope Document

User Quality
Requirements Attributes

Use Case Document

System
Requirements
Functional
Requirements Constraints

Adapted from Karl Wiegers,

Software Requirements Software Requirements Specification

© 2002 User Requirements Notation 1-7

Page 8

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 User Requirements Notation

Page 9

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 User Requirements Notation

Page 10

Why Manage Requirements ?

Distribution of Distribution of Effort to
Defects Fix Defects

Code Code
Other Design
Requirements 7% 1%
Other Requirements 4% 13%
56% 10% 82%

Design
27%
(Martin & Leffinwell)

© 2002 User Requirements Notation

Page 11

RE Process and Related Activities

Why? Identify Business Needs

What? Derive User & Functional Requirements

Time
How? Design Solutions
TIME
Who?
When? Project Management Process

If-Then Risk Management Process

Does It? Quality Management Process

Where? Component & Configuration Management Process

© 2002 User Requirements Notation
Page 12

Towards Good Requirements Specs!

 Valid (or “correct”)  Consistent
– Expresses actual – Doesn’t contradict itself
requirements (satisfiable)
 Complete – Uses all terms consistently
– Specifies all the things the – Note: inconsistency can be
system must do hard to detect, especially in
– ...and all the things it must concurrency/timing aspects
not do! and condition logic
– Conceptual Completeness
– Formal modeling can help
 E.g. responses to all
classes of input
– Structural Completeness
 E.g. no TBDs!!!

Source: Adapted from Blum 1992, pp164-5 and the IEEE-STD-830-1993

© 2002 User Requirements Notation

Page 13

Towards Good Requirements Specs!

 Necessary  Verifiable
– Doesn’t contain anything – A process exists to test
that isn’t “required” satisfaction of each
 Unambiguous requirement
– “every requirement is
– Every statement can be
specified behaviorally”
read in exactly one way
– Clearly defines confusing
 Understandable
terms (Clear)
 E.g. in a glossary – 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 User Requirements Notation

Page 14

Typical Mistakes
 Noise  Wishful thinking
– the presence of text that carries – text that defines a feature that
no relevant information to any cannot possibly be validated.
feature of the problem.  Jigsaw puzzles
 Silence – e.g. distributing requirements
– a feature that is not covered by across a document and then
any text. cross-referencing
 Over-specification  Inconsistent terminology
– text that describes a feature of the – Inventing and then changing
solution, rather than the problem. terminology
 Contradiction  Putting the onus on the
– text that defines a single feature in development staff
a number of incompatible ways. – i.e. making the reader work hard
 Ambiguity to decipher the intent
 Writing for the hostile reader
– text that can be interpreted in at
least two different ways. – There are fewer of these than
 Forward reference friendly readers
– text that refers to a feature yet to
be defined.

Source: Steve Easterbrook, U. of Toronto

© 2002 User Requirements Notation

Page 15

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
– [Link]
 INCOSE Requirements Working Group
– [Link]
 Tools Survey: Requirements Management (RM) Tools
– [Link]
– See also [Link]
 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
– [Link]
 Software Product Line Bibliography
– [Link]

© 2002 User Requirements Notation

Page 16

Part II

User Requirements
Notation (URN)

© 2002 User Requirements Notation

Page 17

Motivation for URN

(ITU-T SG17 Question 18)

Stage 1 Stage 2 Stage 3

Requirements Message Protocols,
and Service Sequence Procedures,
Description Information Behaviour
Informal requirements? MSC or SDL or
Use Cases? UML interaction UML Statechart
URN! diagrams diagrams

© 2002 User Requirements Notation

Page 18

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 User Requirements Notation
Page 19

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 User Requirements Notation

Page 20

Current Proposal for URN

 Draft documents for Z.150, Z.151, Z.152
– [Link]
 Combined use of two complementary
notations:
– Goal-oriented Requirement Language (GRL) for
NFRs ([Link]
– Use Case Maps (UCM) for Functional
Requirements ([Link]
 Create ITU-T standard by end of 2003
(Z.150-153)
© 2002 User Requirements Notation
Page 21

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 User Requirements Notation

Page 22

Basic GRL Notation

System
Softgoal
?
Break Hurt Some- Unknown
Security

Belief Contribution
Make Help Some+ Equal Biometrics is no Security of
regular off-the-shelf Host
technology Security of

. Terminal
. Make
Argumentation
Access
Cost of Encryption
Authorization
Terminal
Task
Decomposition
Correlation (AND)
Authentication Identification
(side-effect)
Means-End Goal

Cardkey Password Biometrics

© 2002 User Requirements Notation

Page 23

Evaluations with GRL

Satisficed
System
Security
Weakly Satisficed

Undecided
Biometrics is no Security of
Weakly Denied regular off-the-shelf Host
technology Security of
Denied
. Terminal
.
Access
Cost of Encryption
Authorization
Terminal

Authentication Identification

Cardkey Password Biometrics

© 2002 User Requirements Notation

Page 24

GRL Model with Actors

Resource Actor
Dependency
Payment
Electronic
Accountant
TaxPayer
Forward
Tax Forms System
Security
.
Biometrics is no Security
regular off-the-shelf of Host
technology Security of

. Terminal
.
Cost of Access
Encryption
Terminal Authorization

Authentication Identification
Keep Password
Secret

Cardkey Password Biometrics

Actor
Boundary

© 2002 User Requirements Notation

Page 25

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 User Requirements Notation
Page 26

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 User Requirements Notation

Page 27

Pool

Start Stub
Point

AND-Fork
Slot

End Point

Responsibility
Component
a) Root UCM

b) Biometrics Plug-In c) PassWord Plug-in

Timer

OR-Fork

© 2002 User Requirements Notation

Page 28

Electronic Accountant: Highlight

Biometrics selected, Successful scenario

© 2002 User Requirements Notation
Page 29

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 User Requirements Notation

Page 30

Refining UCMs with Messages

UserA AgentA AgentB UserB
req
User:A Agent:A Agent:B User:B
chk
msg1
chk vrfy upd
req ring
vrfy

upd
ring

SN
chk UserA Switch SN UserB
req
msg2
msg3
User:A Switch User:B msg4

vrfy chk
msg5
req ring
upd vrfy
upd
ring

© 2002 User Requirements Notation

Page 31

MSC for Biometrics Successful

© 2002 User Requirements Notation

Page 32

Why Stop at MSCs?

UML UML HMSC
sequence collaboration
diagrams diagrams

MSC’2000

UCM Scenario
spec Output MSC ’96
(XML) (XML)

LOTOS
test cases

Documentation Performance TTCN-3

(ps, pdf, cgm) models test cases

© 2002 User Requirements Notation

Page 33

UCMs and Performance

Device Characteristics
• Processors, disks, DSP,
Arrival external services…
• Speed factors
Characteristics Timestamp
• Exponential, or
• Deterministic, or TaxPayer Security E_Accountant Response Time
• Uniform, or T1 T2 Requirement
• Erlang, or CheckBio Continue • From T1 to T2
Access Ready • Name
• Other
Population size Rejected
• Response time
• Percentage

Components
Responsibilities
• Allocated responsibilities
OR Forks •Data access modes
• Processor assignment
• Relative weights •Device demand parameters
(probability) •Mean CPU load (time)
•Mean operations on
Can generate Layered Queuing other devices
Networks (LQN) automatically!

© 2002 User Requirements Notation

Page 34

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 User Requirements Notation

Page 35

URN — Missing Piece of the

Modelling Puzzle?
URN-NFR/GRL UCMs link to

?
Informal operationalizations
Structural Requirements, Goals, non-functional
(tasks) in GRL
Diagrams Textual Use Cases requirements, alterna-
models
tives, rationales
SDL, eODL, or
UML class, object,

?
component, & MSC, UML URN-FR
Use / UCMs UCMs represent
visually use cases
deployment Case Diagram
Superimpose &
visually system level behavior in terms of causal
diagrams Activity
onto Diagram
structures of abstract components. Can responsibilities
replace UML use case & deployment diagams.

UCMs visually UCMs provide a

associate Behavioral Diagrams Testing and framework for
behavior and MSC/SDL, or UML Performance making high level
structure at the sequence, collabor., & Languages and detailed
system level statechart diagrams design decisions
TTCN, LQN, ...

© 2002 User Requirements Notation

Page 36

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: [Link]

© 2002 User Requirements Notation

Page 37

© 2002 User Requirements Notation

Page 38

© 2002 User Requirements Notation

Page 39

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 User Requirements Notation

Page 40

UCMNAV and Scenario Highlight

© 2002 User Requirements Notation

Page 41

UCMNAV Facts
 Load/save/import/export in XML
 Developed in C++, GUI in Xforms
 Requires an X-server
– E.g. Xfree86 freeware ([Link]
 Multiple platforms are currently supported
– Solaris, Linux, and Windows (all)
 Current stable version: 2.0.1
– Freely available at [Link]
 Free and Open Source:
– [Link]

© 2002 User Requirements Notation

Page 42

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 User Requirements Notation

Page 43

Report Generation in PS/PDF

© 2002 User Requirements Notation

Page 44

URN – Emerging Projects

FILE ScenarioMessage
48

6
Logic LogicLayer
ProcessMsg MsgToTool

ProcessMsg MsgToTool
1 MsgSentToTool

18
Socket SocketLayer
SendMsg SendMsg
GetRequest
34

MsgSentToTool 9 BufferLayer
GetRequest 8

32

32 1

 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

© 2002 User Requirements Notation

Page 45

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 User Requirements Notation

Page 46

Selected References
 URN: [Link]
 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 [Link]: 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.

© 2002 User Requirements Notation