MSWE2 Methodik der Softwareentwicklung 2

(1)

21.04.2005Requirements Engineering im Überblick1

Requirements Engineering im Überblick P a u lG rü n b a ch e r

(2)

The Challenge: Avoiding Requirements Mismatches

(3)

Stakeholder: A u sg a n g sp u n kt je d e r A n fo rd e ru n g se rm itt lu n g Wichtige Stakeholder

!

K u n d e n

!

Benutzer

!

Entwickler Beispiele

!

C o n te n t-Ve ra n tw o rt lic h e

!

D o m ä n e n e xp e rt e n

!

Fachleute für Marketing

!

U sa b ili ty -E xp e rt e n

!

Verantwortliche für Markt- und Zielgruppenanalysen

!

…

(4)

Beispiele für Stakeholder-Ziele

Die Web-Anwendung muss mit 1. September 2004 online verfügbar sein (Vorgabe des Auftraggebers). Die Web-Anwendung muss gleichzeitig mindestens 2500 Benutzer unterstützen (Qualitätsziel des Auftraggebers). Als Entwicklungsplattform soll J2EE zum Einsatz kommen (Technologieerwartung der Entwickler). Die Übertragung sämtlicher Geschäftsdaten muss gesichert erfolgen (Qualitätsziel des Benutzers). Die Benutzerschnittstelle muss Layouts für unterschiedliche Kundengruppen ermöglichen (Qualitätsziel des Auftraggebers). Ein beliebiger Benutzer muss in der Lage sein, mit der Web-Anwendung ein gewünschtes Produkt innerhalb von drei Minuten zu finden (Usability- Zieldes Auftraggebers). Der Benutzer soll durch Auswahl eines Symbols jederzeit die im Warenkorb befindlichen Artikel anzeigen können (Funktionsziel eines Benutzers).

(5)

Software / IT Challenges 30% of software development projects fail. 7 0 % o f t h e r e m a in d e r

!

Are over budget by 189%

!

B e h in d s ch e d u le b y 2 2 2 % More than 50% of this trouble is caused by in a d e q u a te r e q u ir e m e n ts d e fin iti o n .

(352 companies, 8000 Projects. Source: The Standish Group, 199(352 companies, 8000 Projects. Source: The Standish Group, 1995)5)

(6)

0%5%10%15% Lack of User Input Incomplete Requirements & Specifications Changing Requirements & Specifications Lack of Executive Support Technology Incompetence Lack of Resources Unrealistic Expectations Unclear Objectives Unrealistic Time Frames New Technology Lack of Planning Didn't Need it Any Longer Lack of IT Management Technology Illiteracy Other

% of Responses Project Challenged Factors Project Impaired Factors

Project Challenges Source: 352 US Companies, 8000 Projects, The Standish Group, 1994

(7)

Perceived R elative Importance of Software Problems in Europe

^Reqûirêmên^ts

Spe cif ica tio n

Pro jec

t men age Man

t

Managing Cu

sto mer Rqt s

Lac k o f Q S

Lack of Stan dards

System Analysis

& D esi gn

Doc um en tat ion

Software and System Testing

Con fig ura tio

n men age Man

t

Sof tw are in sta lla tio

n ort upp d S an

Cod in g

Source: European Software Institute, TR 95104, www.esi.es, ESSI Project No. 11000, ESPITI, 3800 companies, 17 European countries

(8)

Einleitung Anforderungen spielen für die Qualität von Software-intensiven Systemen eine entscheidende Rolle. Nach wie vor Probleme mit Anforderungen

!Unklar spezifiziert !Fehlerhaft !Unvollständig !Instabil !...

D ie F o lg e n

!Mangelnde Akzeptanz durch die Benutzer !Fehlplanungen !Inadäquate Softwarearchitekturen !…

(9)

Woher kommen Anforderungen? Die Beteiligten und Betroffenen der A n w e n d u n g se n tw ic kl u n g (s ta ke h o ld e r) m it ih re n Z ie le n u n d E rw a rt u n g e n b ild e n d e n A u sg a n g sp u n kt je d e r A n fo rd e ru n g se rm itt lu n g . S ta ke h o ld e r s in d P e rs o n e n o d e r O rg a n is a tio n e n , d ie d u rc h e in e z u e n tw ic ke ln d e A n w e n d u n g b e tr o ff e n s in d u n d e in e n d ir e kt e n o d e r i n d ir e kt e n E in flu ss a u f d ie A n fo rd e ru n g e n n e h m e n .

(10)

Audience Survey - I What is your role in the product requirements p ro ce ss ?

!

Sa le s & m a rk e tin g

!

E n g in e e ri n g

!

Executive

!

R e se a rc h & d e ve lo p m e n t

!

End user

(11)

Audience Survey - II Which of these play a significant part in your o rg a n iz a tio n ’s t yp ic a l r e q u ir e m e n ts a p p ro a ch ?

!

Prose documents

!

Requirements specification tools

!

Prototyping

!

Business case analysis

!

St a ke h o ld e r w in -w in c o n ce p ts

(12)

Audience Survey - III What are your major concerns with your o rg a n iz a tio n ’s t yp ic a l r e q u ir e m e n ts a p p ro a ch ?

!

Takes too long to do well

!

Too many defects

!

Too hard to keep up with change

!

Ke y s ta ke h o ld e rs e xc lu d e d

!

T o o b u re a u cra tic

(13)

Spiral RE Prozess

(G. Kotonyaand I. Sommerville1998)

Requirements elicitation Requirements analysis and negotiation Requirements documentationRequirements validation

Informal statement of requirements Agreed requirements Draft requirements document

Requirements document and validation report

Decision point: Accept document or re-enter spiral START

(14)

Wichtige Aufgaben des RE E rm itt e ln u n d V e rh a n d e ln d e r A n fo rd e ru n g e n B e sc h re ib e n d e r A n fo rd e ru n g e n P rü fe n d e r A n fo rd e ru n g e n V e rw a lte n d e r A n fo rd e ru n g e n

(15)

Ermitteln der Anforderungen Anforderungen können nicht durch simple Befragung d e r St a ke h o ld e r g e w o n n e n w e rd e n . Anforderungen sind das Ergebnis eines gemeinsamen L e rn - u n d K o n se n sb ild u n g sp ro ze ss e s. Für diese Aufgabe existieren zahlreiche Methoden:

!

Kreativitätstechnik en

!

Szenariobasierte Methoden

!

M u lti kr ite ri e lle E n tsch e id u n g sve rf a h re n

!

Moderationstechnik e n

!

Interviews

!

D o ku m e n te n a n a ly se

!

…

(16)

Beschreiben der Anforderungen Die ermittelten Anforderungen müssen in einer projektgemäßen Form in einem Anforderungsdokument b e sc h ri e b e n w e rd e n . Es existieren zahlreiche Beschreibungsformen:

!

Informale (z.B. User Stories aus eXtreme P rogramming)

!

Semi-formale (z.B. Anwendungsfälle)

!

Formale (z.B. Z) Wahl der Beschreibungsform hängt ab von:

!

P ro je kt ri si ko

!

Adres satenkreis (Stakeholder und deren Vorwissen)

(17)

Prüfen der Anforderungen Dies umfasst

!

V a lid ie ru n g (» H a b e n w ir d a s R ic h tig e s p e zi fiz ie rt ? « )

!

Verifikation (»Haben wir richtig spezifiziert?«) V e rf a h re n

!

R e vi e w s

!

In sp e kt io n e n

!

Prototyping

!

…

(18)

Verwalten der Anforderungen Ä n d e ru n g e n s in d e in w e se n tli ch e s M e rk m a l v o n S o ftw a re -P ro je kte n . A n fo rd e ru n g e n s in d in d e r Regel nicht statisch, sondern Änderungen u n te rw o rf e n . D a s V e rw a lte n v o n A n fo rd e ru n g e n ( R e q u ir e m e n ts M a n a g e m e n t ) unterstützt:

!

E in b ri n g e n n e u e r A n fo rd e ru n g e n

!

Än d e ru n g e n b e st e h e n d e r An fo rd e ru n g e n

!

Ve rw a ltu n g d e r Ab h ä n g ig ke ite n z w is ch e n Anforderungen sowie Beziehungen zu anderen En tw ic kl u n g se rg e b n is se n ( tr a ce a b ili ty )

(19)

Beschreibungsformen Stories (z.B. wie in Extreme Programming) D ia g ra m m e ( z. B . U se C a se D ia g ra m m e ) Formatierte Spezifikationen (z.B. Use C ases) Formale Spezifikationen (z.B. Z ) .. .

(20)

User Story U m g a n g ss p ra ch lic h e B e sc h re ib u n g e n g e w ü n sc h te r E ig e n sc h a fte n , d ie e in g e se tz t w e rd e n , u m e in g e m e in sa m e s V e rs tä n d n is zw is ch e n K u n d e n u n d E n tw ic kl e rn h e rz u ste lle n .

(21)

Diagramme

Cora 1 Function (PAC)

Conflict Detector Calculate Resolution(s) Adjacent Sector Controller

Inititate Calculation of Resolution(s) Environment Data

Arrival Manager Sequencing Tool

En-route Manager Sequencing Tool ControllerManage Co- ordination Request

Update System with Resolution Trajectory(ies)

Indicate Availability of Resolution

Rank Resolution(s)<<uses>> <<uses>> <<uses>>

Flight Data Processor System Co-ordinator

Calculate Cost Value

<<uses>> <<uses>> Display Best-Ranked Resolutions

<<uses>> See Details of a Resolution

<<uses>> Handle Input of Resolutions

<<uses>> <<uses>>

Manage Co-ordination Reciept <<uses>>

Flight Data Processor Departure Manager Sequencing Tool

(22)

Formatierte Spezifikationen

(23)

15.10. 2004WinWin1

WinWin Requirements Negotiation Paul Grünbacher Jo h a n n e s Ke p le r U n iv e rs ity L in z P a u l . G r u e n b a c h e r @ j k u . a t

(24)

15.10. 2004WinWin2

M a n y a p p ro a ch e s fo r m o d e lin g a n d d e sc ri b in g re q u ir e m e n ts Stories, Prosa, Use Cases, Formatted S pecs, etc.

Attribut Kommentar Beispiel Identifikation Eindeutiger Bezeichner 1.2.5 TypElement aus Anforderungs- taxonomieErlernbarkeit Beschreibung Kurze natürlichsprachliche ErklärungDas System soll von gelegentlichen Webanwendern ohne zusätzliche Schulung benutzt werden können BegründungErläuterung, warum eine Anforderung Teil der Spezifikation ist Rund 40% der erwarteten Kunden sind gelegentliche Webanwender QuelleWer ist Ansprechpartner für die Anforderung bzw. welches Dokument ist Grundlage der Anforderung

Leiterin des Marketing AbnahmekriteriumEine messbare Bedingung bei deren Erfüllung die Anforderung als abgenommen gilt

90% der Mitglieder einer zufällig ausgewählten Testgruppe gelegentlicher Webanwender können die Anwendungsfälle UC2.3, UC2.6, UC2.9 und UC2.11 ohne vorhergehende Schulung anwenden Priorität Angabe der Wichtigkeit und ggf. auch der Realisierbarkeit einer Anforderung

10; 5 Abhängige AnforderungenAlle von dieser Anforderung abhängigen Anforderungen1.2.7, 2.3.4, 2.3.6 Konfliktäre AnforderungenAlle Anforderungen die mit dieser Anforderung in Widerspruch stehen

4.5.6 Weiterführende Informationen Verweise auf weiterführende Informationen Usability Guidelines v1.2 VersionDient zur Erfassung der Entstehungsgeschichte einer Anforderung

1.06

BankkundeDemo-User

Anmelden Abmelden Girokonten verwalten Sparkonten verwalten Hilfe benutzen

Passwort ändern TAN verwalten Geschäftsbedingungen lesen

Kontakt aufnehmen

Wertpapierdepot verwalten

How do we get there? Acquisition Elicitation N e g o ti a ti o n

(25)

15.10. 2004WinWin3

WinWin Success-critical stakeholders jointly negotiate th e r e q u ir e m e n ts f o r a s o ft w a re d e ve lo p m e n t project to achieve mutually satisfactory so lu tio n s.

(26)

15.10. 2004WinWin4

Who Are The Stakeholders? C u st o m e rs U se rs Programmers Architects D o m a in E xp e rt s

Analysts M a rk e tin g Sales Management …? Why is negotiation s o im p o rta n t?

(27)

15.10. 2004WinWin5

Understanding and Resolving Conflicts Conflicts are inevitable. Achieving mutually satisfactory agreements is critical for building trust and managing expectations.

(Boehm, Port, Al Said, 2000)

(28)

15.10. 2004WinWin6

Adapting to change T h e re is n o c o m p le te a n d w e ll- d e fin e d s e t o f r e q u ir e m e n ts waiting to be d is co ve re d .

(29)

15.10. 2004WinWin7

Understanding and Meeting Constraints R e q u ir e m e n ts d e p e n d o n a va ila b le re so u rc e s a n d ca p a b ili tie s.

(30)

15.10. 2004WinWin8

Sharing Knowledge Users, customers, m a n a g e rs , d o m a in experts, and d e ve lo p e rs h a ve t o share different skills, b a ck g ro u n d s, a n d e xp e cta tio n s.

(31)

15.10. 2004WinWin9

Fostering Team Learning Requirements emerge from a process of co -o p e ra tiv e le a rn in g in which they are explored, prioritized, negotiated, evaluated, and d o cu m e n te d .

(32)

15.10. 2004WinWin10

Developing Shared Commitments Conflicts are in e vi ta b le . N e g o tia tio n is c ri tic a l to a ch ie ve m u tu a lly

satisfactory a g re e m e n ts .

(33)

15.10. 2004WinWin11

WinWin Negotiation Model

Win ConditionWin Condition AgreementAgreement OptionOption

IssueIssue involves addresses adopts

covers Win Condition: Desired objective of an individual stakeholder Issue: Conflict, risk, uncertainty on a win condition Option:A way of overcoming an issue Agreement: A mutual commitment to an option or win condition WinWin Equilibrium State -All Win Conditions covered by Agreements -No outstanding Issues (Boehm et al. 1994)

(34)

15.10. 2004WinWin12

(0) Identify Success-critical Stakeho lders (1) R eview a n d expand negotiation topics (2) B rainstorm stakeholder interests (3) C onverge on Win Conditions (4) Capture a glossary of Terms (5) Prioritize W in Conditions (6) Reveal Constraints and Assumptions (7) Identify Issues and Options (8) Negotiate Agreements

E a s y W in W in P ro c e s s

(35)

15.10. 2004WinWin13

(36)

15.10. 2004WinWin14

Example 1: F lood and Av alanc he C ont rol

Methodsand Tools forAssessingRisksin Alpine Regions One Day Kick-Off Meeting !26 Stakeholders fromdifferent domains !~400 brainstorming contributions !~150 Win Conditions !Detailed analysis of priorities and conflicts

(37)

15.10. 2004WinWin15

Example 2: Graphical Weather Forecast Editor C o m p le x g ra p h ic a l e d ito r fo r t h e m e te o ro lo g is t

RISC Software GmbH

(38)

15.10. 2004WinWin16

(39)

15.10. 2004WinWin17

(40)

15.10. 2004WinWin18

(1) Review and Expand Negotiation Topics Objective: refine, and customize the outline of n e g o tia tio n t o p ic s. H o w : C o u ld -b e , S h o u ld -b e Result: Shared Outline that helps to

!

stimulate your thinking,

!

o rg a n iz e y o u r w in c o n d iti o n s, a n d

!

serves as a completeness checklist for negotiations.

(41)

15.10. 2004WinWin19

Stakeholders negotiate about …

Enterprise ArchitectureProject Context Business Case Requirements Gathering and Analysis Functional RequirementsNon-Functional RequirementsFuture Requirements Runtime Non-runtimeQualities Business TechnologyConstraints

(42)

15.10. 2004WinWin20

(2) Brainstorm Stakeholder Interests Objective: Share perspectives, views, b a ck g ro u n d , e xp e ct a tio n s How: Anonymous, rapid b ra in st o rm in g Result: An unstructured set of comments about their vested interests (w in c o n d iti o n s)

(43)

15.10. 2004WinWin21

People submit and share ideas about their win conditions using electronic d is c u s s io n s h e e ts

(44)

15.10. 2004WinWin22

(3) Converge on Win Conditions Objective: Build and organize win conditions How: Structured discussion to converge on key w in c o n d iti o n s Result: List of clearly stated, unambiguous win co n d iti o n s

(45)

15.10. 2004WinWin23

Team builds a clean list of win conditions and organizes win conditions into pre-defined buckets

(46)

15.10. 2004WinWin24

(4) Capture a Glossary of Terms O b je ct iv e : D e fin e a n d s h a re m e a n in g o f im p o rt a n t te rm s. How: Initial definitions based on stakeholder statements; joint review Result: A glossary of terms with definitions and stakeholder statements showing usage of terms

(47)

15.10. 2004WinWin25

The team crafts definitions for important terms used in the project

(48)

15.10. 2004WinWin26

(5) Prioritize win conditions Objective: Scope project, gain focus How: Vote on Business Importance & Ease of R e a liz a tio n Result: Prioritized win conditions

(49)

15.10. 2004WinWin27

“Maybe later” “L o w H a n g in g F ru it s ” “Forget them” “I m p o rt a n t w it h h u rd le s ” After voting, win conditions are displayed in fo u r c a te g o rie s

(50)

15.10. 2004WinWin28

(6) Reveal Constraints and Assumptions O b je cti ve : S u rfa ce a n d u n d e rs ta n d h id d e n a ss u m p tio n s H o w : A n a ly ze p ri o ri tiz a tio n p o ll t o r e ve a l h id d e n a ss u m p tio n s, d iffe re n t p e rc e p tio n s, … Result: Comments, Issues, sometimes Options

(51)

15.10. 2004WinWin29

Red cells indicate lack of Red cells indicate lack of consensus. consensus. O ra l d is c u s s io n o f c e ll O ra l d is c u s s io n o f c e ll graph reveals unshared graph reveals unshared in fo rm a ti o n , u n n o ti c e d in fo rm a ti o n , u n n o ti c e d assumptions, hidden assumptions, hidden issues, constraints, etc. issues, constraints, etc.

(52)

15.10. 2004WinWin30

(7) Identify Issues and Options Objective: Explore candidate issues and o p tio n s; U n d e rs ta n d is su e s a n d o p tio n s How: Develop/Review pass for Issues and Options Result: A WinWin Tree

!

Win conditions

!

Issues

!

Options

(53)

15.10. 2004WinWin31

Issues are captured as subheadings to win conditions

(54)

15.10. 2004WinWin32

Elaborate Options O p tio n s a re c a p tu re d a s subheadings to issues

(55)

15.10. 2004WinWin33

(8) Negotiate Agreements O b je ct iv e : N e g o tia te a g re e m e n ts How:

!

Adopt win conditions that raised no issues as agreements;

!

Adopt options as agreements Result: A WinWin Tree:

!

Win conditions

!

Issues

!

Options

!

A g re e m e n ts

(56)

15.10. 2004WinWin34

A g re e m e n ts a re c a p tu re d a s s u b h e a d in g s to options and win conditions

(57)

15.10. 2004WinWin35

Next Generation Tool Support: EasyWinWin Cognito E m p h a si ze s D is tr ib u te d R e q u ir e m e n ts N e g o tia tio n D e liv e re d a s A cti ve M e th o d o n C o g n ito Based on EasyWinWin Process In te rn e t- e n a b le d Scalable A rchitecture http://www.groupsystems.com

(58)

15.10. 2004WinWin36

The WinWin Spiral Model T h e W in W in S p ir a l M o d e l is Risk-Driven R is k s d e te rm in e - p rocess, - level of detail, - u se of tools, etc.

(59)

15.10. 2004WinWin37

Why Use WinWin ? T h e a lte rn a tiv e s d o n ’t w o rk .

!

Win-lose often leads to lose-lose. Avoids costly rework.

!

100X cost to fix requirements after delivery. B u ild s tr u st a n d m a n a g e s e xp e cta tio n s.

!

Looking out for other’s needs builds trust.

!

Balancing needs leads to realistic expectations. H e lp s s ta ke h o ld e rs a d a p t t o c h a n g e .

!

Shared vision and the flexibility of quick re- n e g o tia tio n .

(60)

21.04.2005Detaillierung nicht-funktionaler Anforderungen1