Hierarchie der Anforderungen in der Business Analyse

Transkript

1 Hierarchie der Anforderungen in der Analyse Entstanden aus einer Diskussion zwischen H. Ferraz-Leite (CBAP), Erich Freitag und Peter Gerstbach Erich Freitag Chapter Meeting in Wien 1

2 Agenda in der Analyse Grundsätzliches zu Klassifizierung von Hierarchie der Fragestellungen zu Konsistenz von Diskussion, Erfahrungen, 2

3 Vorstellung Erich Freitag Inhaber der PQRST e.u. Unterstützung zu organisatorischen Fragestellungen und Engineering- Aufgaben Schriftführer IIBA Austria Chapter Viele Jahre in Software Engineering, Engineering, Analyse, Entwicklung und Qualitätsmanagement tätig vorwiegend im Umfeld sicherheitskritischer IT- und Kommunikationssysteme für öffentliche Auftraggeber Daraus u.a. Gerichtssachverständiger für Übertragungs- und Informationstechnik 3

4 Erfahrungen Das Pferd beim Schwanz aufzäumen Wir brauchen ein xy-system! 4

5 Grundsätzliches Grundsätzliches zu : Ein Requirement (deutsch: Anforderung) im Sinne der Analyse ist nahezu alles, was die Vergangenheit, die Gegenwart oder die Zukunft von Organisationsthemen betrifft - von Strukturen über Rollen und Prozesse bis hin zu jeglicher Art von Regeln und Vorgaben. Neu im BABOK V3: a usable representation of a need. Substituting, this is: "a usable representation of a problem, opportunity or constraint with potential value to a stakeholder. (preliminary) Eine der wesentlichen Aufgaben der Analyse ist es sicherzustellen, dass die Anforderungen allen Beteiligten bekannt sind und auch von allen (in gleicher Weise) verstanden werden. 5

6 Grundsätzliches Requirement Flow: dfd Requirement states [Traced] [Traced] [Traced] 3.2 Conduct Elicitation Activity 3.2 Elicitation Results 5.1 Define 4.2 Manage Traceability 4.2 [Traced] 4.1 Manage Scope and Need [Communicated] 5.1 Need 3.3 Document Elicitation Results 4.3 Maintain for Re-Use 4.3 [Maintained & Reusable] 4.5 [Communicated] [Communicated] 5.5 Case 3.3 [Stated] [3, 4, 6] 4.1 [Approved] 4.5 Communicate [Communicated] 3.3 [Stated, Unconfirmed] 4.4 Package 3.4 Confirm Elicitation Results 3.4 [Stated & 4.4 Prepare Package Confirmed] 6.1 Prioritize 7.4 Define 7.4 except [Stated] 6.5 Verify Organize or [Prioritized and Approved] 6.2 Structure 6.3 Specify and Model [Analyzed] [Verified] 7.2 Allocate 6.1 [Prioritized] [Prioritized and Validated] 7.5 Validate Requiremens [Verified] 7.1 Assess Proposed [Verified] 7.2 [Allocated] 6.6 Validate [Validated] [Verified] 6

7 Grundsätzliches Requirement Flow: dfd Requirement states [Stated] 3.3 [Stated, Unconfirmed] 4.1 [Approved] 4.5 [Communicated] [Communicated] 4.5 Communicate 6.1 Prioritize 3.4 Confirm Elicitation Results 3.4 [Stated & Confirmed] Verify 7.4 Define 7.3 Organizational Readiness Assessment [Deployed] [Designed] 6.6 Validate 6.6 [Validated] 6.5 [Verified] [Verified] 7

8 Grundsätzliches Requirement States: 8

9 Klassifizierung Klassifizierung von : classification: 9

10 Klassifizierung : Die beschreiben Anforderungen aus der Gesamtsicht des Unternehmens classification: = Case Need Required Capabilities Scope 10

11 Klassifizierung : classification: Die beschreiben die Anforderungen aus Sicht der einzelnen oder aus Sicht von Gruppen von n 11

12 Klassifizierung : classification: Die sind jene Anforderungen, die eine Lösung beinhalten muss, um sowohl die als auch die zu erfüllen sie werden typisch in funktionale und nicht-funktionale Anforderungen unterteilt 12

13 Klassifizierung : classification: Die stellen eine Art Brücke zwischen den und den verschiedenen dar. 13

14 Klassifizierung : classification: Die beschreiben den Übergang vom derzeitigen Ist-Zustand in den künftigen Soll-Zustand 14

15 Warum eine Hierarchie? Eine BA-Workshop-Aufgabe Aufgabenstellung (vereinfacht): Finden Sie in einem Brainstorming Anforderungen zu folgender Ausgangssituation: 15

16 Warum eine Hierarchie? Ergebnis der BA-Workshop-Aufgabe Ergebnis nach Erklärung der Hierarchie und Zuordnung: 3 Req.s 9 Req.s 6 Req.s 10 Req.s 2 nicht zugeordnete Req.s 16

17 Hierarchie Hierarchie der Der Wert der Anforderungshierarchie ist, dass man die Analyse am richtigen Ende beginnt. Wird beispielsweise schon zu Beginn die Frage gestellt was soll die Lösung können? so ist dies zwei Ebenen zu tief, denn diese Frage lässt sich erst dann richtig beantworten wenn wir zuerst wissen, was die Zielsetzung ist (= ) und wenn wir dann wissen, welche was tun können müssen (= ), um die zu erreichen: 17

18 Hierarchie Das Pferd richtig aufzäumen 5.1.3: [Stated]: Elicitation must be performed in order to assist stakeholders in defining their perceived needs. Ensure that they reflect actual business, as opposed to describing solutions 18

19 Hierarchie Reihenfolge der Vorgangsweise werden in der enterprise analysis definiert werden in der analysis definiert werden in der analysis definiert Designed solution werden in der solution assessment and validation definiert 19

20 Hierarchie Lösungs-Hierarchie der sind die Lösung für die sind die Lösung für die sind die (Übergangs-)Lösung für die (und zum Teil auch für die ) 20

21 Hierarchie Tracing und Validierung von 4.2.3: and all stakeholder and solution must be traceable to a business requirement 6.6.2: validation is an ongoing process to ensure that stakeholder, solution, and transition align to the business 7.2.3: Scope: The solution scope allocates business to components and releases. The associated stakeholder and solution should match that allocation 21

22 Fragestellungen Fragestellungen bei Was wird auf der Ebene benötigt? (d.h. was ist die Zielsetzung aus der gesamten Unternehmenssicht?) Beispiel: neuer Vertriebsweg durch Online-Bestellplattform 22

23 Fragestellungen Fragestellungen bei Beispiel: neuer Vertriebsweg durch Online-Bestellplattform Wie machen wir das? Was benötigen die? 23

24 Fragestellungen Fragestellungen bei Wie machen wir das? Was benötigen die? Beispiel: für den Online-Kunden als einen der ergibt sich die Anforderung: der Online-Kunde muss eine Bestellung tätigen können. 24

25 Fragestellungen Fragestellungen bei Die Anforderung Bestellung tätigen benötigt zur Präzisierung eine Prozessbeschreibung, also beispielsweise: Kunde erfasst Produktcode -> System zeigt Produktinfo an -> Kunde gibt zu bestellende Anzahl an -> System prüft Lagerstand mit Lagersystem ab -> falls im Lager vorhanden Bestätigung an Kunden 25

26 Fragestellungen Fragestellungen bei Bestellung tätigen Wie sieht die Lösung aus? Was muss die Lösung können? 26

27 Fragestellungen Fragestellungen bei Wie sieht die Lösung aus? Was muss die Lösung können? Das System hat eine Erfassungsmaske für Produktcodes (oder eine Auswahlliste, eine Drop-Down- Box, eine Suchmaske, ) Das System hat eine Produktinfomaske. Anzuzeigende Infos sind: Produktbild, Preis, Lagerstand, 27

28 Fragestellungen Fragestellungen bei Das System hat eine Erfassungsmaske für Produktcodes, eine Produktinfomaske, Wie tut die Lösung das? Systemanalyse, Architektur, ( design) 28

29 Fragestellungen Fragestellungen bei Systemanalyse, Architektur, ( design) Was benötigen wir für den Übergang? 29

30 Fragestellungen Fragestellungen bei Was benötigen wir für den Übergang? Schulungen, Datenkonvertierung, Aussendung an Kunden, 30

31 Konsistenz Konsistenz von Die kommen von den Projektsponsoren. Diese finanzieren das Projekt und haben deshalb das Recht zu sagen, was die Zielsetzung ist und was nicht. 31

32 Konsistenz Konsistenz von Die kommen von den Usern, Kunden, Abteilungen, = den n. 32

33 Konsistenz Konsistenz von Die Aufgabe des Analysten ist es hier, divergierende Wünsche zwischen und zu hinterfragen bzw. zu klären. Was benötigen die, um die zu erfüllen? 33

34 Konsistenz Konsistenz von Die Aufgabe des Analysten ist es hier, die Lösungsanforderungen mit den und abzugleichen. Was muss die Lösung können, um die und die zu erfüllen? 34

35 Ende Diskussion, Fragen, Erfahrungen, Danke für Ihre Aufmerksamkeit!