Requirements Engineering & User Requirements Notation

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 3


Part I

Requirements Engineering

© 2002

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

Page 5




Requirements Development

Requirements Management

Elicitation Analysis Specification Verification

Larry Boldt, Trends in Requirements EngineeringPeople-Process-Technology, Technology Builders, Inc., 2001

© 2002

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

Page 7


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


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


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


(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


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


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


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


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


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 16


Part II

User Requirements Notation (URN)

© 2002

Page 17


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


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


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


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


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


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


Evaluations with GRL

..


Identification

Cost ofTerminal


technology

AccessAuthorization Encryption

Authentication

Satisficed

Weakly Satisficed

Undecided

Weakly Denied

Denied

Security ofHost

Security ofTerminal

SystemSecurity

© 2002

Page 24


GRL Model with Actors

..


Identification

Cost ofTerminal


technology

AccessAuthorization

Encryption

Authentication

Securityof HostSecurity of

Terminal

SystemSecurity

ActorBoundary

.

TaxPayer

Payment

ForwardTax Forms

ResourceDependency

ElectronicAccountant

Actor

Keep PasswordSecret

© 2002

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

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

Page 27


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


Electronic Accountant: Highlight

Biometrics selected, Successful scenario

© 2002

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

Page 30


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 31


MSC for Biometrics Successful

© 2002

Page 32


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


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


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


?

?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


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 37


© 2002

Page 38


© 2002

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

Page 40


UCMNAV and Scenario Highlight

© 2002

Page 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

© 2002

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

Page 43


Report Generation in PS/PDF

© 2002

Page 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

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


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


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.