Agiles requirements engineering

1. Agiles Requirements-Engineering
Daniel Fisher
daniel.fisher@devcoach.com

2. Lennybacon.com
Daniel Fisher | CTO & Software Architect
MCP, MCTS, MCPD…
daniel.fisher@devcoach.com
Mit-Gründer und Geschäftsführer von devcoach.com
www.devcoach.com
Mitglied von
www.solution-EXPERTS.de
Mit-Gründer und Vorstand der
gemeinnützigen www.just community.de e.V.
Veranstalter des größten Entwickler & IT-Pro
Community Events in Deutschland: www.nrwconf.de
Mit-Gründer und Leiter der
INETA Usergroup Düsseldorf
www.NetUG-NiederRhein.de
Mitglied im Microsoft
Community Leader & Insider Program (CLIP)
Connected Systems Advisory Board
Expertengruppe für WCF, WF & BizTalk

3. devcoach.com
• Leistungen
– Architektur-Beratung
• Strukturierter und effizienter zu einer wartbaren Anwendung.
– Prozessoptimierung
• BPM
• FDD, TDD, MSF Agile & SCRUM
– Software-Entwicklung
• Team-out-of-the-box (Near-shoring)
• Objektmodelle und Datenzugriff
• Kommunikations-Infrastrukturen
• Identitäts- und Berechtigungsmodelle
• Web 2.0 und Rich Internet Applikation
– Coaching & Training
• Technologien schneller verstehen und richtig einsetzen.
• Technologien
– Microsoft Windows & .NET Framework
• ASP.NET, WCF, WF, WPF, Silverlight & Geneva
• Kunden
– Versicherung, Finanzindustrie, Mittelstand, Handel, Kommunikation,
Softwarehersteller u.v.a.
• Bundesamt für Sicherheit in der Informationstechnologie, Microsoft,
Dresdner Bank…
Project
Experience
Technology
Know-how
devcoach®

4. Agile Anforderungsanalyse...

5. Warum sind die Anforderungen so wichtig?

6. Der Erfolg eines Software-Projektes hängt von
verschiedenen Faktoren ab!

7. Heisst das wenn man eine Anforderungsanalyse
betreibt erhält man gute Software?

8. Die bloße existenz ist keine Garantie
Wie bei allen anderen Faktoren!

9. Das ist nicht nur in der Software-Industrie so...

10. Ein Brot ist immer so gut wie seine Zutaten und
sein Bäcker

11. Oder?

12. Wenn aus Eisen kein Gold werden kann...
kann ein Prozess allein keine Gute Software
machen!

13. Sehen wir uns die "Zutaten" mal an...

14. Customer Requirements

15. Functional Requirements

16. Non-functional Requirements

17. Derived Requirements

18. Allocated Requirements

19. Stakeholder identification

20. Stakeholder interviews

21. Requirements lists

22. Measurable goals

23. Prototypes

24. Use cases

25. Und trotzdem...

27. Sehen wir uns das Problem mal genauer an...

28. Der Kunde weiss gar nicht was er will?

29. Der Kunde will eine Software!
Wenn er ein Auto kauft muss er das ABS dazu
auch nicht selbst erfinden...

31. Der Kunde weiss gar nicht wie er die
Anforderungen formulieren soll?

32. Der Kunde hat ein Geschäft, dass er kennt!
Zu 99,9% ist das nicht das schreiben von
Anforderungen...

33. Die Anforderungen des Kunden ändern sich mit
der Zeit!

34. Die Welt dreht sich. Märkte ändern sich!
Warum sollten Anforderungen in Stein
gemeisselt sein...

35. Die Kommunikation mit dem Kunden ist schwer!

36. Jeder spricht die Sprache seiner Fachdomäne!
Techniker auch...

37. Der Kunde hat keine Ahnung von Technologie

38. Woher soll der Kunde die Technologie kennen
wie wir? Kennen wir seine Fachdomäne wie er?

39. Der Kunde versteht den Entwicklungs-Prozess
nicht!

40. Verstehen wir seinen Geschäftsprozess
ohne, dass er diesen erklärt?

41. Der Entwickler verfasst oder interpretiert
Anforderungen!

42. Der Entwickler kennt die Technologie!
Nicht die Fachdomäne...

43. OK, Probleme identifiziert!

44. Aber wie kann uns "Agil" helfen?

45. Agil != Funky

46. agil <Adj.> [frz. agile < lat. agilis]
(bildungsspr.): von großer Beweglichkeit
zeugend; regsam, flink, gewandt und wendig
(bes. Körperlich und geistig).

47. Messen, messen, messen!
Nicht nur einmal raten!

48. Ein Projekt hat ein meist fixes Budget
Für das Software Programmiert werden kann

49. Ein Projekt hat ein meist eine Deadline
Bis zu der Software Programmiert werden kann

50. Agilität heisst Kurskorrekturen ein zu planen
Das Ziel genauer zu treffen!

51. Wie kann man denn Aufwände schätzen wenn
der Umfang nicht von vorne herein klar ist?

52. Heisst das nicht, dass vieles doppelt entwickelt
wird?

53. Ist so ein Ansatz denn schon Reif?

54. Ein Beispiel aus einem Projekt...

55. The Manual

56. Small iterations Gather
Requirements
Design
DevelopTest
Review

57. Und die Tools?

58. A fool with a tool is still a fool!
Besonders bei agilen Methoden!