Daniel Amyot

1
Requirements Engineering User Requirements
Notation

• Daniel Amyot
• damyot_at_site.uottawa.cahttp//www.UseCaseMaps.org/
  urn/
• October 2002

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

3
Part I

• Requirements Engineering

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.

5
Requirements Engineering
Requirements Engineering
Larry Boldt, Trends in Requirements
EngineeringPeople-Process-Technology, Technology
Builders, Inc., 2001
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
  consistencyand completeness

7
A Requirements Engineering Approach
Adapted from Karl Wiegers, Software Requirements
1-7
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

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
10
Why Manage Requirements ?
Distribution of Effort to Fix Defects
Distribution of Defects
Code 1
Code 7
Other 4
Design 13
Requirements 56
Other 10
Requirements 82
Design 27

• (Martin Leffinwell)

11
RE Process and Related Activities
Identify Business Needs
Why? What? How? Who? When? If-Then Does
It? Where?
Derive User Functional Requirements
Time
Design Solutions
Project Management Process
Risk Management Process
Quality Management Process
Component Configuration Management Process
12
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
• Doesnt 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

13
Towards Good Requirements Specs!

• Necessary
• Doesnt contain anything that isnt 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

14
Typical Mistakes

• 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

• 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.

Source Steve Easterbrook, U. of Toronto
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
• http//www.cs.toronto.edu/sme/papers/2000/ICSE200
  0.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/Rob
  s/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/i
  ndex.html

16
Part II

• User Requirements Notation (URN)

17
Motivation for URN (ITU-T SG17 Question 18)
SDL or UML Statechart diagrams
MSC or UML interaction diagrams
Informal requirements? Use Cases?
URN!
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

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

20
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)

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 URNs additional objectives

22
Basic GRL Notation
23
Evaluations with GRL
24
GRL Model with Actors
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

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

27
Pool
StartPoint
Stub
AND-Fork
Slot
End Point
Responsibility
Component
a) Root UCM
28
Electronic Accountant Highlight
Biometrics selected, Successful scenario
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

30
Refining UCMs with Messages
31
MSC for Biometrics Successful
32
Why Stop at MSCs?
UCMspec(XML)
Scenario Output(XML)
MSC 96
LOTOStest cases
TTCN-3test cases
Performance models
Documentation (ps, pdf, cgm)
33
UCMs and Performance

• Device Characteristics
• Processors, disks, DSP, external services
• Speed factors

• Arrival
• Characteristics
• Exponential, or
• Deterministic, or
• Uniform, or
• Erlang, or
• Other
• Population size

Timestamp

• Response Time
• Requirement
• From T1 to T2
• Name
• Response time
• Percentage

Security
E_Accountant
TaxPayer
T1
CheckBio
Continue
Ready
Access
Rejected

• Components
• Allocated responsibilities
• Processor assignment

• Responsibilities
• Data access modes
• Device demand parameters
• Mean CPU load (time)
• Mean operations on other devices

• OR Forks
• Relative weights (probability)

Can generate Layered Queuing Networks (LQN)
automatically!
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

35
URN Missing Piece of the Modelling Puzzle?
UCMs link to operationalizations(tasks) in GRL
models
UCMs represent visually use cases in terms of
causal responsibilities
UCMs visually associate behavior and structure at
the system level
UCMs provide a framework for making high level
and detailed design decisions
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 http//www.cs.toronto.edu/km/GRL/

37
(No Transcript)
38
(No Transcript)
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)

40
UCMNAV and Scenario Highlight
41
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

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

43
Report Generation in PS/PDF
44
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

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

46
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
  (SAM02), 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 (ltltUML2000gtgt), 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.