Podczas mojej pracy zauważyłem, że spory problem stanowią wymagania. Trudnością nie jest ich spisanie. Trudnością jest ich wyartykułowanie. Pomijam turbulencje związane z celem zamiany czy też budowy systemu. Nie zawsze trzeba wiedzieć po co się zmienia system. Żartowałem :-). Wiedzieć trzeba.  Dziś jednak nie o tym. Chcę napisać o sensownej inżynierii wymagań.

Otóż  chciałbym podzielić się kilkoma istotnymi zasadami, które, mam nadzieję, że pomogą ustanowić efektywne podstawy dla modelowania wymagań.  Postaram się, żeby było modnie czyli zwinnie :-).

Zacznij od modelu biznesowego

Narysuj proces biznesowy. Jeśli robisz drobną zamianę to zejdź do poziomu systemów. Jeśli większą (np.: wymieniasz system) podnieś poziom abstrakcji. Do aktywności na procesie dodaj wymagania. Określ w nich co musi zrobić system by wesprzeć ten krok procesu biznesowego. Jeśli masz model na poziomie systemów to zaczynasz tworzyć wymagania na system. Jeśli dodałeś wymagania na wyższym poziomie abstrakcji to być może tworzysz wymagania biznesowe. Ważne jest to, że zaczynasz zawężać perspektywę patrzenia na system i uszczegóławiasz powoli detale.

Przedstawiciele biznesu są potrzebni

Interesariusze projektu powinni przekazywać swoje wymagania, nadawać im priorytety oraz w odpowiednim czasie podejmować decyzję. Istotnym jest, aby interesariusze projektu zrozumieli tę koncepcję i angażowali się od początku projektu. Fajnie jest jak proces biznesowy ma swojego właściciela. Wtedy on staje się kluczowym interesariuszem. Udziałowcy projektu są jedynym źródłem wymagań. Tak, programiści mogą sugerować wymagania, ale interesariusze muszą zaakceptować te sugestie.

Oprogramowanie bez wymagań jest stratą czasu

Jeśli nie ma wymagań, nie ma czego budować. Celem Tworzenia Oprogramowania jest zbudowanie działającego oprogramowania, które spełnia wymogi udziałowców projektu. Jeśli nie znasz tych potrzeb, nie jest w stanie odnieść sukcesu. Twój system musi być oparty na wymaganiach, całościowo na wymaganiach, i na niczym innym jak na wymaganiach. Wymagania możesz zdefiniować za pomocą przypadków użycia, diagramów BPMN (na różnym poziomie abstrakcji), makiet ekranów, opisów itd.. Musisz zmusić/namówić/przekonać przedstawicieli biznesu do tego by powiedzieli co chcą mieć. Muszą to zrobić w taki sposób aby dla wszystkich stron stało się jasne po co to robimy.

Celem jest wzajemne zrozumienie, nie dokumentacja

Podstawowym celem procesu zbierania wymagań jest zrozumienie, czego chcą interesariusze. To, czy stworzysz szczegółową dokumentację opisującą te wymagania, czy być może jedynie zbiór odręcznych szkiców czy notatek, to już zupełnie inna sprawa. Liczy się zrozumienie.

Modele są dla wszystkich

Jeśli budujesz modele wymagań  to pokazuj je publicznie. Modele są ważną częścią kanałów komunikacyjnych, ale działają tylko wtedy, gdy ludzie je widzą i rozumieją. Głęboko wierzę w koncepcję publicznego ujawniania modeli tak, aby każdy miał do nich dostęp i mógł z nimi pracować, nawet, jeśli są to tylko szkice lub odręcznie narysowane makiety. Dlatego też…

Modelowanie ma większy sens, gdy modele opisują system z wielu perspektyw 

Wymagania odnoszące się do systemu są zazwyczaj złożone, jako że dość często obejmują wiele kwestii. Jako że każdy model ma swoje mocne i słabe strony, żaden pojedynczy model nie jest wystarczający; dlatego też aby móc wykonać swoje zadanie będziesz potrzebował kilka rodzajów modeli. Warto wymagania przypisać do elementów na modelach. Wymaganie możesz łączyć (poza przypadki użycia) z aktywnością procesu biznesowego, ekranem, klasą, komponentem. Możesz wiązać wymagania między sobą. Zwróć jednak uwagę, że…

Nadmiar mapowań też jest szkodliwy

Zachowaj umiar.  Potrzebujesz kilku typów mapowań. Kiedy naprawiasz coś w domu używasz jedynie kilku ze swoich narzędzi, takich jak śrubokręt i klucz francuski. Następnym razem, gdy coś naprawiasz, możesz użyć innych narzędzi. Pomimo tego, że masz wiele narzędzi, nie używasz ich wszystkich naraz. Tak samo jest w przypadku Tworzenia Oprogramowania: Pomimo, że w swojej „intelektualnej skrzynce na narzędzia” posiadasz kilka technik, przy danym projekcie używasz jedynie pod zestawu.

Używaj prostych, ogólnych narzędzi i technik

Możliwym jest, a nawet pożądanym, aktywny udział osób zainteresowanych w modelowaniu. Nie mniej jednak interesariusze projektu zazwyczaj nie znają technik modelowania ani skomplikowanych narzędzi do modelowania (np.: Enterprise Architect’a). Jedną z opcji jest poświęcenie kilku miesięcy na przeszkolenie udziałowców z zakresu technik i narzędzi modelujących, ale o wiele lepszym podejściem jest użycie prostych narzędzi, takich jak białe tablice i kartki papieru, oraz prostych technik modelowania. Proste narzędzie i techniki są łatwe do nauczenia, dlatego też są one ogólne- każdy może z nimi pracować. Nie strasz ludzi technologią, jeśli nie ma takiej potrzeby. Po uzgodnieniu kształtu i zakresu zmiany/systemu możesz użyć narzędzi Case i utworzyć w nich specyfikację systemu. Na etapie kreowania wymagań, narzędzia takie jak Enterprise Architect są tylko zawalidrogą.

Wymagania z czasem zmieniają się

Ludzie często nie wiedzą, czego chcą – a jeśli wiedzą, to zazwyczaj nie wiedzą jak to przekazać. Co więcej, ludzie zmieniają zdanie – dość często można słyszeć jak udziałowcy mówią „Teraz, kiedy sobie to przemyślałem…” lub „Nie to miałem na myśli”. Co gorsza, środowisko zewnętrzne też się zmienia – być może Twoja konkurencja ogłosiła nową strategię, lub rząd uchwalił nową ustawę. Niestety tak bywa. Jeśli masz wymagania zmapowane na inne elementy dość szybko „ogarniesz” zakres zmiany.

Większość wymagań powinna być niezależna od technologii

Wzdrygam się, kiedy słyszę terminy takie, jak „zorientowane na obiekt”, „strukturalne” lub „oparte na komponencie” wymagania. Wszystkie te terminy to kategorie technologii wdrażania i dlatego tez odzwierciedlają kwestie architektoniczne i projektowe. Wymagania powinny określać czego (jakich funkcji) spodziewamy się po systemie. Muszą być napisane w języku, jaki używa biznes. Nie mniej jednak nie tworzymy oprogramowania w próżni. Ważnym jest być świadomym tego, że niektóre wymagania, takie jak ograniczenia techniczne mówiące, iż Twój system musi używać standardowych technologii J2EE i relacyjnej bazy danych stosowanych w Twojej organizacji, są tak naprawdę zależnie od technologii. Twoi udziałowcy muszą zrozumieć, kiedy ma to zastosowanie i dlaczego.

 

 

Mam nadzieję, że te 10 porad sprawi, że Twój proces zarządzania wymaganiami będzie bardziej przyjazny. Powodzenia 🙂

Zostaw odpowiedź

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

Możesz użyć tych HTML tagów i atrybutów: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Close