W poprzednim artykule mogłeś przeczytać o tym, jak znaleźć odpowiednią firmę programistyczną, która zrealizuje Twój pomysł na projekt. Gdy podejmiesz właściwą decyzję, czeka Cię kolejne wyzwanie. Zapewne masz już w głowie pewną wizję swojego projektu, jednak problem pojawia się w momencie, gdy masz to przelać na papier. Jak się do tego zabrać, z czego taki dokument powinien się składać i jakich błędów należy w nim unikać? Inaczej mówiąc, jak napisać dobrą specyfikację wymagań, która ma za zadanie zebrać w jednym dokumencie wszystkie funkcje jakie ma posiadać dany system. Odpowiedź na to pytanie znajdziesz w tym artykule.

Przeczytaj też: What Shall We Pay Attention To When Choosing Software Development Company?

Od czego zacząć?

1. Zacznij od krótkiego opisu Twojej firmy / instytucji. Zdefiniuj co to jest za firma i czym się ona zajmuje.

2. Określ obszar, do którego system będzie dedykowany. Czy będzie on przeznaczony do użytku wewnętrznego czy może dla użytkowników zewnętrznych?

3. Opisz procesy biznesowe, które są realizowane w Twojej firmie. Procesy biznesowe należy rozumieć jako powtarzalne działania przeprowadzane w danej organizacji. Takie procesy zostaną przekształcone na wymagania funkcjonalne a następnie na przypadki użycia.

4. Wyznacz sobie cele tego systemu. Odpowiedz na pytania do czego ma on służyć, w jakich działaniach pomóc i jakie procesy biznesowe w Twojej firmie usprawnić. Następnie przedstaw wymagania funkcjonalne, które mają pojawić się w systemie. Możesz to zrobić za pomocą tzw. user stories, które polegają na prostych opisach potrzebnych funkcji z perspektywy użytkownika. Dzięki temu wykonawca będzie miał obraz tego, w jaki sposób planujesz z systemu korzystać. Możesz je rozpisać krok po kroku lub przedstawić w formie graficznej jako przypadki użycia. Przykład takiego diagramu:

Warto też wypisać role użytkowników oraz wstępną macierz dostępu użytkowników do poszczególnych funkcjonalności.

Cenna wskazówka: Specyfikacja wymagań projektu powinna być opisana w precyzyjny sposób. Im więcej szczegółów, tym lepiej.

O czym powinieneś pamiętać?

Prawidłowo przygotowana specyfikacja wymagań powinna zawierać nie tylko wymagania funkcjonalne ale również te niefunkcjonalne, takie jak: bezpieczeństwo, wydajność, responsywność, dostępność (WCAG). Jest to istotne, ponieważ to wszystko przekłada się na całokształt systemu oraz jego odbiór przez użytkownika. Dlatego niezwykle ważne jest, aby brać wymagania niefunkcjonalne pod uwagę od samego początku tworzenia projektu.

Nie zakładaj, że coś się pojawi w oprogramowaniu, o czym nie wspomniałeś w specyfikacji wymagań, a co Twoim zdaniem jest oczywiste. Jasno określaj swoje wymagania. Dokument powinien zawierać opis branżowych pojęć oraz specyfikę Twojej firmy.

Jakich błędów nie popełniać?

Unikaj zbyt ogólnych sformułowań wymagań, z których wynika pewna dowolność. Często zdarza się, że klient nie do końca jest w stanie sobie wyobrazić jak to oprogramowanie ma wyglądać, z czego dokładnie powinien się składać czy jakie zmiany mógłby wprowadzić. Przykładowo, chciałby mieć w nim raporty, ale jeszcze nie wie, jak one mają działać czy w jakiej formie mają być przedstawione.

Jeśli znajdziesz się w podobnej sytuacji, nie bój się napisać w dokumencie specyfikacji wymagań, że czegoś nie wiesz. Umieść informację ogólną i poproś o wsparcie. W tej roli najlepiej sprawdzi się Analityk. Wtedy jest czas na dyskusję, gdzie zespół zaproponuje jakieś rozwiązanie i przedstawi sposób w jaki mogłoby to funkcjonować.

Załóżmy, że masz już działające oprogramowanie, jednak chcesz go stworzyć na nowo. W takiej sytuacji nie wzoruj się na tym, co masz. Nie twórz opisów takich samych funkcjonalności. Skup się na opisie samego działania danej funkcji, a nie na projektowaniu tego systemu.

Priorytetyzacja wymagań

Prioryteryzacja wymagań jest przydatna w przypadku, gdy zależy Ci na jak najszybszym uruchomieniu systemu w wersji MVP. Zastanów się, które elementy powinny być zawarte w pierwszej wersji oprogramowania. Niektóre funkcjonalności – te mniej istotne – mogą być dodawane już w trakcie działania systemu. To może również pomóc pozyskać środki finansowe potrzebne do dalszego rozwoju oprogramowania.

Przeczytaj też: MVP (Minimum Viable Product) – Od Czego Zacząć?

Co powinna zawierać specyfikacja wymagań?

Dobrze stworzona specyfikacja wymagań musi składać się co najmniej z:

• misji organizacji,
• krótkiego opisu czym się organizacja zajmuje,
• wyznaczeniem celu projektu,
• wskazaniem kto jest głównym odbiorcą i jakie będą grupy przyszłych użytkowników,
• opisu procesów biznesowych w organizacji,
• opisu poszczególnych obszarów, które system ma wspomagać,
• opisu wymagań i zadań jakie ma realizować system,
• ilości użytkowników oprogramowania oraz ilości danych,
• spisu wymogów niefunkcjonalnych.

Przykłady specyfikacji wymagań

Poniżej przedstawiam kilka przykładów prawidłowej i błędnej specyfikacji wymagań.

Prawidłowo zdefiniowane wymagania:

„System, w części dla klientów i handlowców, powinien być responsywny i przygotowany do wyświetlania zarówno na dużych monitorach jak i smartfonach” – jeśli opisano również, które części systemu są dostępne dla klientów oraz handlowców, wymóg staje się precyzyjny.

„Handlowiec na liście ofert do akceptacji, akceptuje ofertę od klienta. Wysyłany jest mail z potwierdzeniem do klienta. Oferta otrzymuje status ‘zaakceptowana’, a klient traci prawo do jej edycji. Staje się widoczna dla działu magazynowego.” – zdefiniowano kto wykonuje daną operację, określono na jakich ofertach można wykonać operację oraz jakie są skutki wykonania tej operacji.

Błędnie zdefiniowane wymagania:

„Oprogramowanie powinno mieć elastyczny interfejs” – nie wiadomo o jaką elastyczność chodzi. Responsywność? Customizacja?

„System powinien umożliwiać szybkie dodawanie nowych pozycji oferty” – co to znaczy szybkie? Jak ją mierzyć?

„Użytkownik akceptuje ofertę” – jaki użytkownik? Co ta akceptacja oznacza?

Odrębną sytuacją są wymagania, które okazują się niepełne, a wręcz czasem błędne:

„System powinien umożliwiać wybór koloru poszczególnych elementów produktu B, tak jak zostało to opisane w produkcie A” – brzmi dobrze, ale okazuje się, że: produkt A ma możliwość wyboru tylko jednego głównego koloru dla całego produktu, produkt B ma możliwość ustawienia różnych kolorów dla poszczególnych jego części, ale niektóre kolory nie łączą się ze sobą z uwagi na konieczność zachowania spójnej tonacji całości produktu B. W produkcie A jest prosta lista kolorów. W produkcie B jest kilka list kolorów. Wybranie jednego często powoduje zawężenie listy kolorów na pozostałych listach wybieralnych.

Podsumowanie

Specyfikacja wymagań to bardzo ważny element dokumentacji projektowej. Najczęściej spotyka się opisy wymagań jako przypadków użycia. Jest to najprostsza i najczytelniejsza forma.

Warto zwrócić również uwagę na fakt, że każdy posługuje się swoim branżowym słownictwem. Ważne jest, aby używać języka w sposób zrozumiały dla obu stron. Pamiętaj, że w opisie specyfikacji wymagań nie jest konieczna żadna specjalistyczna wiedza. Głównym zadaniem tego dokumentu jest zebranie wszystkich funkcjonalnych wymagań oprogramowania w przystępny i uporządkowany sposób. Najważniejsze jest, aby dokument specyfikacji wymagań zawierał wszystkie istotne informacje z punktu widzenia klienta.

Opis wymagań możesz stworzyć na własną rękę, jednak pamiętaj, że zawsze istnieje możliwość wsparcia. Jeśli zajdzie taka potrzeba to zasięgnij rady zespołu analitycznego. Dodatkowo, jeśli zależy Ci na profesjonalizmie, możesz również skorzystać z usług firm trzecich, takich jak nasza.

Consulting świadczy usługi doradcze odpowiednio dobranymi narzędziami IT w zakresie m.in. systemów operacyjnych. Poprzez serię wspólnych spotkań z najlepszymi specjalistami przeprowadzana jest dogłębna analiza wraz z opisem wymagań. Często w trakcie spotkań wychodzą wszystkie wątpliwości, oczekiwania i pytania z obu stron. Takie przygotowanie pozwoli ustalić wspólną wizję systemu, co przekłada się na lepiej wykonaną pracę.

Sprawdź, jak przebiegają poszczególne etapy consultingu w Evertop.