Kiedyś po wyjściu z pracy, wstąpiłem do niewielkiego sklepu z odzieżą, na jednej z uliczek w pobliżu Starego Rynku w Poznaniu. Zainteresował mnie garnitur. Producent był znany, cena niska, a z metki wynikało, że powinien pasować. Był wieczór, do zamknięcia sklepu kilka minut, więc przymierzyłem tylko marynarkę. Pasowała nawet dość dobrze. Na propozycję odłożenia sprawy do poniedziałku, właściciel zaoferował sporo niższą cenę i gotowość dokonania ewentualnych poprawek. Uległem.

Już w domu stwierdziłem, że marynarka ma tylko jedną kieszeń piersiową, a mała kieszonka nie mieści wizytówek. Nazajutrz okazało się, że w dziennym świetle kolor jest, no, taki sobie, a spodnie wymagają zmiany długości nogawek i dopasowania. W poniedziałek znów byłem w sklepie. Okazało się, że kieszeni naprawić nie można, a dopasowanie jest odpłatne i wykonuje je wytwórca na drugim końcu Polski, co miało zająć kilka tygodni.

Gdy wkrótce od marynarki odpadł guzik, postanowiłem nie ryzykować tego samego ze spodniami i wszystkie guziki przyszyłem ponownie sam. Aha - jeszcze jedno - ten nieszczęsny kolor utrudnił mi korzystanie z już posiadanych komponentów, z których większość należała do innej konwencji kolorystycznej. Efektem były kolejne zakupy...

Ponieważ wszelką odzież - od skarpetek, po szalik - od zawsze kupuję sobie sam, to i w tym przypadku pretensję mogłem mieć tylko do siebie.

Wszystko to przypomniało mi się w związku z seminarium, w którym uczestniczyłem ponad rok temu, a którego tematem było doskonalenie specyfikacji wymogów, jakie mamy, czy raczej - powinniśmy mieć - wobec systemów informatycznych, jeszcze zanim przystąpimy do ich tworzenia. Może słowo "wymogi" nie oddaje dokładnie tego, o co w tym chodzi, zacytujmy więc fragment książki: "Wymogi to coś, co należy poznać, zanim rozpocznie się tworzenie produktu (...), to coś, co produkt musi robić lub cecha, jaką musi posiadać (...), niezależnie od tego, czy produktem tym jest łódź podwodna, system bankowy, sieć telefoniczna czy też zacisk hamulcowy".

W pierwszym momencie sprawa wydaje się oczywista. Dopiero gdy skonfrontować to chociażby z przedmiotami z otoczenia, okazuje się, jak bardzo mijają się one nawet z najbardziej oczywistymi celami, dla których powstały. To samo można powiedzieć o skutkach wdrożenia wielu systemów informatycznych.

Oddając jeszcze raz głos wspomnianej książce - cała sztuka polega na zastosowaniu metodyki, która umożliwia znalezienie tych wymogów i związków między nimi, utwierdzenie się, że wskazane zostały właściwe z nich, no i to, co większość informatyków lubi najbardziej - udokumentowanie wszystkiego w usystematyzowany i przejrzysty sposób. Dopiero wyniki tego etapu stają się podstawą analizy, obojętnie, w jaki sposób zamierza się ją prowadzić. Właśnie to autorzy podkreślają - wymogi muszą być ustalone i uznane, zanim powstanie koncepcja ich informatycznej obsługi, bez względu na to, czy jej udziałowcem będzie oprogramowanie gotowe, czy coś tworzonego w całości we własnym zakresie.

Aha - w końcu winien jestem wyjaśnienie, kto to taki, ci autorzy. Są to przedstawiciele światowej klasy w swej dziedzinie - Suzanne i James Robertsonowie, a sama Suzanne prowadziła wspomniane tu, kilkudniowe seminarium i jej autograf mam w cytowanej książce (Mastering the Requirements Process, Addison-Wesley, 1999 r.).

Wracając do moich przygód z garniturem - w rozpędzie nabywania dodatków dałem sobie wcisnąć również kosztowną muszkę. Muszkę, której pewnie nigdy nie założę. Po pierwsze, bo nie uczestniczę w stosownych do tego okazjach, po drugie - bo to i tak zupełnie nie w moim stylu.