Przestańmy pisać wymagania, zacznijmy je specyfikować.

Jedną z kluczowych czynności w analizie biznesowej, czy też, by być bardziej precyzyjnym - inżynierii wymagań, jest identyfikacja i dokumentacja wymagań. Bardzo często, notorycznie wręcz, spotykam się z określeniem: "pisanie wymagań". To określenie podtrzymuje jeden z fatalnych w konsekwencjach mitów dotyczących inżynierii wymagań.

Wymagań się nie pisze. Wymagania się specyfikuje.

Wymagania stanowią podstawę do podejmowania różnorodnych decyzji. W zależności od rodzaju wymagań, decyzje te mogą dotyczyć strategii organizacji w określonych obszarach, podejść do rozwiązania, wyboru architektury. Czy takie decyzje podejmujemy na podstawie wyników "pisania"? Określenie "pisanie" implikuje po prostu przedstawienie jakiejś informacji w formie pisemnej w jakikolwiek sposób. Specyfikacja oznacza przedstawienie informacji w sposób ścisły i precyzyjny.

Odnosząc się do wymagań i ich znaczenia w kontekście organizacyjnym oraz projektowym, jakie sformułowanie jest bardziej adekwatne – "pisanie wymagań" czy ich specyfikowanie?

Pomijając kwestie semantyczne, określenie "pisanie wymagań" implikuje również, że wymagania można "pisać" w dowolnej formie i mogą zawierać dowolną treść. Jest to jedno z bardziej utrwalonych w środowisku analityków biznesowych nieporozumień.

Dobrej jakości wymagania są odbieralne – to znaczy, że wiemy do czego się odnoszą, jakie są ich oczekiwane rezultaty, mamy podstawy ocenić, czy wymagania są prawidłowo spełnione.

Jak to się ma do typowych "pisanych" wymagań, w postaci, na przykład: "system umożliwia wyszukiwanie trasy"?

Na jakiej podstawie chcemy stwierdzić, że to wymaganie zostało prawidłowo zaimplementowane, skoro nie wiemy, jaki ma być wynik owego wyszukiwania? Być może wynikiem ma być: "Lista tras spełniających określone kryteria"... Problem w tym, że nie wiemy, jakie kryteria, ponieważ nie wiemy, w jaki sposób wyszukiwanie ma być realizowane i przez kogo – czy system losowo wyszukuje trasę na podstawie określonych parametrów, czy wyszukiwanie odbywa się na życzenie użytkownika, po wprowadzeniu kryteriów wyszukiwania? Nie wiemy tego.

Nie wiemy, kto korzysta z tego wymagania, nie wiemy jaki jest wynik. Stwierdzenie, że wynikiem ma być wyszukana trasa, jest niemalże bezwartościowe.

Wymagania, w tym przypadku szczególnie funkcjonalne, powinny określać co jest wejściem i co jest wyjściem, tak jak definicja funkcji. W tym przypadku nie znamy ani wejścia (jakie informacje należy wprowadzić, aby wyszukiwanie mogło zostać wykonane), ani wyjścia, czyli informacji, którą chcielibyśmy uzyskać po wykonaniu funkcji wyszukiwania.

Nie znamy również żadnych ograniczeń. W tym przykładzie mówimy o wyszukiwaniu trasy, prawdopodobnie z punktu A do punktu B. Czy możliwe jest wyszukiwanie trasy do punktu oddalonego o 100 000 km? W jakim czasie chcielibyśmy uzyskać wyniki wyszukiwania? Tego również nie wiemy.

Dobrze wyspecyfikowane wymaganie wyjaśniłoby te kwestie. Napisane wymaganie takich informacji nie zawiera.

W konsekwencji – zespół wytwórczy nie ma pojęcia, w jaki sposób zrealizować wymagania, zespół testowy nie ma pojęcia, jakie przetestować, interesariusze biznesowi, od których prawdopodobnie to wymaganie pochodzi, nie wiedzą, czego oczekiwać od implementacji. Sytuację można porównać do próby złożenia zamówienia w kwiaciarni formułując swoją potrzebę w następujący sposób: "potrzebuję ładny, duży bukiet na urodziny”. Żadna profesjonalna florystka takiego zamówienia nie przyjmie – z jakiego powodu pokrzykujemy, że nasze wymagania, pisane w podobny sposób, przyjmie zespół wytwórczy lub odbierze je biznes?

Wymagania się specyfikuje. Żeby ta specyfikacja była odpowiedniej jakości, należy zapewnić, że treść wymagania lub uzupełniające atrybuty wyjaśniają:

• Kto, co robi.

• Jaki jest mierzalny wynik realizacji wymagania.

• W przypadku wymagań jakościowych, jaki parametr mierzymy, jaka jest skala pomiaru i jaka jest procedura pomiaru.

• Jakie są ograniczenia.

• Jakie są warunki początkowe.

• Jakie dane / informacje przetwarzamy.