blog.testowka.pl

Wymagania != Specyfikacja

opublikowany przez 07, Maj, 2014, w kategoriach Agile, Scrum

„Wymagania” to nie to samo co „specyfikacja funkcjonalna/techniczna”! Wiem, że to nie wydaje się być oczywiste, ale gdyby wszyscy zdawali sobie z tego sprawę to mogli byśmy uniknąć wielu, tak często powtarzających się w IT problemów. Spróbujmy więc to jakoś zdefiniować.

Wymagania (ang. Requirements) – wymagania wobec tworzonej aplikacji to jest to, co ktoś od niej wymaga. Pisząc ktoś mam na myśli kogoś, kto ma jakiś interes w tym, by dane wymaganie zostało zrealizowane – ten ktoś jest więc Interesariuszem (ang. Stakeholder). Interesariusz wymaga od aplikacji, by realizowała ona lub pomagała w realizacji jakichś konkretnych celów. Przeważnie chodzi o cele biznesowe, ale mogą to też być też kwestie związane na przykład z wymogami prawnymi czy zależnościami od innych systemów. Ponad Interesariuszami (przeważnie jest ich wielu) jest jeszcze ogólny cel biznesowy naszej organizacji jakim przeważnie jest generowanie zysków – tak, chodzi oczywiście o pieniądze (choć nie zawsze wprost). Interesariusze wyrażają swoje potrzeby właśnie w postaci wymagań, a więc wymagania opisują to jaki cel ma zostać osiągnięty – czyli to CO aplikacja ma dostarczać. To czego wymagania nie powinny dotyczyć to sposób, w jaki ten cel musi zostać osiągnięty (można podać oczywiście w ramach wymagań jakieś przykłady różnych rozwiązań niemniej jednak nie jest to konieczne).

Większość problemów w wytwarzaniu współczesnych produktów IT bierze się właśnie stąd, że za definiowanie tego jak powinny wyglądać rozwiązania IT biorą się ludzie, którzy nie potrafią tych rozwiązań zaimplementować. Oczywiście robią to nie pytając o zdanie tych, którzy to potrafią. W ten sposób bardzo często powstaje właśnie specyfikacja funkcjonalna – czyli dokumentacja opisująca to JAK system ma spełniać wymagania Interesariuszy. Dokumentacja ta następnie (no może nie tak od razu) jest zazwyczaj przekazywana tym drugim (developerom), którzy implementują te rozwiązania na tyle na ile je rozumieją.

Warto zastanowić się nad tym po co tworzona jest zazwyczaj specyfikacja funkcjonalna? Przeważnie tworzy się ją po to, by za jakiś czas pamiętać o tym co nasz system ma robić i jak ma to robić? Kluczowe jest tutaj „…za jakiś [znacznie dłuższy] czas…”.

Potrzeba istnienia specyfikacji funkcjonalnej sprowadza się do minimum (w zasadzie zależy to tylko od tego, czy z jakiegoś rozsądnego powodu chcemy mieć na przyszłość dokumentację tego, co zostało zaimplementowane), gdy mamy do czynienia z inkrementalnym i iteracyjnym wytwarzaniem oprogramowania jak na przykład w Scrum. Planując pracę na najbliższe dwa tygodnie nie potrzebujemy z góry szczegółowo zapisywać tego jak zamierzamy zaimplementować rozwiązania postawionych przed nami problemów. Zgodnie z zasadą Just In Time – pracujemy w danym momencie nad tym co jest w danym momencie najważniejsze. Przed rozpoczęciem Sprintu przeważnie nie wiemy jak zaimplementujemy dane wymaganie.

Cały ten Agile dotyczy właśnie tego by zbliżyć tych ostatnich w łańcuchu – developerów, do tych z samego początku – Interesariuszy. Chodzi o to, by to właśnie ludzie, którzy mają implementować rozwiązania mogli podejmować decyzje, co do tego jak dane wymaganie zostanie zrealizowane.

To plus rozróżnienie wymagań od specyfikacji to fundamentalne podstawy dobrego zrozumienia metod takich jak Scrum czy BDD. Niestety wydaje mi się, że wiele osób zgubiło to gdzieś po drodze i teraz na przykład piszą User Stories tak, jak by były dokumentacją funkcjonalną. Wielokrotnie spotykałem się z (oczywiście bzdurną) opinią, że User Stories mają być odpowiednikiem dokumentacji funkcjonalnej…

Co w takim razie z analitykami? Nic… Analitycy są potrzebni – bardzo potrzebni! Pomagają zrozumieć domenę biznesową developerom, a także często samym Interesariuszom. Pomagają znaleźć optymalne rozwiązania problemów wyrażonych w postaci wymagań.

Jeśli natomiast Twoja praca sprowadza się głównie do pisania specyfikacji funkcjonalnej, którą później wysyłasz do developerów to przykro mi, ale jest spora szansa, że jesteś dokumentalistą a nie analitykiem (nawet pomimo swoich wybitnych umiejętności w tym zakresie). Analizując problem i poszukując jego rozwiązań należy bowiem brać pod uwagę różne aspekty – a już na pewno kwestie biznesowe oraz możliwości implementacyjne. Dobry analityk będący częścią wskroś-funkcjonalnego zespołu developerskiego wnosi niesamowitą wartość – jeśli tylko rozróżniamy wymagania od specyfikacji funkcjonalnej (patrz powyżej).

Specyfikacja funkcjonalna – czy inna dokumentacja tego typu stanowi zasadniczy koszt wytwarzania oprogramowania i naprawdę warto jest się zastanowić czy mamy doby powód by koszt ten ponosić. Zauważcie, że nie neguję istnienia takiej dokumentacji zawsze i wszędzie – jest z pewnością wiele przypadków, w których jej istnienie jest konieczne! Proszę Was tylko o to, byście zadali sobie pytanie z jakiego powodu taka dokumentacja jest konieczna w Waszym przypadku, oraz zastanowili się, czy odpowiedź na nie ma sens…

–== C. D. N. ==–


2 Comments for this entry

  • Zły

    Tutaj trzeba rozważyć kilka różnych aspektów. I tak:
    – Primo: W przygotowaniu specyfikacji funkcjonalnej trzeba przede wszystkim brać pod uwagę kto jest odbiorcą dokumentacji. Specyfikacja nie jest tylko dla deweloperów. W większości przypadków jest dla właśnie interesariuszy projektu (zwłaszcza jak jest klientem zewnętrznym) i całej organizacji, która bierz udział w projekcie.
    – Secundo: jeżeli analityk przygotuje specyfikację przed przystąpieniem do prac to pozwoli to już na tym etapie wyłapać większość błędów w wymaganiach, opracować koncepcje rozwiązania, a także wycenić i zaplanować prace. Sami deweloperzy uświadamiają sobie co mają na końcu dostarczyć.
    – Tertio: Nie można zakładać, że specyfikacja jest niezmienialna. Ona żyje razem z projektem. Na każdym etapie prac wymagania mogą się zmienić, rozwiązanie może się zmienić (znaleźliśmy lepsze), odkryjemy błąd w koncepcji. Specyfikacja ma za zadanie opanować chaos i pomóc w wykryciu wszystkich zależności przy dokonywaniu zmian.
    – Quarto: Zgadzam się, że specyfikacja ma dokumentować to co zostało wytworzone. Później można do niej wrócić i uświadomić sobie o co w ogóle chodziło.
    – Quinto: Analityk, który przygotowuje specyfikację tylko dla samego przygotowania i (w trakcie jej przygotowywania lub później) nie współpracuje z zespołem to dupa nie analityk.

    Swoją drogą polecam w tym temacie lekturę Hani Wesołowskiej – http://analizait.pl/2013/czy-dobra-analiza-gryzie-sie-z-agile/

  • Hanna Wesołowska

    Pytanie co rozumiesz pod pojęciem „specyfikacja funkcjonalna”? Dobre praktyki i znane mi standardy związane z analizą i wymaganiami, mówią o tym, że specyfikacja funkcjonalna odpowiada na pytanie „Co rozwiązanie ma robić”. Właśnie na poziomie wymagań (Co?), nie projektu technicznego, sposobu rozwiązania. Narzucanie tego, w jaki sposób coś ma zostać wykonane (wewnętrzny algorytm, struktura, interfejs, itp.) to zła praktyka, sposób, w jaki wymagania nie powinny być opisywane.

1 Trackback or Pingback for this entry

Skomentuj