Ten artykuł jest pewną kontynuacją poprzedniego. Potraktujmy go jako “prostszą wersję” 🙂 popartą oczekiwaniami przyszłego wykonawcy, który w swoim artykule niejako “składa zamówienie na dokument wymagań”.
Wpadła mi swego czasu przed oczy strona pewnego developera stron WWW. Dlaczego mnie zainteresowała? Bo po pierwsze słusznie oczekuje od swojego klienta konkretów, po drugie potrafi krótko i zwięźle opisać czego potrzebuje, by mógł wytworzyć oprogramowanie (opisał to w kontekście tworzenia stron WWW, które obecnie bardzo często także są wynikiem działania oprogramowania):
Podstawowym dokumentem, który należy przygotować jest specyfikacja techniczna. Powinna ona wyszczególnić funkcjonalności, które mają znaleźć się na stronie. Niestandardowe funkcje powinny zostać dokładnie opisane. Opis może przybrać formę zarówno słowną, jak i graficzną (schemat działania, diagramy UML).
Jak widać podzielił wymagania na funkcje (funkcjonalności) standardowe i niestandardowe. Dlaczego? Uważam, że słusznie, standardowe (opisane już gdzieś lub ogólnie uznane) funkcjonalności należy wydzielić i przytoczyć ich znane i typowe opisy lub nazwy (np. okno logowania) dzięki czemu unikamy nazbyt szczegółowych (czytaj kosztownych bo pracochłonnych) opisów zachowując już jednak pewną jednoznaczność. Po drugie, zapewne będą one realizowane przez predefiniowane w wielu narzędziach, moduły (czytaj wykonane taniej). Niestandardowe funkcjonalności wymagają dokładniejszego opisu – bo są niestandardowe ;).
I dalej:
Poza danymi czysto technicznymi warto opowiedzieć także o swoim biznesie. Im więcej potencjalny wykonawca strony będzie wiedział o firmie tym lepiej będzie mógł dostosować ją [stronę WWW, oprogramowanie] do charakteru firmy. Warto powiedzieć co wyróżnia firmę na tle konkurencji, co robi lepiej, jakie umiejętności posiada. Należy również określić cel realizowany przez stronę.
Opis funkcjonalności zawsze będzie zachowywał pewien poziom ogólności (autor opisu nie programuje a opisuje co chce dostać i z pomocą tego co dostanie, osiągnąć). Skoro więc istnieje pewne pole manewru dla wykonawcy (a zawsze tak będzie), pomoże mu w wytworzeniu lepszego produktu, zrozumienie celu zamawiającego. Jak przekazać wiedzą “pozwalającą zrozumieć”? Od tego jest analiza biznesowa i zapis jej wyników, w tym model biznesowy firmy i cel biznesowy projektu.
Model biznesowy powinien zawierać nie tylko opis zamawiającego. Jeżeli jakiekolwiek funkcjonalności są dedykowane klientom zamawiającego (publiczna strona WWW, portal samoobsługi CRM itp.) opis typowego klienta (grupa docelowa) i jego cele, także powinny znaleźć się w treści analizy biznesowej:
Kolejnym elementem jest przekazanie informacji o kliencie, do którego kierowana jest strona. Takie czynniki jak wiek, wiedza czy zapotrzebowania na informację odbiorców wpływają na sposób realizacji strony. Strona tworzona jest dla naszych odbiorców, tak więc im lepiej będzie dostosowana do ich potrzeb, tym lepszy będzie jej odbiór.
Pora na część najtrudniejszą:
Na koniec należy zamieścić informacje organizacyjne takie jak budżet oraz termin uruchomienia strony.
Jak nie “po dobroci” to podczas negocjacji umowy. Ogólnie zawsze powinna to być tak zwana umowa “fixed price” czyli umowa o dzieło o ustalonym zakresie (powyższy opis), budżecie (wartość umowy) i terminie (harmonogram).
(na podstawie artykułu Jak przygotować zapytanie ofertowe? | Firma w sieci).
