Jak opisać wymagania zamawiającego wybrane elementy Adam Rzeźnicki, Grzegorz Sobolewski PIIT Listopad, 2012
Agenda Kontekst ma znaczenie - na przykładzie cyklu wytwórczego systemu aplikacyjnego Rodzaje wymagań Interesariusze i ich perspektywy Opis Przedmiotu Zamówienia poprzez pryzmat wymagań i interesariuszy 2
Kontekst ma znaczenie Aplikacja 1 OPZ Wymagania Analiza wymagań Projektowa nie rozwiązania Budowa i testy Testy akceptacyjne Odbiór i wdrożenie produkcyjne Utrzymanie i rozwój Faza zamówienia Faza realizacji i utrzymania Wymagania Zarządzanie programami /projektami Zarządzanie zmianami Zarządzanie Architekturą Korporacyjną Aplikacja n OPZ Wymagania Analiza wymagań Projektowa nie rozwiązania Budowa i testy Testy akceptacyjne Odbiór i wdrożenie produkcyjne Utrzymanie i rozwój Faza zamówienia Faza realizacji i utrzymania 3
Kontekst ma znaczenie Aplikacja 1 OPZ Wymagania Analiza wymagań Projektowa nie rozwiązania Budowa i testy Testy akceptacyjne Odbiór i wdrożenie produkcyjne Utrzymanie i rozwój Faza zamówienia Faza realizacji i utrzymania Wymagania Zarządzanie programami /projektami Zarządzanie zmianami Zarządzanie Architekturą Korporacyjną Aplikacja n OPZ Wymagania Analiza wymagań Projektowa nie rozwiązania Budowa i testy Testy akceptacyjne Odbiór i wdrożenie produkcyjne Utrzymanie i rozwój Faza zamówienia Faza realizacji i utrzymania 4
Rodzaje wymagań Wymagania funkcjonalne Wymagania niefunkcjonalne - Bezpieczeństwo - Wydajnościowe - Interoperacyjność/kompatybilność z pozostałymi komponentami ekosystemu IT - Niezawodnościowe - Wdrożeniowe - Utrzymaniowe - Prawne - etc. 5
Interesariusze i ich perspektywy Bazuje na uwzględnieniu zróżnicowanych grup interesariuszy Zorganizowana jest w układ 4 fundamentalnych widoków Widok Biznesowy Widok Funkcjonalny Widok Techniczny Grupy interesariuszy Widok Implementacyjny 6
Interesariusze Interesariusze to osoby lub organizacje, które: mają(bezpośredni lub pośredni) wpływ na rezultat projektu będą(bezpośrednio lub pośrednio) pod wpływem projektu 7
Cztery widoki/perspektywy rozwiązania Widok Biznesowy Dlaczego tym się zajmujemy (jakie są motory)? Dlaczego potrzebujemy, z czego to wynika, jak mierzyć Widok Funkcjonalny Co rozwiązanie będzie robić? Jakich dostarczy informacji? Jakie właściwości, jakie usługi, którzy użytkownicy Niezależny od technologii, produktów, implementacji Widok Techniczny Jak będzie zbudowane rozwiązanie, jaka będzie jego struktura, ramy, składniki, sposób zarządzania? Widok aplikacji, danych, interfejsów, infrastruktury Widok Implementacyjny (Jak, kim, kiedy ) W oparciu o jakie produkty, usługi, narzędzia, procesy, jakich ludźmi, w jakiej lokalizacji, w jakim czasie i budżecie, itd, rozwiązanie będzie zaimplementowane? 8
Widoki i typowe grupy interesu Widok Biznesowy Główne grupy interesu Zarząd, dyrektorzy i kierownicy, zamawiający rozwiązania, analitycy Funkcjonalny Techniczny Implementacyjny Użytkownicy rozwiązań, właściciele procesów, projektanci Dostawcy rozwiązań, konsultanci techniczni, dostawcy podsystemów Manager projektu, dostawcy rozwiązań, testujący rozwiązania, rozwijający rozwiązania, użytkownicy/operatorzy/kierownicy 9
Analogia do budowy domu: cztery widoki/perspektywy Biznesowy Dlaczego chcę nowy dom? Pożądany Funkcjonalny Co da mi nowy dom? Implementacyjny Jak i z czego zostanie zbudowany? Możliwy Techniczny Jak będzie wyglądał po wybudowaniu? 10
Grupy interesu przy budowie domu 11 Widok Biznesowy Dlaczego chcę zbudować nowy dom? (prestiż, inwestycja, rozrywka, mieszkanie) Sponsor Widok Funkcjonalny Jakie będzie posiadał cechy i udogodnienia? (cisza, bezpieczeństwo, rozkład pokoi, ogród) Użytkownik Widok Techniczny Jak zostanie zbudowany? (materiały, media, komunikacja) Budowniczy Projektant Widok Implementacyjny W jaki sposób będzie następowała realizacja? (finansowanie, zaopatrzenie, model, fazy)
Perspektywa biznesowa Dlaczego to robimy? Kluczowe pytania Jakie są wewnętrzne i zewnętrzne motory? Jakie są modele biznesu i procesy biznesowe? Kto bierze udział w procesach biznesowych? Jakie są cele realizacji projektu? Jak będzie mierzony sukces wprowadzanego rozwiązania? 12
Perspektywa funkcjonalna Co powinno zapewniać rozwiązanie? Kluczowe pytania Co zapewni kompletne rozwiązanie? Jak będzie ono wykorzystane i jakich nowych usług dostarczy? Jakich informacji będzie dostarczało? Do kogo? Jakie właściwości powinno posiadać rozwiązanie? 13
Perspektywa techniczna Jak powinno działać rozwiązanie? 14 Kluczowe pytania W jaki sposób system powinien być zbudowany i jaką posiadać strukturę? Jakie są niezbędne interfejsy zewnętrzne i inne wymagania? Jakie aplikacje i dane są potrzebne? Jak wygląda niezbędna infrastruktura? Jakie standardy zostaną zastosowane? Jak zostanie osiągnięta wymagana jakość systemu?
Perspektywa implementacyjna W jaki sposób rozwiązanie zostanie zbudowane? Kluczowe pytania 15 Jakie specyficzne produkty i komponenty, od jakich dostawców, są potrzebne do zbudowania systemu? Jak rozwiązanie będzie wspierane i rozwijane? Jakie metody walidacji będą zastosowane? Jak będzie wyglądało zarządzanie projektem? Jakie jest źródło finansowania? Jak przeprowadzić zmiany i jaki będzie ich wpływ przy przechodzeniu od stanu obecnego do docelowego?
Opis Przedmiotu Zamówienia poprzez pryzmat wymagań i interesariuszy Specyfikacja wymagań Wymagania funkcjonalne Wymagania niefunkcjonalne SMART (S)pecific znaczące, jednoznaczne, (M)asurable mierzalne, zarządzalne, (A)ttainable osiągalne, przypisywalne, (R)elevant realistyczne, zorientowane na rezultaty, (T)imely osadzone w ramach czasowych, umożliwiające ich śledzenie, Śledzenie i zarządzanie wymaganiami 16
Opis Przedmiotu Zamówienia poprzez pryzmat wymagań i interesariuszy Perspektywa BIZNESOWA Perspektywa FUNKCJONALNA DLACZEGO? CO? Perspektywa IMPLEMENTACYJNA Perspektywa TECHNICZNA W JAKI SPOSÓB? JAK? 17
Pytania
Dziękuję