Requirements Engineering - UZH92e16808-9399-4a2d-9105-a...Requirements Engineering – A Personal Reﬂection "© 2017 Martin Glinz" 2" Das Ptoblert',o iBvers o n o o Uh An vollslåndige

Department of Informatics!

Requirements Engineering

Requirements Engineering

ResearchGroup"

Ein persönlicher Rückblick und Ausblick"A Personal Reflection"

Abschiedsvorlesung Farewell Lecture

2017-05-09

Martin Glinz

www.ifi.uzh.ch/rerg"

2"Requirements Engineering – A Personal Reflection "© 2017 Martin Glinz"

Das Ptoblert',

o

iBvers no

oo

UhAn

vollslåndigef orderunse

lnFormot¡k

und l,õ¡tris¡cn

ul!roa

U)ie sfell' ;oLs Jor,danit meine Anweder

greìf en ?es be

oC'

ID

v49 e 7¡ele

AnwcndunF¡ch¡liss¿n

I

, Ivnrealisf isch e Erv¡,p,rlu

lnfornoliKern

i"h's

?

ìe sagmeìnen

/ /// / )

First slide from my inaugural lecture"1994-06-27"


Das Ptoblgrr....uncl scinc tõsenq r

Reryircrrent s En3inecring

o

iB nasver

C'a

UhAn

vollsländ igef ordervngê

C'rl

lnFormof I

O

t Ivnrealisf isch e Erv,nr

AnwcndungFach¡lissen

e Z¡ele

U)ie slell' ;úL Jor,danit rneine Anueder

greìfen ?es be

lnfornoliKern

i"h's2

ìe sagmeìnen

/ /// / )

Two fundamental invariants of Requirements Engineering (RE)""• "Bridging the gap""• "Creating and ensuring

shared understanding""... between stakeholders and developers"

My life with RE – in five stories"

1 "The early days"2 "Requirements modeling"3 "Stakeholders"

4 "Value-orientation"5 "Shared understanding"


The birth of a new discipline"


30/ /t2 sE¡.

-IANUARY 1977 VOLUME SE-3

,{ PUBLICATION OF THE IEEE COMPUTER SOCIETY

IEEE TFlANSACTIONS ONSOF'T\MAR,EFNGINEER,ING

NUMBER 1

@

ETH.ZÜ R ICH

2 4. Feb. 19¿BI B LIOTH EK

Cat-

t:f)ITOR'S NOTICE R. T. Yeh I

S l)t:ClA l- COLLECTION ON REQU I REM ENT ANAI-YSIS

Gucst Editorial-Reflcctions on Rcquìrcments . . . . . D. 'T. Il.ossStructured Analysis lor Rcquiremcnts Delinition .D. T. Ross and K. E. Schonton, Jr.Structurcd Analysis (SA): A Language for Communicating Idcas . D. .|. R¿.r.ç.çÂuttrrnatcd Soltware Engincering Through Structured Managcmcnt . . . . . .C. A. Irttine atttl J. W. Brut.keilPSL/PSA: A Computcr-Aidcd Technique for Structr.rred Docunrcntation and Analysis ol Inlorm¿rtion ProccssingSystcnrs .....D. Teicrtroe,,ç atur E. A. Hershe¡,, IIIAn Extcndablc Approach to computer-Aided Soltware Rcquircmcnts Enginecrins . . . .

.....7. E. Bell, D.C. Bi.rler,and t+t. ti. DyerA lìcquirerrrcnts Enginccring Mcthodology lor Rcal-Tiurc Proccssing Rcquircrncnts ... .....11,Í. Ll/..4tJortt'fhc Soltrvarc l)cvclopnrcnt System .C. G. Dat¡is Qnd C. R. vick

26

l634

4t

496069

f'^ l'l:lì.S

A nu I t's i.s oJ' Á I gtr i t h rns

Multiproccssor schcduling with thc Aid of Nctwork Flow AlgorithmsTrvtl l\f cthotls lbr thc I:ilicicnt Analysis of'Mcrnory Address Tr¿rce Data

ll. S. StoneA. J. Sntiih

8594

ACKNOWI.frfxi M llN'f OIr RtifrtìRl]tìS R. T. Yeh 102

TSE SE-3(1)"


Special Collection on Requirement Analysis"

30/ /t2 sE¡.

-IANUARY 1977 VOLUME SE-3

,{ PUBLICATION OF THE IEEE COMPUTER SOCIETY

IEEE TFlANSACTIONS ONSOF'T\MAR,EFNGINEER,ING

NUMBER 1

@

ETH.ZÜ R ICH

2 4. Feb. 19¿BI B LIOTH EK

Cat-

t:f)ITOR'S NOTICE R. T. Yeh I

S l)t:ClA l- COLLECTION ON REQU I REM ENT ANAI-YSIS

Gucst Editorial-Reflcctions on Rcquìrcments . . . . . D. 'T. Il.ossStructured Analysis lor Rcquiremcnts Delinition .D. T. Ross and K. E. Schonton, Jr.Structurcd Analysis (SA): A Language for Communicating Idcas . D. .|. R¿.r.ç.çÂuttrrnatcd Soltware Engincering Through Structured Managcmcnt . . . . . .C. A. Irttine atttl J. W. Brut.keilPSL/PSA: A Computcr-Aidcd Technique for Structr.rred Docunrcntation and Analysis ol Inlorm¿rtion ProccssingSystcnrs .....D. Teicrtroe,,ç atur E. A. Hershe¡,, IIIAn Extcndablc Approach to computer-Aided Soltware Rcquircmcnts Enginecrins . . . .

.....7. E. Bell, D.C. Bi.rler,and t+t. ti. DyerA lìcquirerrrcnts Enginccring Mcthodology lor Rcal-Tiurc Proccssing Rcquircrncnts ... .....11,Í. Ll/..4tJortt'fhc Soltrvarc l)cvclopnrcnt System .C. G. Dat¡is Qnd C. R. vick

26

l634

4t

496069

f'^ l'l:lì.S

A nu I t's i.s oJ' Á I gtr i t h rns

Multiproccssor schcduling with thc Aid of Nctwork Flow AlgorithmsTrvtl l\f cthotls lbr thc I:ilicicnt Analysis of'Mcrnory Address Tr¿rce Data

ll. S. StoneA. J. Sntiih

8594

ACKNOWI.frfxi M llN'f OIr RtifrtìRl]tìS R. T. Yeh 102

Requirements Engineering in 1977"

❍  Languages and tools (plus some methods)"❍  Requirements came (by some magic) from the “customer”"❍  Core parts of today’s body of RE such as"

Elicitation, validation, and management of requirements, including negotiation, change management or traceability)"

"not yet recognized"●  neither as practical problems"●  nor as research topics"


In January 1977 I was finishing my diploma thesis in Mathematics at RWTH Aachen University and had no idea that this work would shape my life some day"

The vision of RE 1970’ & 1980’"

❍  Create complete and unambiguous specifications of the problem"

❍  using formal or semi-formal models"❍  supported by powerful tools"

❍  Textual (entity-relationship-based)"❍  Graphic (flow-based or state-event based)"


Some examples: SADT"


SADT: A graphic modeling language"Based on hierarchical flow diagrams"

22 IEEE TRANSACTIONS ON SOFTWARE ENGIN EERING, JANUARY

SAOT9 DIAGRAM FORM ST098 9 /75 Form <· 1975 SofTech.1nc , 460 Totten Pond Road. Waltham. Mass. 02154. USA

USED AT: AUTHOR : DATE : l }WORKING ]!lEAOER DATEf CONTEXT: PROJECT : REV : [JoRAFT I j r TRECDMMENDEoI NOTES : 1 2 3 4 5 6 7 8 9 10 I I PUBLICATION l l

Cl GENERAL SUBJECT MATTER

BOUND _,A/ INSIDE/OUTSIDE

CONTEXT I

j' ,vf"ROM/TO RELATE/ SA CONNECT l BOX ,,

Ml 2

" SHOW INPUT_-.

SA -,. 01 ARROW TRANSFOR- OUTPUT_

I Ml MATION 3 f -- 01

SHOW CONTRO,!;;,_ Cl RC UM - ...... 01 STANCE 4 ,, ' j SHOW MECHANISM

MEANS 01 SA 5

Ml INTERFACES

SA Ml SUPPORT

NODE: ITITLE : IN UMBER : Al FIG . 4 DEFINE GRAPHICS R3 l

TO ... CONTROL INTERFACES ARROW

OUTSIDE

INPUT Ir OUTPUT INSIDE

\ T. FROM TRANSFORMATION CIRCUMSTANCE

MECHANISM (Of TRANSFORMATION) MEANS

FEO 4A fEO 48 FEO 4C FEO 4D

Fig. 4. Define graphics.

The title, "Define graphics," is identical to the name inside the first box of Fig. 3, which is here being broken into five compo-nent worthy pieces, called the nested factors in SA terminology. Again the words written inside the boxes are legible , but are they understandable? How can "Bound context ; relate/con-nect; show transformation ; show circumstance; show means," be considered parts of "Define graphics?" It is not very clear, is it? It would seem that something must be wrong with SA for the touted understandability turns out to be, in fact , quite obscure!

Look at Fig. 4 again and see if you don't agree that we have a problem- and see if you can supply the answer to the problem.

The problem is not with SA at all, but with our too-glib ap· proach to it. SA is a rigorous language and thereby is unfor-giving in many ways. In order for the communication of un-

derstanding to take place we ourselves must understand and conform to the rules of that rigor. The apparent obscurity should disappear in a twinkling once the following factor is pointed out : namely, alway s be sure to do your understand· ing in the proper context. In this case, the proper context was established by the title of Fig. 3, " Rationalize structured anal-ysis features ," and the purpose , to define graphical concepts and notations for the purpose of representing and conveying understanding of subject matters. Now, if we have all of that firmly implanted in our mind, then surely the name in Box 1 of Fig. 4 should be amply clear. Read , now, Box 4. 1 3 for yourself, and see if that clarity and communication of intended understanding does not take place.

3 To shorten references to figures, " Box 4. 1" will mean "Box 1 of Fig. 4," etc. in the following discussiort

[Ross 1977]"

Some examples: Semi-formal text"

Structured textual requirements specification"Based on an entity-relationship model "


TEICHROEW AND HERSHEY: STRUCTURED DOCUMENTATION AND ANALYSIS

Parameters: DB--EXBDB NAME-hourly-employee-processing NOINDEX NOPUNCHED-NAIRES PRINT ErIPFYNOPUNICH tIARG-5 NIIARG-20 AMARG-10 BMARG-25 RNIARG-70 CMARG-l HMARG-60 EODESIGNATESEVERAL-PER-LINE DEFINE COEMMENT NONEW-PAGE NONER-LINE NOALL-STATEfENTSCOGPLFMENTARY-STATVE1ESETS LINE-4IURBERS PRINTEOF DLCC1MMENT

1 PROCESS hourly-enployee-procesing;2 /1* DATE OF IAST CHIANGE - JUN 26, 1976, 13:56:44 R/3 DESCRIPTIOES;4 this procesR perforirs those actions needed to interpret5 time cards to produce a pay statement for each hourly6 employee.;7 KEYWORDS: independent;8 ATTRIBUTES ARE:9 complexity-level

10 high;11 GENERATES: pay-RtateneRt, error-liRting,12 hourly-employee-report;13 RECEIVES: time-card;14 SUEPARTS ARE: hourly-paycheck-validation, hourly-emp-update,15 h-report-entry-generation,16 hourly-paycheck-production;17 PART OF: payroll-processing;18 DERIVES: pay-statRe ent19 USING: time-card, hourly-employee-record;20 DERIVES: hourly-employee-report21 USING: time-card, hourly-employee-record;22 DERIVES: error-listing23 USING: time-card, hourly-employee-record;24 PROCEDURE;25 1. cRIpute gross pay from time card data.26 2. coRpute tax, from gross pay.27 3. subtract tax froD gross pay to obtain net pay.28 4. update hourly employee record accordingly.29 5. update department record accordingly.30 6. generate paycheck.31 note: if status code specifies that tEe employee did not work32 t:is week, no processingvill be done for this employee.;33 HAPPENS:34 number-of-payments T1MES-PER pay-period;3D TRIGGERED BY: hourly-emp-processing-event;36 TERMINATION-CAUSES:317 nw-erployee-proessing-evenRt;3E SECURITY IS: qompany-only;3940 EOF Eor EOF EOF EOF

Fig. 2. Example of a FORMATTED PROBLEM STATEMENT for one PROCESS.

The System Input/Output Flow aspect of the system dealswith the interaction between the target system and its en-

vironment.System Structure is concerned with the hierarchies among

objects in a system. Structures may also be introduced tofacilitate a particular design approach such as "top down."All information may initially be grouped together and calledby one name at the highest level, and then successively sub-divided. System structures can represent high-level hierarchieswhich may not actually exist in the system, as well as thosethat do.The Data Structure aspect of system description includes all

the relationships which exist among data used and/or manipu-lated by the system as seen by the "users" of the system.The Data Derivation aspect of the system description speci-

fies which data objects are involved in particular PROCESSES inthe system. It is concerned with what information is used,updated, and/or derived, how this is done, and by which pro-

cesses.Data Derivation relationships are internal in the system,

while System Input/Output Flow relationships describe thesystem boundaries. As with other PSL facilities System Input/Output Flow need not be used. A system can be considered as

having no boundary.The System Size and Volume aspect is concerned with the

size of the system and those factors which influence the volumeof processing which will be required.The System Dynamics aspect of system description presents

the manner in which the target system "behaves" over time.All objects (of a particular type) used to describe the target

system have characteristics which distinguish them from other

objects of the same type. Therefore, the PROPERTIES of par-

ticular objects in the system must be described. The PROP-ERTIES themselves are objects and given unique names.

The Project Management aspect requires that, in addition tothe description of the target system being designed, documen-

tation of the project designing (or documenting) the targetsystem be given. This involves identification of people in-volved and their responsibilities, schedules, etc.

IV. REPORTSAs information about a particular system is obtained, it is

expressed in PSL and entered into a data base using the Prob-lem Statement Analyzer. At any time standard outputs orreports may be produced on request. The various reports canbe classified on the basis of the purposes which they serve.

1) Data BaseModification Reports: These constitute a recordof changes that have been made, together with diagnostics andwarnings. They constitute a record of changes for error correc-vtion and recovery.2) Reference Reports: These present the information in the

data base in various formats. For example, the Name List Re-port presents all the objects in the data base with their type anddate of last change. The Formatted Problem Statement Reportshows all properties and relationships for a particular object(Fig. 2). The Dictionary Report gives only data dictionarytype information.3) Summary Reports: These present collections of informa-

tion in summary from, or gathered from several differentrelationships. For example, the Data Base Summary Reportprovides project management information by showing thetotals of various types of objects and how much has been saidabout them. The Structure Report shows complete or partialhierarchies. The Extended Picture Report shows the dataflows in a graphical form.4) Analysis Reports: These provide various types of analysis

of the information in the data base. For example, the Con-tents Comparision Report analyzes similarity of Inputs andOutputs. The Data Process Interaction Report (Fig. 3) can beused to detect gaps in the information flow, or unused dataobjects. The Process Chain Report shows the dynamic be-havior of the system (Fig. 4).

45

PSL [Teichroew&Hershey 1977] "Espreso [Ludewig 1983]"SPADES [Ludewig et al. 1985] "

Some examples: Structured Analysis"

"Based on a hierarchy ofdataflow diagrams"

Later extended with capabilitiesto model state-dependent behavior"


DFD 3

DFD 0

.1

.2 .3

DFD 1

Kontext-Diagramm

.1

.2.3

.4

1

32

0

Calibrate

Limits

Dimension

Value

Sensor value

Check limits

Checked value

Alarm indicator

Instrument images

Instrument display

Build instrument display

[DeMarco 1979]"

Some examples: STDs, statecharts"

Specification of event-driven, state-dependent system behavior"

State-transition diagrams, statecharts"

12"Requirements Engineering – A Personal Reflection "© 2017 Martin Glinz" 12"

closed"

open"

validating"

card sensed"validate card"

card valid"allow one turn;"count’ = count +1;"flash green light"

card invalid"flash red light"

count = 0"

one turn done"

normal mode"

Inactive mode"

switch to"normal mode"

IDL€,

úø.íñç

I

w

I

74 STRUCTURED DEVELOPMENT FOR REAL-TIME SYSTEMS

5rù?fwùaÍn*éÀ'îNs'\

TA+'|U- a\^?NAþ9çuE41uN)E

lÐrrlùlr4edr,(,;rttDlgtglJírrfl4¡¡¡6,rt6tttE TúAA.|ÍA$Jr\¡&'

¡rÐ&ndM.uoÉ r't LP<4¡DtlAtr,'MAhtfã$Jllft/wArr cl¡ WAll+

nW;*WDomtnrEuuug

Figure 7.12. St¡te transition diagram for Figure 7'11.

Another situation that can complicate a state-transition diagram is a large numberof similar behaviors of the system being controlled. Consider a system that must keeptrack of train traffic in a tunnel. If the tunnel is long enough to accommodate fourtrains simultaneously, the situation could be represented as in Figure 7.13, The modelis awkward and highly redundant; furthermore, if the system were to be implementedin several tunnels with differing capacities, a general model could not be built.

A shorthand notation for this situation is shown in Figure 7.14. The tests, incre-ments, and decrements of the counter T are not true conditions and actions, but merelya concise way of representing a number of similar states.

Even with these conventions for simplification, a single state diagram for a com-plex system can be very large. An alternative representation is discussed in the nextsection.

[Ward&Mellor 1985]"[Harel 1987]"

1983 – The beginning of a personal liaison"

In March 1983, I joined Brown Boveri (BBC) Research as a postdoc"

By then I considered myself as a database person"Our goal at BBC research was to build an integrated software engineering environment – everything from requirements to source code"

Requirements were to be stated in a text-based, semi-formal language: ESPRESO / SPADES"

My task was to design the database"


\2

1. EINFÜHRUNG

1.1 Die Software-Entwicklungsumgebunq SEEME

Aufgrund der noch immer nicht beherrschten Probleme bei der Abwicklungvon Software-Projekten (Termin- und Kostenüberschreitungen, unzuverlässige,schlecht wartbare Produkte) bemüht man sich weltweit um die Schaffung vonSoftware-Entwicklungsumgebungen, welche die effizientere Entwicklung besse-rer Software mit Werkzeugen unterstützen.

Obwohl es einige allgemein anerkannte Prinzipien bei der Software-Entwicklunggibt, hat sich bis heute keine Entwicklungsmethode allgemein durchsetzenkönnen. Der Ersteller einer Software-Entwicklungsumgebung steht daher vordem Problem, Werkzeuge entwickeln zu müssen, obwohl er sich über die Rich-tigkeit und ZweckmäBigkeit der" von diesen Werkzeugen unterstützten Methodennicht völlig im klaren ist. Die heute vorhandenen Systeme sind in der Regellnsellösungen, die eine bestimmte Methode für eine bestimmte Phase in derEntwicklung unterst[itzen. Hinzu kommt, daB die Benutzerakzeptanz ein ent-scheidendes Problem bei der Einführung von Software-Engineering-Methodenund -Werkzeugen ist und daB die Benutzer oft erst bei der Arbeit mit einemEntwicklungssystem merken, was sie eigentlich brauchen oder gerne hätten.

Eine gute Sofware-Entwicklungsumgebung sollte daher

- eine integrierte Menge von Werkzeugen bereitstellen

- eine komfortable, einheitliche Benutzerschnittstelle haben, um den Umgangmit den Werkzeugen (und das Erlernen dieses Umgangs) zu erleichtern

- eine schrittweise Einführung gestatten (Akzeptanzverbesserung)

- eine Anpassung der Werkzeuge an neue methodische Erkenntnisse und an

. geänderte oder erweiterte Bedürfnisse der Benutzen ermöglichen

Die Forderungen nach einem einerseits integrierten und einheitlichen, aberandererseits erweiterbaren System scheinen sich auf den ersten Blick zuwidersprechen. Es gibt jedoch ein Lösungskonzept/ welches diesen beiden undauch den übrigen oben aufgestellten Forderungen gerecht wird. Die Grundideedabei ist, das System funktionell in drei Teile zu gliedern: Einen HCI (human-computer interface)-Modul für die gesamte Kommunikation zwischen Benutzer

3

und System, ein Datenbanksystem, welches die gesamte Datenverwaltung und-kommunikation abwickelt und dazwischen eine Menge voneinander entkoppelterWerkzeuge, von denen jedes eine bestimmte Aufgabe im Rahmen des Software-Entwicklungsprozesses (2.8. Spezifikationserstellung oder Systemintegration)unterstützt. (Bild 1.1).

Ein solches System ist inteq riert , indem alle Werkzeuge in das aus HCI-Modulund Datenbanksystem gebildete Basissystem eingebettet sind und aufgrund dereinheitlichen Datenhaltung alle von einem Werkzeug erzeugten Daten ohneschwierigkeiten in anderen werkzeugen verwendet werden können.Das System hat eine einheitliche Benutzerschnittstelle und ist aufgrund derModularität des Werkzeugsatzes schrittweise einführbar , erweiterbar undänderbar.

wir nennen unser system daher sEEME (A software Engineeringwhich is modular and extensible.

Benutzer HCI-Modul Werkzeugsatz

Envi ronment

Datenban ksystem

Werkzeug 1

SEEME-HCt

Werkzeug n

SEEME-Base

Bild 1 .1 : Grundstruktur der Software-Entwicklungsumgebung SEEME

This was the plan"

""

"""And we believed in it..."Today we know that we were doomed to fail."

However, there was an effect: RE took possession of my life"


[Glinz&Ludewig 1984]"

The very first RE conference – in fall 1983"

So I came across RE""

and found it exciting""which I still do today."

15"

Inform ati k- Fachb e ri ch teHerausgegeben von W Brauerim Auftrag der Gesellschaft lur Infbrmatik (GI¡

71

Requirements E ngineering

Arbeitstagung der GIFriedrichshafen, C)ktober I 9tì3

Herausgegebenvon G. Flommel und D. Krönig

Springer-VerlagBerlin Heidelberg New York Tokyo

Ø(ö)

qrü

Requirements Engineering – A Personal Reflection "© 2017 Martin Glinz"

[Hommel&Krönig 1983]"





DORAobject-oriented Stake-

holder

My journey with requirements modeling"

From 1984 until today"


1984-1987: SPADES"


SPADES Tool User's Manual -40-

Example: Figure 18 shows an example of a contents report produced with defaultparameter values. Figure 19 shows a report of the same volume, butwith the following parameters:Depth Of Nesting = MIN (means no nesting)Relatíons = COMPRISEST STARTED-BYSel.ected lexts: values in submenu set to Selectors = ernpty string

Contents = *

SPADES 2.3 SPADES-L Form - REP0RT Genereted: 1986-10-21 10:51

T

T***

**t(Voi.ume: DS'10 Þased on vergion: 2 tgg6-L0-21, 06:2L

(:rr ffi 'Þ{0DULE'-DMSI0N *r.rok*ír*rdrroktck***rÕk**rJcJ(#. *)'MCIOULE' wei gh-au tomät i on :"Autometes a weighing process for Iiquids .;, CCIMPRI SES'

' nlúULl' wei ghi ng-ef e tem :"Ëontrol. and moni toring of weighing proceEs t'or liquids .

;'TÐ{T' Functisn "This Ís E demo specific¡tion of å EyEtem that monitors uleighing ofliquida. I ts main componeniÊ. årÊ iuo subsysiem-c.: l-- thÈ ini tisli¡àtion suÞeystem lweigh-ini t- the run time system lweigh-rts. ";'CC¡¡TPRI SES' .

'BUFFER' sceles-reading,AND''llODLlLE' wei gh-i n i t

, AND''Ì'IOÞULE' wei ch-r is:nNeighing run time system ";, CSHPRI SES'

' FR0CEDUF.E' run-wei ghi ng :

'RunE the weighing process o;'UPDATES' li quid-i tem-counter;' CCNSUHE$' scaìes-readi ng;'TER.YINATED-BY' stop-bu t ton ;' STÊRTED_BY' starr-bu t rcn ;' OCCUPI ES' wei gh-con troller'ENO' run-weighÍng

' -:ND' we i gh-r t s' EÌ.lD' wei Sh¡ nS-system,AND''ÌIODULE' evaluarion ¡

"EualuateE weighing data from lweighing-system o

'END'evaluetion,AI\D''MODULE' opertstor-interfaee

' END' wei gh-autometi on ; .

Fisure 1 8: Sample Contents Report (with Default Pararneter Values)

• "Textual language"• "Based on a set of fixed types for""entities and relationships"

[Ludewig et al. 1985]"[Glinz&Ludewig 1986]"[BBC 1986a, 1986b]"

1984-1987: SPADES"


• "Tool supported incremental specification and rich textual reporting"• "Very limited capabilities for graphic output"

_il

il

Il

1l

il

il

il

il

SPÀDES Tool User's Manual -65-

11.3 Representation Modes

Two aspects of a specification can be analyzed graphically:- The hierarchical aspect, showing the hierarchical embedding of an object (tne

hierarchy is formed by the COMPRISES-relation)- the environmental aspect, showing the non-hierarchical embedding of an object,

i.e. its dataflow' tining, resource occupation, etc. reLationships to otherobjects.

The hierarchy (or tree) representation mode is used to analyze the hierarchicalaspect (figure 43). The environment (or star) uode and the dataflow mode showthe environmental aspect (figure 44), Dataflow mode is a subset of the envi-ronment mode showing dataflow relationships only.

-Tree-Print-Change-(

Fiqur e 44: Graphics display in envÍronment mode

II

I

¡

¡

t)

il

it

il

il

lt

il

il

I:-ll'-ll

r{€igtFcontrol ler

sceles-reading

üEec

nrn-*eighiqf

start-button

operato

alert

SPADES 2.3 o ttfqe: Versron t9 I 10:47 has bac

I

1986-1991: SA/RT"

❍  In 1986, the first practically usable tools for graphic modeling of dataflow diagrams appeared on the market"

❍  Tools for graphic modeling eventually killed SPADES"❍  Learned and taught SA/RT: Structured Analysis with real

time extensions"❍  Teaching it taught me how to make it practically applicable"


A crystallization point: "Tool exhibition at ICSE ’87"in Monterey"

[Ward&Mellor 1985] [Hatley&Pirbhai 1987]"

• Software through Pictures by IDE"• Teamwork by Cadre"• Statemate by AD CAD / David Harel" and many more ..."

SA/RT: A textbook example"


r --Conlrol Speed ---rr¡lrtt

PedalDe

Í

Deslred_Speed

d

fleached_Deslred_

--'8pee-dtr\r-\

IIPedal i

I

Overrlde ìI\t \

It

Brakd¡.Engageô..

"-.)

"'ù

s

s1ControlSpeed

rnsl;\*Runnlng - - ->

s1Drlver_Fequ6st1',

Crulse'----connna-f¡'j

ConlrolSpeed

Throttle_Posltlon Throttle_

Posltlon ConlrolSpeed

.4

MalntalnSpeed

.2

lncreassSpeed

TestPedalDeflectlon

.3

.5

ClearSpeed

1

SelectSpeed

s0

[Cadre 1986]"

SA/RT: ... and a real-world example"


ü

oJoEE'(D

o(clC)u,

(oJIoàI

J

1.1;58Run Off

FædbeckPoütrSupdyl2

lnhlblll

Slalurf

Statu¡lnt.ñrl

Dlagnætlcf)¡t¡_RunOff

Choppcrconñgurrlkrn Stetu!

FccdbackElowcrPræcuruFlllcrcd <-

FccdbeckBlowerPressurc

Fcodback ------Contactor!l

lnhibil

FeedbackPowerSupplyl 2

CommandOpcnLlneContactors

EnorCarLoglc

GlobdRært

CommandVducl

CommandCommonVducLonVoIagc

Command¡Tc¡t

Error

todcCommand¡

----Gommendcont ctoË1

Command----Conllctorll

todcCommands

lro-sccTÐ(cr(D

\(4

I

ChoppcrConflgur¡tlon

¿a

'Ttc=C)rio=qr_

U,-tt(Dc)õ'Itõ':t

o)m:Ero,JooG)

s2Command

s3Conrmand

--->¡lotoringContactorl

Command--Þeparatlon

Contactotl

Command Command---)Blower

Contaclorl

R.!rt_Contþl

.4

Stdurcontrol

.3

.2

Release

5

tonhorlngContac-toÉ

Contaclorl

s4

Conlactorl

s5

Closlng

lYalFor

NoOperaüon

Te¡tStrb

LowVoltageo

Lowvoltagê=l

ReleaseArrrt(Ïf

ArmOff

LlneContacþrsStatus=l

=1

Openlng

Corst_ilotorlng_Braklng

RheostaticBraklngOnly

Offstato

Forrrrdon/

ReleaseArmOff/

Rh.o.tadcorú

Rheostaücûff/

WalForG¡obalRæêt

Closlng

GlobalResetl=1ReleaseArnûff/

St¡tus=1

Closlng

ésqiL,,f,

1.1-sl;37Charg ingContactorControl ChargingContactorExlsts=1

o¿oÌtEoao(oC)v,

(oJIoèI

J

-1'o¡(c¡o\o.

'Tlcfc)õ'=or_(n1t(Dc,õ9)a;

(¡)m:Ero)JooG)J

lF GlobalReset is one lor more than 10...200msTHEN generate GlobalReseton

Source: ABB"

1991: The rise of object-oriented modeling"

❍  Inherent problems and weaknesses of SA/RT"❍  Started investigating object-oriented modeling"

"


[Glinz 1991]"

tl.Timm (Hrsg.f

RequirementsEngineeringtgl

"Structured Analysis" und venrandte AnsätzeMarburg, April 1991

Proceedings

Springer-Verlag

ØÁfäâ

K@)q¿ \;P

Probleme und Schwachstellen derStrukturierten Analyse

Martin GlinzABB Informatikschule

CH-5405 Baden

ZusammenfassungDie Sfrukturierte Analyse (SA) hat - gemessen an wichtigen Bedürfnissen u¡dRandbedingungen heutiger Software-Entwicklung - erhebliche Schwachstellen.Diese betreffen insbesondere das fehlende Information Hiding und verschiedeneProbleme im Zusammenhang mit der Verzahnung von Spezifikation tmdEntwurf.Die sogenannte "object-oriented Analysis" löst die Probleme von SA nur zum TeiIund schafft dabei neue Probleme.Die festgestellten Schwachstellen können teilweise behoben bzw. umgangenwerden. Es gibt aber Probleme, die sich nicht lösen lassen, ohne den methodi-schen Rahmen von SA zu sprengen.Eine Skizze der Richtung, in die eine moderne, graphisch orientierte, teilformaleSpezifikationstechnik entwickelt werden müßte, schließt den Beitrag ab.

EinleitungStruktu¡ierte Analyse (SA) ist eine der derzeit populärsten graphischen, teil-formalen Techniken fü¡ die Spezifikation von Software. Unter StrukturierterAnalyse verstehe ich in diesem Beitrag eine Familie sehr eng verwandter Spezifi-kationstechniken, welche auf dem Grundprinzip von hierarchisch zerlegtenDatenfluß-Diagrammen basieren. SA wurde erstmals in den Büchern vonDeMarco (1978) und von Gane und Sarson (1979) systematisch beschrieben. SAwird teilweise auch als 'Yourdon-Methode'bezeichnet, weil Yourdon vor allemdurch Schulung erheblich zu¡ Verbreitung von SA beigetragen hat. Zur heutigenStn¡ktu¡ierten Analyse gehören fi.ir mich sowohl die Weiterentwicklung vonMcMenamin und Palmer (1984) mit event partitioning und Hinzunahme derDatenmodellierung (Entity-Relationship-Diagramme) als auch die Echtzeit-Erweiterungen von Ward und Mellor (1985) bzw. von Hatley und Pirbhai(1987).

1991-2011: Object-oriented modeling"

❍  Hierarchically decomposed object models [GI-RE’93]"

❍  based on scenarios and statecharts [ESEC 1995]"

❍  ADORA [ASE 1998, Inf. Syst. 2002, ASE 2006, ICSE 2008, ...]"

❍  Our focus activity for many years"


of requirements"

ADORA"

❍  A language and tool for object-oriented specification of software-intensive systems"

❍  Basic concepts"●  Modeling with abstract objects"●  Hierarchic decomposition of models"●  Integration of object, behavior and interaction modeling"●  Model visualization in context with generated views"●  Adaptable degree of formality"


[Berner et al. 1998]"[Glinz et al. 2002]"[Reinhard et al. 2006]"[Reinhard et al. 2008]"and many more"

Requirements Engineering – A Personal Reflection "© 2017 Martin Glinz" 26"

The ADORA Tool – A Short Demo"

A context diagram as an abstract overview of the model"



Expand the system node to see its inner structure"



View more detail: zoom into LicenseAdministrator"



Get a simplified view by projection: hiding external agents"



Zoom into LicenseServer"



Enrich the model by displaying system behavior"



Viewing the state information in more detail"

33"


Empty space for editing is generated automatically"


Eventually, ADORA did not make it"

due to"❍  Our inability to develop the tool prototype into a product"

❍  The dominance of UML"Despite the weaknesses of UML as a requirements language"


Proceedings of the 10th International Workshop on Software Specification and Design (IWSSD-10), San Diego, November 2000. 11-22.

Problems and Deficiencies of UML as a Requirements Specification Language

Martin GlinzInstitut für Informatik, Universität Zürich

Winterthurerstrasse 190CH-8057 Zurich, Switzerland

[email protected]

AbstractIn recent years, UML has become a standard language

for modeling software requirements and design.In this paper we investigate the suitability of UML as a

semiformal requirements specification language. Usingthe Teleservices and Remote Medical Care (TRMCS) casestudy as an example, we identify and demonstrate variousproblems and deficiencies of UML, particularly concern-ing use case models and system decomposition.

We also investigate whether and how the deficienciescan be overcome and how potential alternatives couldlook.

Keywords: UML, requirements specification, model, usecase, decomposition

1 IntroductionSemiformal modeling languages are a powerful means

of describing requirements. Such languages have a longtradition, starting about 25 years ago with PSL/PSA [23],SADT [20] and Structured Analysis [5]. About ten yearsago, object-oriented specification languages appeared ([3],[4], [22] and many others). A few years ago, the object-oriented approaches were consolidated into UML [21].

The structured languages like DeMarco’s StructuredAnalysis [5] were plagued by many problems, in particularthe paradigm mismatch between analysis and design,missing locality of data definitions, only partial informa-tion hiding and no types [8]. Object-oriented modelinglanguages were proposed to overcome these problems.However, the early object-oriented specification languagesalso had serious deficiencies, particularly due to theirinability to model dynamic and behavioral aspects of asystem. Jacobson [14] tried to overcome these defects byintroducing the notion of use cases. UML [21] was createdwith the goals of unifying the best features of differentexisting languages and of creating an industry standard.

However, UML is not the ultimate answer to the prob-lem of creating a good language for semiformal modelingof requirements. In this paper, we identify several defi-ciencies of UML as a language for requirements specifi-cation. We select issues from the Teleservices and RemoteMedical Care (TRMCS) case study representing typical

requirements specification problems. We try to modelthese issues with UML and discuss the difficulties en-countered.

We do not attempt a comprehensive analysis of theweaknesses of UML. In particular, we do not systemati-cally analyze the omissions, inconsistencies, vaguenessesand comprehensibility problems in the partially overcom-plex and ill-structured metamodel of UML and in the defi-nition of UML semantics. Considering the size of theUML 1.3 specification (over 800 pages), this would be amajor research endeavor. Furthermore, when looking atthe rapid evolution of UML versions, the results wouldprobably be outdated before completion.

The rest of this paper is organized as follows. In section2 we outline the case study. In sections 3 and 4 we identifydeficiencies in UML concerning use case models and sys-tem decomposition. In section 5 we investigate whetherthe deficiencies can be overcome by using UML extensionmechanisms. Finally, we sketch a potential alternative toUML.

2 The case studyAs a case study we use the Teleservices and Remote

Medical Care System (TRMCS) which was defined byInverardi and Muccini for this workshop [7]. As this casestudy is rather open, we add more precise requirementsand design decisions where appropriate. The high-levelgoals and constraints of the TRMCS and some high-levelsystem design decisions are summarized below.

Business/system requirements for the TRMCSGoal. The TRMCS shall provide medical assistance to at-home or mobile patients.Subgoals.1. The TRMCS shall provide two main services for pa-

tients:• adequately service help calls issued by a patient• continuously telemonitor a patient’s health condition

and automatically generate a help call when neces-sary.

2. These services shall be available regardless of theactual geographic location of the patient (but withinthe limits defined by the service contract).

[Glinz 2000]"

2009 – today: Flexible modeling"

A somehow disturbing observation:"Plain old text + Rich Pictures won the Next Top Model Contest at RE’09"Hmmm."

"Spawned our work on flexible, lightweight modeling"❍  A Very Lightweight Modeling Language [RE’10] "

❍  FlexiSketch [REFSQ 2011, ASE 2013, RE’15, ICSE 2015]"


[Glinz 2010], [Wüest&Glinz 2011]"[Wüest et al. 2013, 2015a, 2015b]"

FlexiSketch"

❍  Support a flexible sketching / modeling process"❍  Allow users to define their own notations / languages on the fly"❍  Co-evolve models and metamodels"


Liberating Modelers from the Tyranny of a Strict Modeling Language"

Modeling!

Meta-!Modeling!

Sketch!Recognition!

Freeform sketching

Assign meanings

through annotations

Identify similar symbols

beautification

Automatic inference

Mobile"

Collaborative"Multi-Platform"

FlexiSketch in Action"


REQUIREMENTS

20 IEEE SOFTWARE | W W W.COMPUTER.ORG/SOFT WARE | @IEEESOFT WARE

discovery.3 One such solution is the Collaborative Creativity Canvas (see Figures 2b and 4). Facilitators can use it to foster creativity and replace the often frustrating requirements negotiation process with a lively cocreation process. It aims to turn stakeholder conflicts into opportuni-ties for innovation.

Although Martin’s research in-cluded traditional literature reviews, expert opinion, and practitioner sur-veys, it was driven largely by industrial collaboration. Ideas conceived in in-dustry were iteratively and incremen-tally improved as they moved back and forth between the lab and practice. As such, Martin’s creativity solutions re-sulted from industrial partnerships and not through the more traditional model in which an idea emerges from research and then incubates in a lab for five years before the finished prod-uct is offered to industry.

Martin explained that this project revealed the benefits of industrial co-design, especially through the ongoing guidance and feedback he obtained. He pointed out that working with in-dustry didn’t produce short-sighted research because he had the time and

freedom to consider, and explore, in-novative ideas throughout the process.

ArchieArchitectural knowledge and re-lated quality concerns are often un-documented and tacit. So, develop-ers often lose track of early design decisions. For example, system-level qualities representing “nonfunc-tional” requirements tend to become eroded during refactoring, bug fix-ing, and other maintenance activities.

To address this problem, my re-search group at DePaul University de-veloped Archie (see Figures 2c and 5), an Eclipse plug-in.4 Archie focuses on requirements’ role in a project’s downstream design and maintenance phases. It parses source code and then automatically detects and visu-alizes a range of architectural tactics such as heartbeats, resource pooling, and role-based access control.

Archie was funded by grants from the US National Science Founda-tion and Department of Homeland Security and developed by Ahmed Fahkry (see Figure 6) and other stu-dents under Mehdi Mirakhorli’s su-pervision. To place Archie into prac-titioners’ hands, we released it on GitHub under Archie-Smart-IDE and on the Department of Home-land Security’s SWAMP (Software Assurance Marketplace).

Mirakhorli explained that one of the greatest challenges for technol-ogy transfer was in understanding the real users’ actual usage patterns. We addressed this through frequent iterations of prototyping, coding, and testing. However, the real test will come as industrial users adopt Archie in their development environments. As such, Archie is less advanced along the technology-transfer scale than FlexiSketch or Martin’s creative collaboration activities.

FIGURE 4. Participants in one of Martin Mahaux’s workshops use the Collaborative Creativity Canvas to explore innovative requirements ideas. For more details, see http://bit.ly/martinmahaux.

FIGURE 3. Martin Glinz, Norbert Seyff, Dustin Wüest, and Parisa Ghazi work with FlexiSketch. For additional information, visit www.ifi.uzh.ch/rerg/research/flexiblemodeling.html.

s1req.indd 20 12/9/14 3:02 PM

IEEE Software"32(1), p. 20"Jan/Feb 2015"

A FlexiSketch Teaser"






A personal paradigm shift"

DEFINITION [1993]. Requirements Engineering – The application of a systematic, disciplined, quantifiable approach to the specification and management of requirements; that is the application of engineering to requirements."

"DEFINITION [1998]. Requirements Engineering – Understanding and documenting the customers’ desires and needs."

"With the notion of stakeholders becoming pervasive, this became “the stakeholders’ desires and needs”"


Adapted from the definition of software engineering in IEEE Std. 610.12 [IEEE 1990]"

I came up with this definition in 1998 when writing a column on Requirements"Engineering for the newsletter of an IT company I had collaborated with."

A personal milestone"

41"

Conference Organization General Chair Robyn Lutz, Iowa State University and Jet Propulsion Lab, USA

Program Chair Martin Glinz, Universität Zürich, Switzerland

Local Arrangements Mats Heimdahl, University of Minnesota, USA

Financial Chair Jane Cleland-Huang, DePaul University, USA

Practitioner Tracks Ian Alexander, Independent Consultant, UK Frank Houdek, DaimlerChrysler Research, Germany

Workshops Mikio Aoyama, Nanzan University, Japan

Tutorials Nancy Day, University of Waterloo, Canada

Doctoral Symposium Betty Cheng, Michigan State University, USA

Posters and Demos Alain Wegmann, EPF Lausanne, Switzerland

Publicity Jeff Thompson, Guidant Corp., USA Sebastian Uchitel, Imperial College, UK

Webmaster Tobias Reinhard, Universität Zürich, Switzerland

Registration Ramesh Bharadwaj, Naval Research Laboratory, USA

Proceedings Samuel Fricker, ABB Research and Univ. Zürich, Switzerland

Program Board (associate program chairs) Betty Cheng, Michigan State University, USA Sol Greenspan, National Science Foundation, USA Neil Maiden, City University London, UK Bashar Nuseibeh, The Open University, UK Klaus Pohl, Universität Duisburg-Essen, Germany Colette Rolland, Université Paris 1, France Motoshi Saeki, Tokyo Institute of Technology, Japan Alistair Sutcliffe, UMIST, UK Roel Wieringa, Universiteit Twente, The Netherlands

Program Committee Annie Antón, USA Ian Alexander, UK Daniel Amyot, Canada Mikio Aoyama, Japan Joanne Atlee, Canada Daniel Berry, Canada Jaelson Castro, Brazil Marsha Chechik, Canada Daniela Damian, Canada Nancy Day, Canada Eric Dubois, Luxembourg Christof Ebert, France Martin Feather, USA Steve Fickas, USA Anthony Finkelstein, UK Xavier Franch, Spain Donald C. Gause, USA Vincenzo Gervasi, Italy Carlo Ghezzi, Italy Holger Giese, Germany Michael Goedicke, Germany Orlena Gotel, USA Anthony Hall, UK Jane Hayes, USA Mats Heimdahl, USA

Constance Heitmeyer, USA Patrick Heymans, Belgium Frank Houdek, Germany Pankaj Jalote, India Marina Jirotka, UK Natalia Juristo, Spain Søren Lauesen, Denmark Julio Leite, Brazil Michel Lemoine, France Emmanuel Letier, Belgium Nazim Madhavji, Canada John Mylopoulos, Canada Andreas Opdahl, Norway Barbara Paech, Germany Oscar Pastor, Spain Björn Regnell, Sweden Bill Robinson, USA Kevin Ryan, Ireland Guttorm Sindre, Norway Erik Simmons, USA Tetsuo Tamai, Japan Jeffrey Thompson, USA Alain Wegmann, Switzerland Eric Yu, Canada Didar Zowghi, Australia

Call for Papers and Proposals

Understanding the stakeholders’ desires and needs Requirements engineering has increasingly become a dominant activity in systems development—the more we can generate or outsource design and construction, the more we need requirements that adequately reflect the stakeholders’ desires and needs. The IEEE International Requirements Engineering conference is the premier requirements engineering con-ference, providing a forum for researchers, practitioners, educators, and students to present and discuss the most recent innovations, trends, experiences, and concerns in the field of requirements engineering. Topics of interest include, but are not restricted to: requirements elicitation, analysis, documentation, validation, and verification; requirements specification languages, methods, processes, and tools; require-ments management, traceability, viewpoints, prioritization, and negotiation; modeling of requirements, goals, and domains; formal analysis and verification; prototyping, simulation, and animation; evolution of requirements over time, product families, and variability; relating requirements to business goals, archi-tecture, and testing; social, cultural, and cognitive factors in requirements engineering; domain-specific problems and solutions.

Paper categories We invite submissions of high quality papers in the following categories: Technical solution papers present solutions for requirements-related problems which are novel or significantly improve existing solutions. A technical solution paper must include a preliminary validation of the proposed solution. Scientific evaluation papers evaluate existing problem situations or validate proposed solutions with scientific means, i.e. by empirical studies, experiments, case studies, simulations, formal analyses, mathe-matical proofs, etc. Scientific reflection on problems and practices in industry also falls into this category. Industrial practice and experience papers present problems or challenges encountered in practice, relate success and failure stories, or report on industrial practice. The focus is on ‘what’ and on lessons learned, not on an in-depth analysis of ‘why’. Otherwise, consider submitting a scientific evaluation paper. Vision papers sketch new ways of looking at things, present creative new ideas, rethink current notions, etc. Please note that this is not a forum for research proposals or immature technical solution papers. More details about the paper categories and the corresponding evaluation criteria are provided on the conference web pages. Papers must not describe work submitted to or presented at other forums. Accepted papers will be published in an IEEE CS Press Conference Proceedings and will be available in the IEEE CS Digital Library.

Submission information Submissions will be handled electronically at the RE’06 web site. Authors without web access must make advance arrangements with the Program Chair at least one week before the deadline. Technical solution papers and scientific evaluation papers must not exceed 10 pages. Industrial practice and experience papers and vision papers must not exceed 6 pages. Submissions must be formatted according to the IEEE CS proceedings format (see http://www.computer.org/portal/pages/ieeecs/publications/cps/cps_forms.html for templates and instructions). The detailed submission instructions will be published at www.re06.org.

Other contributions We also invite proposals for tutorials, workshops, panels, doctoral symposium contributions, posters, and research demonstrations. Details are specified on the conference web pages.

Important dates Paper abstracts February 6, 2006 Paper submissions (all categories) February 13, 2006 Tutorial, workshop, and panel submissions March 6, 2006 Notification of authors April 24, 2006 Doctoral symposium submissions May 2, 2006 Poster and research demonstration submissions May 2, 2006



1 8 I E E E S O F T W A R E P u b l i s h e d b y t h e I E E E C o m p u t e r S o c i e t y 0 7 4 0 - 7 4 5 9 / 0 7 / $ 2 5 . 0 0 © 2 0 0 7 I E E E

requirements engineering (RE) in softwareand systems development.“Understanding the Stakeholders’ Desires

and Needs” was also the theme of the14th IEEE International Require-

ments Engineering Conference.1

From the RE ’06 conferenceand its theme, the idea forthis special issue emerged.We invited authors of RE’06 papers that specificallydealt with stakeholder is-sues to submit a practice-

oriented view of their work.After a round of IEEE Soft-

ware peer review, we chosetwo of these submissions for this

issue. We also solicited contributions

in a public call for papers and chose two of thesesubmissions after review. In addition, the issuecontains a technical opinion piece on stakehol-ders in global RE and a Point-Counterpoint debate.

Identifying the stakeholdersStakeholder identification precedes any other

RE activity: we must first determine who theyare and how important they are.

Suppose we want to elicit and document asoftware system’s requirements. To identify therelevant stakeholder roles, we look for personsor organizations who

■ have an active interest in the system becausethey’ll actually use it or are directly involvedin processes that the system will change;

focusStakeholders in RequirementsEngineering

To build a useful system, we need to know its requirements;to know its requirements, we need to know the stakehold-ers’ desires and needs. The term stakeholder generalizes thetraditional notion of customer or user in requirements en-

gineering to all parties involved in a system’s requirements (see thesidebar “What Is a Stakeholder?”). The growing attention being paidto stakeholders’ needs and desires reflects the growing importance of

guest editors’ introduction

Martin Glinz, University of Zurich

Roel J. Wieringa, University of Twente

A guest editors’ introduction"with > 100 citations"





2003: Two disturbing questions"

Why not just code what the stakeholders desire and need?!Why can agile projects succeed with little or even no RE?!

Hmmm.""

Another personal paradigm shift"DEFINITION [2003]. Requirements Engineering – Specifying and managing requirements to minimize the risk of delivering a system that does not meet the stakeholders’ desires and needs."

""


I created this definition when preparing an invited talk on Requirements Engineering at the Swiss Association for Quality"in September 2003. It is now part of the IREB Glossary of Requirements Engineering Terminology [Glinz 2014]."

A paradigm shift with consequences"

If RE is considered a means for controlling risk,"... then how much RE do we need?"

!What’s the value of requirements?!How can we achieve specifications that create optimal value? "


The value of requirements"

Value means"❍  The benefit of an explicit specification"

Bringing down the probability for developing a system that doesn’t satisfy its stakeholders’ expectations and needs to an acceptable level"

minus "❍  The cost of writing, reading and maintaining this

specification"


47"

The eleventh commandment ... of traditional RE"

Thou shalt quantify"

"... all your quality requirements"

"... to make them unambiguous and verifiable.""If it’s not measurable, make it measurable."

"

Regardless of the effort involved?"

Does this create optimal value?"


A new approach to quality requirements"


IEEE SoftwareVol. 25, No. 2 March/April 2008pp. 34-41"

This is part of my work on non-functional requirements. This work constitutes another story in my professional life which I skipped in this talk to keep it at a reasonable length. "[Glinz 2005, 2007, 2008, 2016]."





2012: Back to a fundamental problem"

How much to invest in RE"... to secure successful communication of desires and needs"

... between stakeholders and developers?"

"à "Study the problem of " "" "shared understanding"


Das Ptoblert',

o

iBvers no

oo

UhAn

vollslåndigef orderunse

lnFormot¡k

und l,õ¡tris¡cn

ul!roa

U)ie sfell' ;oLs Jor,danit meine Anweder

greìf en ?es be

oC'

ID

v49 e 7¡ele

AnwcndunF¡ch¡liss¿n

I

, Ivnrealisf isch e Erv¡,p,rlu

lnfornoliKern

i"h's

?

ìe sagmeìnen

/ /// / )

Shared Understanding"

“The ticketing system shall provide discounted tickets which are for sale only to skiers staying in one of the resort’s hotels and are valid from the first to the last day of the guest’s stay.”"

"Do all involved parties have the same understanding of this requirement?"

If so, do we need to specify it explicitly or can we rely on implicit shared understanding?"

"



Comput Sci Res Dev (2015) 30:363–376DOI 10.1007/s00450-014-0256-x

SPECIAL ISSUE PAPER

On shared understanding in software engineering: an essay

Martin Glinz · Samuel A. Fricker

Published online: 1 July 2014© Springer-Verlag Berlin Heidelberg 2014

Abstract Shared understanding is essential for efficientsoftware engineering when the risk of unsatisfactory out-come and rework of project results shall be low. Today, how-ever, shared understanding is used mostly in an unreflected,ad-hoc way. This affects the quality of the engineered soft-ware solutions and generates re-work once the quality prob-lems are discovered. In this article, we investigate the role,value, and usage of shared understanding in software engi-neering. We contribute a reflected analysis of the problem,in particular of how to rely on shared understanding that isimplicit, rather than explicit. After an overview of the state ofthe art we discuss forms and value of shared understanding insoftware engineering, survey enablers and obstacles, compileexisting practices for dealing with shared understanding, andpresent a roadmap for improving knowledge and practice inthis area.

Keywords Shared understanding · Software engineering ·Implicit shared understanding

1 Introduction and motivation

Shared understanding between stakeholders and softwareengineers is a crucial prerequisite for successful develop-ment and deployment of any software system [8,17,37,55].A stakeholder is a person or organization that has a (director indirect) influence on a system’s requirements [30]. End

M. Glinz (B)Department of Informatics, University of Zurich, Zurich, Switzerlande-mail: [email protected]

S. A. FrickerSoftware Engineering Research Laboratory, BlekingeInstitute of Technology (BTH), Karlskrona, Swedene-mail: [email protected]

users, customers, operators, and managers are typical exam-ples of stakeholders.A software engineer is a person involvedin the specification, design, construction, deployment, evo-lution, and maintenance of software systems. Requirementsengineers, architects, developers, coders, and testers areexamples of common software engineering roles.

In traditional development projects, shared understandingamong and between stakeholders and software engineers isachieved by eliciting requirements and producing a compre-hensive requirements specification. In agile environments,stories, up-front test cases, and early and continuous valida-tion of an incrementally developed software system serve thesame purpose.

Shared understanding among a group of people has twofacets: explicit shared understanding (ESU) is about inter-preting explicit specifications,1 such as requirements, designdocuments, and manuals, in the same way by all group mem-bers. Implicit shared understanding (ISU) denotes the com-mon understanding of non-specified knowledge, assump-tions, opinions, and values. The shared context provided byimplicit shared understanding reduces the need for explicitcommunication [51] and, at the same time, lowers the risk ofmisunderstandings.

Explicit shared understanding based on specifications isratherwell understood today. In particular, research and prac-tice in Requirements Engineering have contributed practicesfor eliciting requirements, documenting them in specifica-tions and validating these specifications, see, for example,[2,3,23,25,50,60]. In contrast, the role and value of implicit

1 In the normal case, explicit specifications are captured in writing.Principally, however, explicit verbal communication remembered byall team members is also a form of explicit shared understanding, albeita rather volatile one.

123

Can we rely on implicit shared understanding?"

This requires:"❍  Low probability for misunderstandings"

❍  Reduction of impact of misunderstandings"❍  Impact = "

●  Cost for detection and correction"+"●  Cost created by "• "Non-satisfied stakeholders" " " " " " " " "• "Rework"

à "We need techniques for building and assessing shared "" "understanding"

53"How Much Requirements Engineering Do We Need? "© 2017 Martin Glinz"

Towards a bright future of RE"

New emerging topics"❍  Requirements evolution"❍  User feedback, runtime monitoring, requirements mining"❍  Complementarity of requirements and product design: a

new paradigm shift for RE on the horizon"

A comeback of requirements modeling?"

Requirements Engineering is ina healthy and thriving state"


RE@40April 24-28, 2017 · Kappel am Albis, Switzerland

RE@40·

Forty Years of Requirements Engineering– Looking Forward and Looking Back


with whom I had/have the pleasure to work with"... due to many engaged people"

...and many others who worked with me or were advised by me""

Let me say thank you"

To all of my former and current PhD students and Postdocs,"

To my academic teachers and peers, as well as my colleagues from practice,"

To my students and course participants,"

To my wife and my family,"

And to everybody in the audience for honoring me with their presence today."


References"

BBC Brown Boveri (1986a). SPADES Language Manual, version 2.3. Document Ex CTT 86/30."BBC Brown Boveri (1986b). SPADES Tool User’s Manual, version 2.3. Document Ex CTT 86/33."S. Berner, S. Joos, M. Glinz, M. Arnold (1998). A Visualization Concept for Hierarchical Object Models. 13th IEEE Conference on Automated Software Engineering (ASE 1998), Honolulu, Hawaii. 225–228."Cadre Technologies Inc. (1986). Cruise Control Requirements. White paper (Note 54, 11 Jul 86)."T. DeMarco (1979). Structured Analysis and System Specification. New York: Yourdon Press."M. Glinz, J. Ludewig (1984). SEED – Das Datenbanksystem für die Software- Entwicklungsumgebung SEEME. Brown Boveri Research Center, Research Report KLR 84-143 C."M. Glinz, J. Ludewig (1986). SEED – A DBMS for Software Engineering Applications Based on the Entity-Relationship Approach. 2nd International Conference on Data Engineering, Los Angeles. 654–660."M. Glinz (1991). Probleme und Schwachstellen der Strukturierten Analyse. In M. Timm, (ed.): Requirements Engineering ’91. Informatik-Fachberichte vol. 273, Berlin: Springer. 14–39."M. Glinz (1993). Hierarchische Verhaltensbeschreibung in objekt-orientierten Systemmodellen – eine Grundlage für modellbasiertes Prototyping. GI-Symposium Requirements Engineering ’93. Report no. 41 of the German Chapter of the ACM, Stuttgart: Teubner. 175–192."M. Glinz (1995). An Integrated Formal Model of Scenarios Based on Statecharts. In W. Schäfer and P. Botella (eds.): Software Engineering – ESEC’95. Proceedings of the 5th European Software Engineering Conference, Sitges, Spain. Lecture Notes in Computer Science 989, Berlin: Springer. 254–271."


References – 2"

M. Glinz (2000). Problems and Deficiencies of UML as a Requirements Specification Language. Tenth International Workshop on Software Specification and Design. San Diego, Ca. 11–22."M. Glinz, S. Berner, S. Joos (2002). Object-Oriented Modeling with ADORA. Information Systems 27(6):425–444."Glinz, M. (2005). Rethinking the Notion of Non-Functional Requirements. Third World Congress for Software Quality (3WCSQ 2005), Munich, Germany, Vol. II, 55-64."M. Glinz (2007). On Non-Functional Requirements. 15th IEEE International Requirements Engineering Conference (RE’07), Delhi, India. 21–26."M. Glinz, R.J. Wieringa (2007) Stakeholders in Requirements Engineering. IEEE Software 24(2):18–20."M. Glinz (2008). A Risk-Based, Value-Oriented Approach to Quality Requirements. IEEE Software 25(2):34–41."M. Glinz (2010). Very Lightweight Requirements Modeling. Invited contribution, 18th IEEE International Requirements Engineering Conference (RE’10), Sydney, Australia. 385–386."M. Glinz (2014). A Glossary of Requirements Engineering Terminology, Version 1.6. International Require-ments Engineering Board (IREB). https://www.ireb.org/de/downloads/#cpre-glossary, visited 2017-05-06"M. Glinz, S.A. Fricker (2015). On Shared Understanding in Software Engineering: An Essay. Computer Science – Research&Development 30(3-4): 363–376."M. Glinz (2016). How Much Requirements Engineering Do We Need? Softwaretechnik-Trends 36(3):19–21."


References – 3"

D. Harel (1987). Statecharts: A Visual Formalism for Complex Systems. Science of Computer Programming 8(3):231–274."D.J. Hatley, I.A. Pirbhai (1987). Strategies for Real-Time System Specification. New York: Dorset House."G. Hommel, D. Krönig (eds.)(1983). Requirements Engineering. GI working conference, Friedrichshafen, Germany. Informatik-Fachberichte vol. 74, Berlin: Springer."IEEE (1990). Standard Glossary of Software Engineering Terminology. IEEE Std 610.12-1990. IEEE Computer Society Press."J. Ludewig (1983). ESPRESO - A System for Process Control Software Specification. IEEE Transactions on Software Engineering 9(4): 427–436."J. Ludewig, M. Glinz, H. Huser, G. Matheis, H. Matheis, M. F. Schmidt (1985). SPADES - A Specification and Design System and Its Graphical Interface. 8th International Conference on Software Engineering (ICSE’85), London, UK. 83–91."T. Reinhard, C. Seybold, S. Meier, M. Glinz, N. Merlo-Schett (2006). Human-Friendly Line Routing for Hierarchical Diagrams. 21st International Conference on Automated Software Engineering (ASE 2006), Tokyo, Japan. 273–276."T. Reinhard, S. Meier, R. Stoiber, C. Cramer, M. Glinz (2008) Tool Support for the Navigation in Graphical Models. 30th International Conference on Software Engineering (ICSE 2008), Leipzig, Germany. 823–826."D. T. Ross (Ed.) (1977). Special Collection on Requirement Analysis. IEEE Transactions on Software Engineering SE-3(1).""


References – 4"

D. T. Ross (1977). Structured Analysis (SA): A Language for Communicating Ideas. IEEE Transactions on Software Engineering SE-3(1):16–34."D. Teichroew and E. A. Hershey III (1977). PSL/PSA: A Computer Aided Technique for Structured Documentation and Analysis of Information Processing Systems. IEEE Transactions on Software Engineering SE-3(1):41–48, 1977."P.T. Ward, S.J. Mellor (1985). Structured Development for Real-Time Systems, Vol. I-III. Englewood Cliffs, N.J.: Prentice-Hall."D. Wuest, M. Glinz (2011). Flexible Sketch-Based Requirements Modeling. 17th International Working Conference on Requirements Engineering: Foundation for Software Quality (REFSQ 2011), Essen, Germany. 100–105."D. Wüest, N. Seyff, M. Glinz (2013). Semi-automatic Generation of Metamodels from Model Sketches. 28th International Conference on Automated Software Engineering (ASE 2013), Palo Alto, Ca. 664–669."D. Wüest, N. Seyff, M. Glinz (2015a). FLEXISKETCH TEAM: Collaborative Sketching and Notation Creation on the Fly. 37th International Conference on Software Engineering (ICSE 2015), Volume 2, Florence, Italy. 685–688."D. Wüest, N. Seyff, M. Glinz (2015b). Sketching and Notation Creation with FlexiSketch Team: Evaluating a New Means for Collaborative Requirements Elicitation. 23rd IEEE International Requirements Engineering Conference (RE’15), Ottawa, Canada. 186–195."

A comprehensive list of my publications is available at http://www.ifi.uzh.ch/en/rerg/publications.html."


Documents

Requirements Engineering - UZH92e16808-9399-4a2d-9105-a...Requirements Engineering – A Personal Reﬂection "© 2017 Martin Glinz" 2" Das Ptoblert',o iBvers o n o o Uh An vollslåndige