Produkty w procesie analizy wymagań

Konkluzja prawnika, by zawierać umowy o dzieło jeżeli tylko jest to możliwe, jest moim zdaniem słuszna. Tam gdzie nie mamy wystarczającej wiedzy by zawierać takie umowy, warto zainwestować czas by określić jednak przedmiot umowy, gdyż umowa zlecenia z ekspertem (dostawcą oprogramowania) powoduje, że Zamawiający kompletnie nie panuje nad umową: nie wie jakiego produktu oczekiwać, satysfakcja z wykonanej pracy może nadejść w trudnym do przewidzenia czasie. Druga uwaga: jeżeli cały proces, od pierwszej analizy do dostarczenia produktu, realizuje jedna firma, mamy do czynienia z sytuacją, w której dostawca sam kontroluje stawiane mu wymagania bo sam sobie definiuje to co ma następnie wytworzyć. Taki brak kontroli rodzi poważne ryzyko nierzetelności.

Continue ReadingProdukty w procesie analizy wymagań

Słownik pojęć biznesowych: najbardziej podstawowe wymaganie

Pierwszym etapem analizy, bardzo trudnym, jest opracowanie modelu pojęciowego. Celem budowy tego modelu jest zrozumienie na poziomie komunikacji (tak zwany biznes z developerem -> zagwarantowanie jednoznaczności) oraz zrozumienie tego co jest przedmiotem projektu (modelując magazyn raczej planujemy oprogramowanie symulujące kartoteki magazynowe a nie produkty w magazynie). Ważne jest by na oprogramowanie patrzeć jak na narzędzie, bo ono nim jest. Oprogramowanie wspomagające zarządzanie magazynem, nie zastępuje tego magazynu i towarów w nim... Tak więc oprogramowanie, nazwy w nim używane, muszą spełnić warunek zgodności ze "słownikiem biznesowym": biznesowy słownik pojęć (zgodność z nim) to jest wymaganie.

Continue ReadingSłownik pojęć biznesowych: najbardziej podstawowe wymaganie

User Stories, czym jest?

Tak więc programista implementuje logikę biznesową, tę musi jednoznacznie udokumentować analityk, oraz zapewnia uzgodnioną jakość (wymagania pozafunkcjonalne). Ma więc dużo pracy... ale nie powinien podejmować prób wpływu na implementowaną logikę biznesową. Czyli np. "jako sprzedawca, dostaję od klientów zamówienia, na podstawie których muszę wystawiać faktury VAT", do tego analityk doda, np. po analizie otrzymanej partii dokumentów, strukturę zamówienia i faktury VAT oraz "algorytm" wyliczenia podatków. Jeżeli programista zaczyna "lepiej wiedzieć" od zamawiającego, forsując np. prostszą implementację, to znaczy, że przekroczył swoje kompetencje, sam sobie - jako developerowi - robi krzywdę psując to oprogramowanie bo klient i tak prędzej czy później na tych uproszczeniach "polegnie". Rolą analityka są także ewentualne negocjacje z zamawiającym, uproszczeń lub rozwinięć tego opisu. Czy analityk może być "pracownikiem" dostawcy? Jak sądzicie?

Continue ReadingUser Stories, czym jest?

Inżynieria wymagań

Wymagania interesariuszy. Moja definicja interesariusza (jedna z wielu): osoba (podmiot) zainteresowana zaistnieniem produktu, na którą pojawienie się produktu ma wpływ. Nie raz jestem pytany czy interesariusz ma prawo zgłaszania wymagań. Jeżeli ma coś do powiedzenia podczas odbioru produktu to znaczy, że ma wymagania. One mogą być jednak niejawne czyli taki interesariusz nie zgłasza wymagań ale ma wpływ na odbiór produktu, należy go koniecznie zidentyfikować. Jeżeli zaś ktoś nie ma nic do gadania przy odbiorze produktu nie jest interesariuszem (ang. stakeholder, kluczem jest tu 'holder' czyli dysponent mający coś do powiedzenia, mający wpływ). Tak wiec interesariusz to ktoś kto, na swoim poziomie ogólności, także musi umieć określić, kiedy uzna, że produkt spełnia jego wymagania. Jak nie potrafi, ktoś musi mu pomóc...analityk :)). I tu rola analityka. Interesariusz spisuje co mu przyjdzie do głowy swoim językiem, analityk upewnia się, że zrozumiał, doprowadza je do postaci testowalnej i klasyfikuje "wymagania" jako "źródło: konkretny interesariusz" (bo każde wymaganie musi mieć właściciela). Proszę zwrócić uwagę, że interesariuszem jest także użytkownik jeżeli tylko ma coś go powiedzenia w projekcie :).

Continue ReadingInżynieria wymagań