Cześć,
Tutaj Szymon z Analizowac.pl
Zawsze się powtarza że ludzie w większości przypadków mają problem z wyborem tego czego chcą. Ale o wiele prościej jest im powiedzieć czego nie chcą albo co im się nie podoba lub co ich boli. No i tutaj to już jest z górki bo jak rozmawiamy z interesariuszami to o wiele prościej jest się dowiedzieć tego że:
- Na tą czynność która jest bezmózgowa traci tydzień swojej pracy a można ją zautomatyzować w 80%
- Tutaj musi ręcznie rozesłać 30 maili gdzie zmienia tylko część treści dla wybranej osoby
- Tutaj jest śliski temat bo powinno się to robić w sposób X ale ja robię to ręcznie i muszę to robić w sposób Y
A w przypadku gdy interesariusz ma już punkt odniesienia w postaci systemu to jest jeszcze łatwiej
- Tutaj muszę za każdym razem odświeżać stronę
- Ten proces powinien być online a jest liczony przez 24 godziny
- Te dane są bezużyteczne i można je ukryć
- Tutaj system się zawiesza
- To robimy poza systemem bo to rozwiązanie jest do niczego
- To trzeba parametryzować bo co chwila zgłaszamy zmianę
- Ten ekran jest tak nieintuicyjny że nowi pracownicy tracą masę czasu na wdrożenie
- itd.
Problem z wymaganiami
No i tutaj przeważnie każdy z nas stara się tak prowadzić rozmowę z interesariuszem żeby utworzyć prosty system który będzie łatwy w implementacji i w utrzymaniu przy okazji będzie rozwiązywał wszystkie punkty bólu i był napisany w postaci pozytywnej. Czyli w klasycznych „User stories”, „Przypadkach użycia”, „System powinien…”, diagramach UML, BPMN itd. No i w taki sposób czy tego chcemy czy nie to narzucamy rozwiązanie. Czy to jest ok? Czasem tak, czasem nie. Przecież wymagania muszą definiować rozwiązanie. Szczególnie te niefunkcjonalne. Pomijam tutaj kwestię dwuznaczności czy spójności wymagań.
A z wymaganiami mało kto chce dyskutować. Wynikają one z potrzeby i celu do zrealizowania. A z celem projektu to już nikt nie chce dyskutować. No chyba że pojawia się wycena która mocno wykracza budżet projektowy. Wtedy zastanawiamy się co zrobić żeby było taniej i żeby spełniało to wymagania w jak największym stopniu.
No i teraz pojawia się kwestia tego kto jest w stanie najbardziej obniżyć wycenę? Dostawca czy klient zmieniając wymagania? No odpowiedź nie jest jednoznaczna.
Inne podejście
Nie ukrywam że chciałbym tym wpisem wywołać dyskusję. Natknąłem się na fajne case study z projektu CMSa który miał za zadanie obsługiwać wnioski o przyznanie grantów. Wszystko odbywało się w sposób papierowy i manualny. Dlatego postanowiono to oprogramować.
I w tym projekcie postanowiono że wymagania będą przedstawione w sposób odwrotny niż zwykle. Wymagania zostały przedstawione w sposób w którym skupiono się na pokazaniu problemów do rozwiązania. A za propozycję wszystkich rozwiązań miał odpowiadać dostawca.
Przedstawienie tych wymagań nie tylko dotyczyło wymagań funkcjonalnych. W ten sam sposób przedstawiono ograniczenia, bezpieczeństwo, użyteczność, performance itd..
Przykładowe wymaganie z analizowanej dokumentacji.
| Zadanie C21 Podczas spotkania zarządu | To zadanie opisuje co robi członek zarządu z wnioskiem o grant podczas spotkania zarządu. |
| Start | Kiedy spotkanie i rozmowa się zaczyna |
| Koniec | Kiedy wszystkie wnioski o grant zostaną przedyskutowane |
| Częstotliwość występowania | Dwa razy w roku |
| Użytkownicy | Czterech członków zarządu i sekretarka patrzą na wnioski w tym samym czasie i zapisują swoje komentarze bezpośrednio w systemie. Zobacz uprawnienia sekcja H1 |
Ta tabelka to mi wymagań nie przypomina tylko taki opis założeń jakie można przyjąć. Dodatkowo dodano podzadania z czymś co chociaż trochę zaczęło przypominać wymagania aczkolwiek tez nimi nie jest. Napisano górnolotnie co trzeba zrobić i jakie są problemy przy takich zadaniach.
| Podzadanie | Propozycja rozwiązania | Kod |
| 1. Obserwuj wszystkie wnioski o grant. Zobacz to co inni członkowie spotkania skomentowali w wersji online(tak szybko jak tylko członek spotkania coś wpisze). Patrz na cały wniosek o grant w jednym widoku wraz z załącznikami które są od razu otwarte. | ||
| 2. Wprowadź swój komentarz do wniosku oraz wprowadź swoje prywatne notatki do wniosku | ||
| 3. Możliwość wprowadzenia komentarza podsumowującego wszystkie komentarze | ||
| 1p. Problem. Obecnie żeby zobaczyć komentarz innej osoby trzeba odświeżać co chwila stronę lub czekać aż dana osoba poruszy problem podczas dyskusji. | ||
| 2p. Problem. Obecnie żeby wprowadzić komentarz to trzeba wejść w osobną podstronę z formularzem przez co nie można podczas pisania komentarza jednocześnie przeglądać wniosku. | ||
| 3p. Problem. Ten sam problem co w 2p. |
Potem taki dokument trafiał do dostawcy oprogramowania i on proponował w jaki sposób może oprogramować dane zadanie przy okazji rozwiązując dany problem.
| Podzadanie | Propozycja rozwiązania | Kod |
| 1. Obserwuj wszystkie wnioski o grant. Zobacz to co inni członkowie spotkania skomentowali w wersji online(tak szybko jak tylko członek spotkania coś wpisze). Patrz na cały wniosek o grant w jednym widoku wraz z załącznikami które są od razu otwarte. | Tak jak w zadaniu C20 [zadanie C20 pokazuje listę wniosków, każda ma dopisaną sygnalizację świetlną jak na drodze dla każdego uczestnika spotkania pokazująca czy można edytować dany wniosek]. System automatycznie aktualizuje dane wniosku bez konieczności odświeżania strony. | |
| 2. Wprowadź swój komentarz do wniosku oraz wprowadź swoje prywatne notatki do wniosku | Tak jak w zadaniu C20 | |
| 3. Możliwość wprowadzenia komentarza podsumowującego wszystkie komentarze | Tak jak w zadaniu C20 | |
| 1p. Problem. Obecnie żeby zobaczyć komentarz innej osoby trzeba odświeżać co chwila stronę lub czekać aż dana osoba poruszy problem podczas dyskusji. | System automatycznie aktualizuje dane wniosku bez konieczności odświeżania strony. | |
| 2p. Problem. Obecnie żeby wprowadzić komentarz to trzeba wejść w osobną podstronę z formularzem przez co nie można podczas pisania komentarza jednocześnie przeglądać wniosku. | Dodawanie komentarza będzie poprzez pole tekstowe które będzie się pokazywać na ekranie po kliknięciu przycisku dodaj komentarz. System nie będzie wyświetlać kolejnej strony. | |
| 3p. Problem. Ten sam problem co w 2p. | Dodawanie komentarza będzie poprzez pole tekstowe które będzie się pokazywać na ekranie po kliknięciu przycisku dodaj komentarz. System nie będzie wyświetlać kolejnej strony. |
Patrząc na sposób przekazania wymagania zastanówmy się nad kilkoma kwestiami:
- Czy potrzeba biznesowa zostanie zrealizowana? TAK
- Czy zwykłe wymagania zajmą więcej miejsca? TAK
- Czy na napisanie takich wymagań poświęcisz mniej czasu? TAK
- Czy wymagania są prostsze dla interesariuszy do zrozumienia? TAK
- Czy napisanie oferty przez dostawcę oprogramowania jest łatwiejsze? TAK
- Czy istnieje ryzyko związane z wymaganiami? TAK
- Czy można to łączyć? TAK
Podsumowanie
Pisanie wymagań w formie prostych założeń oraz problemów które ma interesatiusz do rozwiązania są fajnym rozwiązaniem. Rozwiązanie jest o tyle ciekawe że od problemu wywodzi się cel biznesowy. Można tutaj zauważyć trochę ryzyk związanych z niejasnością wymagania. Proces też raczej lepiej się sprawdzi w przypadku zamówienia systemów od dostawców zewnętrznych w przeciwieństwie do projektów rozwijanych wewnętrznie.
Największym jednak plusem jest to że nie narzucamy rozwiązania w żaden sposób nawet jak byśmy chcieli je narzucić to nie mamy za bardzo jak(no chyba że istnieje problem związany z danym sposobem implementacji ale to już inna para kaloszy). A nie pisząc kodu danej aplikacji nie jesteśmy w stanie poznać jej wszystkich ograniczeń.
Napisanie wymagań w taki sposób zajmuje mniej czasu. Czy uważam że jest to metoda która mogłaby wyprzeć tradycyjne wymagania biznesowe? Raczej nie. Wolałbym to tutaj stosować zgodnie ze sztuką całej naszej pracy analitycznej w IT. Wymagania można modelować i opisać słownie albo stworzyć prototyp. Najlepiej jest ze sobą łączyć te sposoby. Nie widzę przeciwwskazań żeby do tradycyjnego wymagania dopisać jaki jest problem. Zamiast ograniczać się tylko do opisów celów biznesowych.
Źródła
(Programming and Software Engineering 10753) Erik Kamsties,Jennifer Horkoff,Fabiano Dalpiaz (eds.) – Requirements Engineering_ Foundation for Software Quality_ 24th International Working Conference
