Wstęp

Siedem lat temu (2015) artykuł o wymaganiach i śladowaniu kończyłem słowami:

Tak więc wyma­gań biz­ne­so­wych może być kil­ka­dzie­siąt. Wymaganych usług sys­te­mu (przy­pad­ków uży­cia) w dużym pro­jek­cie tak­że może być kil­ka­dzie­siąt. Ale set­ki, czy tysią­ce ??wyma­gań? to wyraz utra­ty pano­wa­nia nad zakre­sem pro­jek­tu? Tu zwró­cę uwa­gę, że wyma­ga­niem (usłu­ga sys­te­mu) może być np. wytwo­rzo­na fak­tu­ra VAT zgod­na z prze­pi­sa­mi. Cechy tej fak­tu­ry (lista pól) to nie osob­ne wyma­ga­nia, to cechy (para­me­try, atry­bu­ty) jed­ne­go wyma­ga­nia. Żadna cecha fak­tu­ry VAT nie ma sama w poje­dyn­kę żad­nej war­to­ści, nie może więc być oddziel­nym przy­pad­kiem uży­cia, tak samo jak wyma­ga­niem naszym może być samo­chód, ale jego kolor czy auto­ma­tycz­na skrzy­nia bie­gów, to cechy samo­cho­du, nie ma sen­su wyma­gać ??czer­wo­ne­go kolo­ru? nie ocze­ku­jąc samo­cho­du (i jak uza­sad­nić, to że ten kolor wspie­ra cel biz­ne­so­wy). Przypadkiem uży­cia samo­cho­du jest podróż a nie wło­że­nie klu­czy­ka do sta­cyj­ki, bo to jest tyl­ko jeden z ele­men­tów sce­na­riu­sza roz­po­czę­cia podró­ży samochodem.

Source: Dlaczego śladowanie wymagań jest istotne w projekcie? – Jarosław Żeliński IT-Consulting

Nadal pojawiają się publikacje o wymaganiach, zarządzaniu nimi i realizowaniu ich. Na rynku są dostępne aplikacje pozwalające je kolekcjonować i zarządzać taką kolekcją. I stale mamy do czynienia z ich – wymagań – niejednoznacznością . Okazuje się, że ich znaczenie staje sie kluczowe dla projektów, także z perspektywy prawa (PZP i zdefiniowane w zaleceniach UZP pojęcie potrzeba). Tym razem skupię się na pojęciach ‘wymaganie’ i ‘potrzeba’ w odniesieniu do projektu rozwiązania.

Mała debata

Niedawno miałem ogromną przyjemność wzięcia udziału a debacie na temat wymagań i tego co powszechnie nazywane jest Inżynierią Wymagań. Moim rozmówcą był Tom Gilb a debatę zostaganizował Karolina Zmitrowicz. W toku tej debaty udało nam się dojść do pewnego ciekawego porozumienia: odkryliśmy, że “od lat mówimy prozą”.

Debata pokazała ważną rzecz: należy zawsze mówić o jakie wymagania chodzi.

Nie chodzi też o to by wydzielać wymagania poza-funcjonalne, bo nie ma sensu ich tak dzielić. Mamy ograniczenia i środowisko, ono także jest ograniczeniem czyli, czymś czego z określonego powodu wymagamy. O tym posłuchacie tu:

Ale po kolei…

Wymagania czyli co?

Na początek definicje kluczowych pojęć (słownik języka polskiego PWN, specyfikacja UML):

wymaganie: warunek lub zespół warunków, którym ktoś lub coś musi odpowiadać
cecha: element odróżniający lub charakteryzujący istoty żywe lub przedmioty, ich czynności i stany oraz zjawiska
potrzeba: to, co jest potrzebne do właściwego funkcjonowania
funkcja: zadanie, które spełnia lub ma spełnić jakaś rzecz (system), także możliwość wykonania określonej operacji przez urządzenie lub program komputerowy
projekt: dokument zawierający obliczenia, rysunki itp. dotyczące wykonania jakiegoś obiektu lub urządzenia
materiał: zbiór wiadomości i danych z jakiejś dziedziny
koncepcja: pomysł, projekt
usługa aplikacji: usługa jest definiowana jako zaspokojenie potrzeby, usługa aplikacji to potrzeba jaką zaspokaja aplikacja
przypadek użycia: w notacji UML (Use Case) reprezentuje deklarację (nazwę) zestawu oferowanych zachowań systemu

(https://sjp.pwn.pl/, https://www.omg.org/spec/UML/)

Tak więc: wymaganie jest precyzyjnie wyrażoną cechą systemu. Potrzeba to cecha (systemu) potrzeba (interesariuszowi) do funkcjonowania czegoś (np. organizacji). System (rozumiany jako aplikacja) świadczy usługi, z perspektywy systemu są to jego przypadki użycia. Tak więc: system realizuje jakieś funkcje, system ma przypadki użycia, system ma pewne cechy, system spełnia określone wymagania, system świadczy określone usługi. W UML mamy funkcje czy przypadki użycia? Mamy przypadki użycia w UML opisujemy (modelujemy) system (aplikacje) a nie jego otoczenie.

UZP definiuje potrzebę jako: ‘funkcja, której brakuje do osiągnięcia celu lub wykonania działania’ (źr. zalecenia UZP). W projektach związanych z inżynierią, a więc inżynierią oprogramowania także, mamy trzy kluczowe role: zamawiający (przyszły użytkownik), projektant oraz dostawca (wykonawca). Spotykane tezy jakoby inżynieria oprogramowania była jakąś inną inżynierią, są nie do obrony: komputer jest definiowany jako: procesor, pamięć i program. jest to więc urządzenie, podobnie jak wiele innych zawierających komputer. Nie raz wykazywano to na konferencjach np. organizacji inżynierskiej INCOSE.

Poniżej schemat obrazujący powyższe pojęcia w kontekście projektu dostarczenia oprogramowania, czyli komputera działającego zgodnie z oczekiwaniami zamawiającego:

W projekcie mamy trzy kluczowe role: biznes, analityk-projektant i developer. Biznes zgłasza potrzeby i dostarcza materiały jakimi są tu wszelkie pisemne artefakty jakie powstają w analizowanej firmie . Na tej podstawie spisywane są wymagania (wobec rozwiązania). Po zebraniu i zatwierdzeniu wymagań i na podstawie materiałów, powstaje model biznesowy i projekt rozwiązania: logika oprogramowania, tej jego części, która realizuje potrzeby biznesowe (spełnia wymagania). Projekt to właśnie wymaganie jakie musi spełnić dostawca (developer): dostarczyć oprogramowanie zgodne z projektem, a tak naprawdę komputer odpowiadający na potrzeby biznesu.

Skąd te wymagania wziąć?

Pojawiło się pojęcie ‘komputer’ a komputer to “procesor, pamięć i program” . Można więc także powiedzieć, że komputer to system, bo składa się z tych trzech powiązanych, współpracujących elementów.

Kluczem do tych rozważań jest stary i dobrze znany Model Wewnętrznego Łańcucha Wartości opisany przez M.E.Portera :

Jest to model opisujący firmę z perspektywy dwóch obszarów aktywności: operacyjny i wspierający. Patrząc na obszar operacyjny, mamy: procesy logistyczne, marketing i sprzedać, obsługę oraz Operations czyli tworzenie ‘tego co jest przedmiotem oferty’. Z perspektywy tego jakie informacje powstają i są przetwarzane (patrz: Architektura informacji, system informacyjny a system informatyczny w organizacji) musimy wyodrębnić kilka obszarów dziedzinowych: określony przepływ pracy między ludźmi (co i w jakiej kolejności robić), opis produktu (czym on jest), opis produkcji (jak on powstaje) oraz … Ważne jest pojęcie ‘komunikat’.

Powyższe mozna zobrazować np. tak:

Organizacja, w tym także firma na rynku, to system reagujący na żądania z rynku: klient zamawia oferowany produkt i ten jest mu dostarczany. Żeby to wszystko mogło funkcjonować musi istnieć Opis Produktu, musi być on wytwarzany (Produkcja), a kolejność wszystkich realizowanych zadań i prac musi być uporządkowana (Opis Pracy).

Produkcja, by była możliwa, wymaga zdefiniowania tego co ma być produkowane (Struktura Produktu) oraz musi istnieć infrastruktura produkcyjna (System Produkcji) czuli np. hala produkcyjna. Ta, jeżeli jest nowoczesna, to jest skomputeryzowana. Do jej kontroli i sterowania nią potrzebny jest System Zarządzający Procesami Produkcji.

To wszystko dzieje się z użyciem określonych zasobów (w tym finansowe), całość to określony system procesów biznesowych jakim jest Przepływ pracy.

Każdy z tych systemów to narzędzie pracy ludzi, są oni użytkownikami tych systemów. Jak to działa? Podobnie jak ludzie, systemy wymieniają sie komunikatami. Nie jest możliwe by ludzie komunikowali sie w różnych tematycznie sprawach, współdzieląc jedną uniwersalną tabelką na wspólnym stole, i nie jest możliwe, by komunikowały się tak te systemy. Dlatego każdy ma swoje tabelki a porozumiewają się komunikatami.

Wymagania na te systemy to nic innego jak:

• opis wewnętrznego mechanizmu działania każdego z nich,
• opis mechanizmu wymiany komunikatów między nimi.

Aż tyle i tylko tyle. Aby to zrobić wcześniej musimy opisać przepływ informacji i udział ludzi w tym przepływie oraz oczywiście strukturę każdego komunikatu: są nimi dokumenty.

A gdzie wymagania użytkownika

Czy więc mamy tu jakieś wymagania użytkownika? Nie, bo użytkownik systemu jest częścią tego systemu, więc jego rola w tym wszystkim nie jest jego wolą a obowiązkiem. Mamy system a “użytkownik” jest jego częścią. Dlatego właśnie mamy wymagania wobec rozwiązania, to projekt tego systemu, a nie mamy wymagań użytkownika. To co słyszymy od ludzi to nie ich wymagania a problemy do rozwiązania:

Źródła