Jak przygotować specyfikację wymagań. Tworzenie dedykowanych aplikacji i oprogramowania na zamówienie

Specyfikacje  wymagań muszą odpowiadać potrzebom projektu i ludzi, którzy je piszą i czytają. Tak jak strony internetowe, aplikacje internetowe czy oprogramowanie które muszą być zaprojektowane w taki sposób, aby miały najlepszą użyteczność dla klienta i użytkownika - tak  opracowanie dokumentu specyfikacji wymaga analizy i iteracji.

Specyfikacje wymagań dla projektu służą trzem celom:

1. zapewnieniu, że powstaje właściwy produkt;
2. zapewnieniu punktu odniesienia, który wyznacza koniec na etapie planowania;
3. umożliwienia dokładnego przeglądu i uzyskania informacji zwrotnych od ludzi na temat kierunku projektu.

Te trzy zadania są niezwykle ważne i jest mało prawdopodobne, aby cokolwiek innego niż pisemna specyfikacja wykonywało je wszystkie jednocześnie. Już sam ten powód jest wystarczający, aby z całego serca poprzeć potrzebę przygotowania takiego dokumentu. 

Co mogą a czego nie mogą robić specyfikacje wymagań?

Specyfikacje, podobnie jak wizja, są formą komunikacji: przekazują ważne informacje w prosty i jasny sposób.

Co mogą robić specyfikacje wymagań?

• skutecznie opisywać  funkcjonalność produktu;
• pomagać projektantom w wyjaśnieniu podjętych decyzji poprzez zachęcanie do konkretności;
• stwarzać warunki do sprawdzania, kwestionowania i omawiania szczegółowych informacji  i planów jeszcze przed rozpoczęciem realizacji projektu;
• przekazywać  informację od jednego do wielu;
• budować punkt odniesienia dla całego zespołu w zakresie planu pracy; 
• prezentować harmonogram projektu w postaci kamieni milowych;
• zapewniać zabezpieczenie na wypadek, gdyby autor (lub autorzy) projektu zwolnili się z pracy;
• przyspieszać, poprawiać i zwiększać regularność dyskusji;
• ułatwiać liderom zespołów przekazywanie informacji zwrotnych i ustalać standardów jakościowych;
• dawać  zespołowi (i autorowi) obiektywne spojrzenie i pewność siebie.

Czego specyfikacje nie mogą i nie powinny robić?

• wykluczać jakąkolwiek dyskusję między członkami zespołu;
• udowodniać zespołowi, jak sprytny jest autor;
• udowodniać, jak ważna jest dana funkcja (i dlaczego nie można jej wykluczyć);
• narzucać ludziom filozoficzne podejście;
• dawać autorowi możliwość wykazania się umiejętnościami w zakresie obsługi programu Visio i UML.

Jeśli istnieje szablon specyfikacji dla całego zespołu, powinien on spełniać kryteria przyjęte w wyniku dyskusji.

Jakie specyfikacje wymagań są potrzebne?

Każda metodyka wytwarzania oprogramowania lub zarządzania projektami inaczej definiuje specyfikacje. Nie ma w tym nic złego.
Istnieją cztery podstawowe rodzaje informacji, które wchodzą w skład specyfikacji. Najłatwiejszym sposobem na ich omówienie jest wyobrażenie sobie, że dotyczą one czterech różnych dokumentów. Ważne jest, aby potrzebne informacje pochodziły od ludzi, którzy je rozumieją oraz aby format był łatwy do odczytania. W małych zespołach często łączy się różne rodzaje specyfikacji. 

W większych zespołach lepiej jest je rozdzielić, a nawet przydzielić je różnym osobom (ale połączenie powinno być zachowane).

1. Wymagania.
   W specyfikacji zaznacz wszystkie zadania i obowiązki do wykonania. Innymi słowy, zbierasz wszystkie wymagania dla danego stanowiska i ustalasz punkt odniesienia. W idealnym przypadku jest to lista warunków, od których zależy powodzenie projektu, opisują  efekt końcowy,  ale nie wyjaśniają, jak to wszystko osiągnąć. W każdym przypadku wymagania powinny być zdefiniowane przed rozpoczęciem projektowania (choć mogą być zmieniane) i aktualizowane później), i powinny one opierać się na tej wizji. Dla jasności  powinny być uzupełnione o specyfikacje funkcjonalne (tj. aby zrozumieć, jak dobrze plan spełnia wymagania).
   
   
2. Specyfikacje funkcjonalne
   Opisują zachowanie produktu w scenariuszu użytkownika. Wynikają one z projektu i ilustrują funkcjonalność oprogramowania poprzez interfejs użytkownika (jeśli istnieje) i szczegóły jak rzeczy powinny działać z nietechnicznego punktu widzenia.  Pokazują również, jak zmieni się doświadczenie klienta po zakończeniu prac, oraz przedstawiają listę konkretnych zadań projektowych. Wykaz ten różni się od wymagań tym, że definiuje  rozwiązanie projektowe, które spełnia wymagania, w tym interfejs użytkownika i inne nietrywialne elementy. Specyfikacje funkcjonalne, jeśli są wykonane kompetentnie, są niezwykle proste - wystarczą np. zrzuty ekranów z objaśnieniami.
   
   
3. Dane techniczne.
   Dokumenty te szczegółowo opisują  podejście inżynierskie niezbędne do wdrożenia specyfikacji funkcjonalnych. Szczegółowość powinna być wystarczająca do opisania najbardziej złożonych lub nadających się do ponownego użycia komponentów, z których mogą korzystać inni programiści oraz uzasadnić komponenty robocze potrzebne do specyfikacji funkcjonalnej. Czasami stopień szczegółowości i techniczności tych ostatnich wyklucza potrzebę sporządzania oddzielnych specyfikacji technicznych.
   
   
4. Lista pozycji roboczych.
   Lista pozycji roboczych opisuje każde zadanie programistyczne wymagane do zaimplementowania specyfikacji funkcjonalnej. Powinnna być podzielona na części, które oddzielają elementy różnych poziomów ważności, podając terminy (w dniach), uwzględniając ograniczenia czasu ich trwania, np. dzień lub pół dnia (o tym decydują programiści). Tworzenie listy roboczej  jest wyłącznie przywilejem programistów.
   
   Listy elementów roboczych nie są specyfikacjami, ale planem implementacji. Są one jednak ważne i związane ze specyfikacjami. Po opracowaniu specyfikacji funkcjonalnej należy przygotować kryteria testowania  i kryteria zakończenia etapu. Będą to priorytetowe scenariusze testowe dla nowej funkcjonalności, jak również kryteria jakości kodu. 

Najprostsze podejście do tych czterech typów specyfikacji jest w przybliżeniu chronologiczne:

1. wymagania,
2. funkcjonalność,
3. parametry techniczne
4. lista pozycji roboczych.

Jak w wielu projektach, każdy rodzaj informacji uzyskany z wykonanego etapu staje się podstawą do uruchomienia następnego etapu specyfikacji. Im większy  zespół i im bardziej złożony projekt, tym wyraźniejsze jest rozróżnienie między  te rodzaje specyfikacji.

Jak napisać funkcjonalną specyfikację wymagań?

Opisz funkcjonalności, których potrzebujesz w formacie przypadku użycia.

Najprostszym sposobem na opisanie  jest następujący sposób:
[rola użytkownika]
może [akcja],
[opis celów użytkownika oraz niezbędnych kroków i opcji].
Optymalnie, opis dużych komponentów powinien być podzielony na mniejsze części.

Ostatecznie, elementy specyfikacji  powinny być obiektywne, prosto sformułowane i stanowić elementarne wymagania, które można zweryfikować.

Na przykład, dość adekwatne wymagania funkcjonalne w formie:

Użytkownik zewnętrzny musi mieć możliwość zarejestrowania się na stronie internetowej, wypełniając formularz rejestracyjny (pamiętając o podaniu imienia i nazwiska, adresu e-mail oraz pożądanego hasła). Użytkownik zewnętrzny musi mieć również możliwość zalogowania się na stronie internetowej za pomocą swojego adresu e-mail i hasła, jeśli posiada konto. Jest to konieczne, aby mógł on wykonywać czynności wymagające posiadania konta (np. kupować artykuły w sklepie internetowym lub zostawiać komentarze).

Każdy uwierzytelniony (zalogowany) użytkownik zewnętrzny musi mieć możliwość wylogowania się, na przykład po to, aby uniemożliwić innym użytkownikom komputera wykonywanie dalszych czynności na stronie internetowej we własnym imieniu.

Przykłady nieprawidłowych wymogów dotyczących specyfikacji wymagań.
Wymagania subiektywne to wszystkie wymagania z przymiotnikami wartościującymi, takimi jak wygodny, piękny, prosty i tym podobne. Są one nieprawidłowe dla specyfikacji wymaań, ponieważ nie ma sposobu, aby sprawdzić, a więc przyjąć pracę, w oparciu o tak podane kryteria.

"Formularz logowania musi być przyjazny i przejrzysty dla użytkownika".

Niejasno określone wymagania są kolejnym przykładem tego, czego nie powinno być w specyfikacji. Takie wymagania są sformułowane w taki sposób, że bez odpowiedniego przeszkolenia nie można np. zrozumieć, o co chodzi:

Wymagania subiektywne są najczęściej formułowane przez biznes i marketing, natomiast wymagania niejasne są najczęściej formułowane przez informatyków i innych specjalistów technicznych. Należy zająć się obiema tymi kwestiami, ponieważ specyfikacja wymagań powininna być przewodnikiem do działania i listą kontrolną do sprawdzania wykonanej pracy. A nieprawidłowe wymagania prowadzą do tego, że dokument specyfikacji nie może być używany i nie bardzo wiadomo, po co w ogóle został napisany, skoro nikt go nie używa.

Przykłady prawidłowych wymagań specyfikacji wymagań
Więcej przykładów normalnych wymagań funkcjonalnych:

Gość z poziomu dowolnej zakładki  dostępnej na  stronie internetowej może zalogować się do serwisu. Kliknięcie na przycisk "login" otwiera formularz do wprowadzenia nazwy użytkownika i hasła. Jeśli nazwa użytkownika i hasło są wprowadzone poprawnie, użytkownik wchodzi na stronę internetową i jest o tym informowany, a następnie pracuje na stronie jako uwierzytelniony użytkownik i dodatkowe funkcjonalności [jakie?] stają się dla niego dostępne. Jeśli nazwa użytkownika i/lub hasło zostaną wprowadzone niepoprawnie, wyświetlane jest powiadomienie i użytkownik jest proszony o ponowne wypełnienie formularza.

Zarejestrowany użytkownik powinien zobaczyć spersonalizowane powitanie "Witaj, [Imię]!" i link do wylogowania się z witryny, Kliknięcie na imię i nazwisko przeniesie użytkownika do jego danych na  osobistym profilu. Kliknięcie na link "wyloguj" wyloguje go i będzie mógł korzystać ze strony jako gość.

Z reguły wymagania funkcjonalne ewoluują: są precyzowane i dopracowywane zarówno w procesie zatwierdzania, jak i w procesie wytwarzania.

Na przykład, opis procedury rejestracji może wyglądać następująco:

Gość powinien mieć możliwość zarejestrowania się na stronie. Aby to zrobić, może z dowolnej strony witryny poprzez link "zarejestruj się" przejść do strony z formularzem rejestracyjnym.
Formularz rejestracyjny zawiera pola: Nazwisko, Imię, Adres e-mail, Hasło i jego Potwierdzenie, oraz flagę zgody na przesyłanie dodatkowych ofert. Wszystkie pola są obowiązkowe. Adres e-mail musi być prawidłowym adresem e-mail, Hasło musi składać się z co najmniej 6 znaków i zawierać litery i cyfry, Hasło i Potwierdzenie hasła muszą być takie same, flaga zgody na ofertę publiczną  być ustawiona. Jeśli formularz jest wypełniony niepoprawnie, wyświetlana jest lista błędów, a pola z błędami są podświetlane.
Po poprawnym wypełnieniu i wysłaniu formularza rejestracyjnego, gość zakłada nowe konto, a na podany adres e-mail zostaje wysłana wiadomość z powiadomieniem o rejestracji i linkiem do aktywacji konta. Aby aktywować konto, użytkownik musi skorzystać z otrzymanego linku, po czym zostanie automatycznie uwierzytelniony (zalogowany).

Jeśli użytkownik nie otrzymał linku aktywacyjnego, może poprosić o jego ponowne przesłanie, podając swój adres e-mail; w takim przypadku powinien również otrzymać wiadomość z informacją, aby poszukać przesłanej wcześniej wiadomości e-mail w skrzynkach śmieciowych.

Logowanie za pomocą formularza logowania przed aktywacją konta nie jest możliwe, w przypadku próby logowania lub rejestracji z nieaktywnymi danymi konta, użytkownik powinien otrzymać powiadomienie, że konto jest nieaktywne i zostać poproszony o ponowne wysłanie maila z linkiem do aktywacji konta.
Jeśli użytkownik nie aktywuje swojego konta w ciągu tygodnia, zostanie ono usunięte z bazy danych.
Jeśli użytkownik, który jest już zarejestrowany i uwierzytelniony, kliknie na link "zarejestruj się", formularz rejestracyjny nie powinien być wyświetlany, ale powinien zostać przekierowany na stronę profilu bieżącego użytkownika z powiadomieniem: "Jesteś już zarejestrowany i zalogowany".

Tak szczegółowa specyfikacja nie jest może zbyt łatwa do napisania, ale dokładnie opisuje wymagania dla końcowej logiki komponentu, co pozwala na sprawne dostarczenie i odbiór wykonanej pracy.

Oczywiście, pisząc jakąkolwiek specyfikację, racjonalne jest zachowanie równowagi pomiędzy kompletnością / wymaganiami szczegółowości a łatwością zrozumienia / napisania samej specyfikacji.

Nadmierna szczegółowość jest czasochłonna i powoduje, że specyfikacja wymagań jest przeładowana oczywistymi szczegółami, natomiast niedostateczna szczegółowość powoduje, że niektóre ważne wymagania nie są opisane i mogą nie zostać wdrożone. Zadaniem analityka biznesowego piszącego specyfikację wymagań jest właśnie znalezienie równowagi pomiędzy kompletnością a zwięzłością.

Poziom szczegółowości wymagany w specyfikacji wymagań zależy zazwyczaj od kompetencji specjalistów i kultury organizacyjnej. Profesjonalistom można powierzyć zadania wysokiego poziomu i rozwiążą je w odpowiedni sposób, natomiast początkującym lepiej jest uszczegółowić zadania, zdekomponować je i sformułować kryteria akceptacji. 

Kiedy będzie gotowa specyfikacja wymagań?

Dla każdego harmonogramu rozwoju obejmującego fazę planowania, pisanie i sprawdzanie specyfikacji jest naturalnym zakończeniem. Teoretycznie, po tym zespół powinien znać większość szczegółów na temat produktu końcowego i zasad jego konstrukcji. Projekt jest gotowy do realizacji, a cała uwaga przenosi się z planistów i projektantów na programistów i testerów.

Kiedy będzie gotowa specyfikacja? Jest to dość kontrowersyjne pytanie. Zawsze istnieją nierozwiązane kwestie lub zależności od innych firm i projektów, które nie są jeszcze w pełni odwzorowane. Stempel "zakończono" może oznaczać bardzo różne poziomy ukończenia i jakości, w zależności od projektu i zespołu.  Jak w przypadku każdego innego aspektu projektu na wysokim poziomie  tylko liderzy zespołów mogą zdecydować, kiedy uznać pracę za wykonaną.
Ogólna zasada jest jednak taka sama: im więcej kompetencji, tym lepsze specyfikacje, tym większe prawdopodobieństwo, że rezultat zostanie osiągnięty w odpowiednim czasie. 

Pytanie: Jaki stopień prawdopodobieństwa jest Ci potrzebny? Czy warto tracić czas na poprawę specyfikacji o 5%? Czy też programiści  mogą ustalać te szczegóły na bieżąco?  Nie ma łatwych odpowiedzi: trzeba polegać na własnym przeczuciu. Myślę, że doświadczenie w zarządzaniu projektami znaczy tu więcej niż umiejętność programowania czy talent pisarski. Ale ważne jest, aby zauważyć: niezależnie od poziomu kompletności, jakiego oczekujesz, jedynym sposobem na uzupełnienie specyfikacji jest weryfikacja. Trzeba, aby wszyscy  uczestnicy  projektu sprawdzili tekst  specyfikacji i przekazali swoje opinie.

Jak postępować z pytaniami otwartymi?

Niezależnie od tego, jak dobrze zespół radzi sobie z procesem projektowania, podczas pisania specyfikacji zawsze pojawiają się  problemy i pytania. Jeśli pozostaną one nierozwiązane, dojdzie do katastrofy. Wiele kłopotów w połowie projektu jest spowodowanych nierozwiązanymi problemami na samym początku tego projektu.

Skuteczne rozwiązanie problemów, które pojawiają się w związku ze stawianiem pytań otwartych zależy wyłącznie od  staranności. Ktoś musi badać potencjalne problemy i jednocześnie je zapisywać. Po spisaniu zagadnień, można nadawać im priorytety, przypisywać do osób i zajmować się nimi. Jeśli nie poświęcisz na to czasu, prawdopodobieństwo pojawienia się poważnych problemów wzrośnie w później.

Jeśli w ten czy inny sposób zapisujesz trudne punkty, proponuję kilka podstawowych pytań, które pomogą Ci nadać im priorytety i dopracować je.

• Kiedy trzeba rozwiązać problem? Kto jest najbardziej kompetentny do podejmowania koniecznych decyzji?
• Czy ten problem można wyizolować, np. sprowadzić do konkretnego komponentu lub scenariusza? Czy też ma to wpływ na całą funkcję/funkcjonalność lub cały projekt?
• Wymień możliwe rozwiązania problemu, które są  są nadal rozważane. Jak każde z możliwych rozwiązań wpłynie na specyfikację?
• Czy można wykluczyć ten problem? Jak to faktycznie wpływa na klienta w scenariuszu użytkownika o najwyższym priorytecie?
• Czy możliwe jest podzielenie problemu na małe zadania, które można (i należy) delegować na inne osoby?
• Kto lub co przeszkadza w rozwiązaniu problemu i co się robi, aby usunąć tę przeszkodę? 

Jeśli pojawia się dużo dużych problemów i trudno je podzielić na mniejsze zadania,  oznacza to, że coś poszło nie tak w fazie projektowania i/lub kierownictwo zespołu popełniło błąd. Znalezienie rozwiązania problemu wykracza poza zwykłe zarządzanie pytaniami otwartymi.

 Finalizacja specyfikacji wymagań

W harmonogramie projektu należy wyznaczyć konkretny dzień na wykonanie specyfikacji. Jest to prawdopodobnie najważniejszy dzień dla menedżerów.  Często pisanie specyfikacji jest ich głównym zadaniem. a może jedynym znaczącym wkładem w projekt. Gdy specyfikacje są już gotowe, uwaga przesuwa się na zarządzanie projektem, w tym pomoc zespołowi podczas przejścia do fazy rozwoju.

Po sfinalizowaniu specyfikacji, podejście zespołu projektowego powinno ulec zmianie. Każdy powinien zdawać sobie sprawę, że na tym etapie dyskusje dobiegły końca: wiele ważnych decyzji zostało już podjętych. Zespół pokonał wiele wyzwań związanych z poszukiwaniem najlepszych rozwiązań projektowych i sporządzeniem uporządkowanego planu. 

Jak sprawdzić specyfikację wymagań?

Sprawdzanie specyfikacji jest procesem zespołowym. Chociaż w centrum uwagi znajduje się dokument i jego autorzy, zadaniem jest upewnienie się, że wszyscy uczestnicy projektu zgadzają się z tym, co jest napisane w dokumencie. 
Najszybszym i najłatwiejszym sposobem jest zebranie wszystkich w tym samym pomieszczeniu. tak, aby każdy mógł usłyszeć odpowiedzi na pytania, które zostaną zadane.

Chcesz nawiązać współpracę z Python Software House, który tworzy  dedykowane aplikacje webowe, dedykowane aplikacje mobilne i strony internetowe na zamówienie?

Poszukujesz Software House, który ma w swojej ofercie  tworzenie dedykowanych aplikacji internetowych z wykorzystaniem Python, Django i Flask? 

Jesteśmy  Python Software House, który istnieje na rynku 20 lat i ma w swoim portfolio wykonane dedykowane aplikacje webowe,  aplikacje mobilne, desktopowe, oprogramowanie na zamówienie, jak również zaawansowane systemy informatyczne. Tworzymy narzędzia cyfrowe i  rozwiązania, które nie tylko pozwalają wizualizować dane, ale także integrujemy je z regularnymi procesami biznesowymi, tworzymy oparte na danych pełnoprawne dedykowane aplikacje mobilne i webowe, które sprawiają, że dane stają się bardziej dostępne dla całej organizacji.

Może chcesz wykorzystać rozwiązania oparte na algorytmach sztucznej inteligencji, machine learning lub deep learning?

Porozmawiaj z nami o swoim projekcie, a my weźmiemy pod uwagę specyfikę Twojej działalności, przewidziany czas i budżet i wybierzemy najlepszą z dostępnych opcji jego realizacji.