Jak prawidłowo przygotować specyfikację projektu dla software house’u

Wstęp

Wstępną formą dokumentacji przyszłego produktu IT jest specyfikacja projektu, opisująca jego podstawowe cechy, założenia oraz cele. Jej przygotowanie jest szczególnie istotne w przypadku rozwiązań o dużym zasięgu, których poprawne wdrożenie jest bardzo istotne dla działalności przedsiębiorstwa. Aby współpraca z firmą realizującą zlecenie przebiegała sprawnie, należy bardzo starannie przedstawić jej pracownikom wstępny zarys projektu. Jak prawidłowo sporządzić taką specyfikację i jakie informacje muszą się w niej znaleźć? Zacznijmy od początku i zadajmy sobie najważniejsze pytanie.

Czym jest specyfikacja projektu IT?

Specyfikacja to dokument zawierający wszystkie kluczowe kwestie związane z projektem IT, którego realizacja zlecona zostanie zespołowi software house’u. Pozwala ona na przedstawienie programistom, grafikom, projekt menedżerom wstępnego zarysu projektu (z uwzględnieniem jego najważniejszych cech oraz celów powstania), a także dokładnego opisu działania funkcjonalności każdego elementu naszego produktu.

Dotyczy to zarówno ogólnego wyglądu oraz podstawowych funkcji produktu końcowego, jak i zastosowanych w nim technologii. W dużym uproszczeniu, specyfikacja projektu IT opisuje, jak powinno działać oprogramowanie, a także jakie akcje będzie mógł za jego pośrednictwem wykonać użytkownik końcowy. Celów sporządzenia tego rodzaju dokumentacji jest jednak znacznie więcej. Przyglądając się bliżej kolejnym elementom dokumentacji, wyróżnić można szereg sekcji o konkretnej wartości dla wykonawców.

Jaką treść obejmuje specyfikacja projektu?

Typowa specyfikacja zawiera przede wszystkim ogólny opis projektu, włącznie z zakresem działań, które wykonywane będą w jego obrębie. Powinna uwzględniać także wszelkie materiały dodatkowe, najlepiej w formie wygodnych załączników – np. linków do tekstów, grafik czy makiet. Ważną kwestią pozostają wymagania techniczne, niezbędne do przygotowania danego produktu.

Specyfikacja powinna określać, na jakie urządzenia oraz jakie systemy operacyjne przeznaczone będzie oprogramowanie, a także z jakich integracji może w zamierzeniu korzystać. Pisząc o integracjach mam na myśli np. połączenie z zewnętrznym systemem fakturowym, CRM, systemem magazynowym, czy narzędziem do automatyzacji marketingu. Dobrze jest opisać, jak mają działać te połączenia i jakie dane powinny być pomiędzy sobą przekazywane.

Kolejny aspekt to komunikacja między front-endem (czyli warstwą wizualną – tym, co widzi użytkownik w przeglądarce lub aplikacji) oraz back-endem (częścią serwerowa, operacyjną). W specyfikacji warto podkreślić, które dane wysyłane na serwer będą krytyczne dla działania aplikacji. Na tej podstawie dużo łatwiej jest zaprojektować cały system.

W specyfikacji uwzględniane są także zaawansowane funkcje aplikacji, czyli jej poszczególne moduły składowe, możliwe do wykonania akcje czy zawarte w treści informacje. Dokumentacja uwzględnia także wszelkie elementy dodatkowe, wychodzące poza standardowy zakres projektu – najczęściej dotyczy to aspektów przygotowywanych przez inne zatrudnione podmioty, zajmujące się np. kwestiami związanymi z obsługą hardware.

Dlaczego specyfikacja projektu jest niezbędna?

Opracowywanie projektów oprogramowania, aplikacji, systemów czy stron www bez odpowiedniej specyfikacji zwykle kończy się niepowodzeniem. Taki stan rzeczy jest najczęściej następstwem braku dostatecznego zaangażowania, niewłaściwego zaplanowania prac lub wyboru nieodpowiedniej technologii, a przede wszystkim niedostatecznej komunikacji inwestora z wykonawcą. Wszystkie te czynniki bezpośrednio przyczyniają się do braku możliwości sporządzenia dobrej dokumentacji projektu. W wielu takich przypadkach klient zachowuje najważniejsze założenia wymarzonego produktu wyłącznie we własnej głowie, przez co większość szczegółów pozostaje niejasna dla członków zespołu wykonawczego. Poszczególne zadania i instrukcje powinny być zatem odpowiednio sformułowane oraz przejrzyście rozpisane w formie prawidłowo sporządzonej specyfikacji. W przeciwnym wypadku cała komunikacja między klientem, a wykonawcami oraz użytkownikami będzie niedostateczna, co przełoży się negatywnie na przepływ informacji także na etapie wdrażania produktu.

Jak przekazać swoją wizję zespołowi software house’u?

Wiele elementów specyfikacji należy ustalić już na początkowym etapie planowania projektu. Podstawą tego działania jest przede wszystkim umiejętne scharakteryzowanie potrzeb użytkownika, do którego kierowany jest końcowy produkt. Na przykład, w przypadku tworzonego na zamówienie oprogramowania biurowego, zespół programistów z software house’u powinien poznać dokładny zakres rzeczywistych potrzeb pracowników biura tak, aby móc określić, w jaki sposób stworzone przez nich oprogramowanie będzie pomocne dla przyszłych użytkowników.

Jeżeli natomiast przedmiotem projektu jest aplikacja handlowa lub usługowa, należy dokładnie określić rynek, na który jest kierowana – dotyczy to zarówno ogólnego przedstawienia warunków panujących w danej branży, jak i sprecyzowania oferowanych w jej ramach produktów lub usług. W specyfikacji powinny zatem znaleźć się wszystkie wymagania, którym musi sprostać projekt.

Jak określić i spełnić potrzeby użytkowników?

Produkt IT wykonywany na podstawie projektu powinien zaspokajać konkretne potrzeby użytkowników. Specyfikacja musi więc uwzględniać wszystkie sposoby, które to umożliwiają. Na tym etapie osoba zamawiająca oprogramowanie powinna być zaangażowana w realizację końcowej wizji w takim samym stopniu, co wykonawca. Członkowie software house’u mogą jednak zapewnić niezbędne wsparcie jeszcze w procesie kształtowania się koncepcji, udzielając porad oraz przedstawiając własne pomysły.

Aby zapewnić zespołowi lepsze warunki do zrozumienia celów wyznaczonych w dokumentacji, dobrym nawykiem jest dostarczenie przez klienta badań rynkowych przeprowadzanych w bezpośrednim odniesieniu do założeń projektu. Ważny etap sporządzania specyfikacji projektu to także analiza SWOT. Należy ona do podstawowych metod strategicznej analizy przedsiębiorstwa, pozwalających na ocenę mocnych i słabych stron projektu, a także szans i zagrożeń występujących w jego ramach. Na tym etapie kluczowe znaczenie ma identyfikacja konkurencji oraz określenie sposobów, w jakie udoskonalana będzie nowa aplikacja.

Czym jest Specyfikacja Wymagań Oprogramowania?

Specyfikacja Wymagań Oprogramowania (Software Requirements Specification – SRS) jest przydatnym dokumentem analitycznym, w którym zawarte są wszystkie zidentyfikowane, funkcjonalne oraz poza-funkcjonalne wymagania użytkowników. Celem jego obecności w kompletnej specyfikacji jest precyzyjne i zrozumiałe przekazanie programistom rzeczywistych założeń produktu powstałego w oparciu o projekt.

Proces przygotowania SRS opiera się na serii analitycznych wywiadów, przeprowadzanych z klientami, menedżerami oraz innymi udziałowcami. Następnie dokładnie analizowana jest dostępna dokumentacja oraz powiązane z projektem kwestie prawne. Członkowie zespołu mogą dzięki temu w każdym momencie odwołać się do zwięzłego, jasnego i przejrzystego dokumentu, który stanowi realną pomoc w przygotowywaniu produktu dobrej jakości.

Jakie informacje przedstawić można w SRS?

Specyfikacja Wymagań Oprogramowania powinna zostać sporządzona dopiero po nakreśleniu głównych założeń projektu. Jej treść musi jednak uwzględniać kilka równie ważnych aspektów. Znaczenie ma bowiem nie tylko cel stosowania tworzonego oprogramowania, ale również sposób działania jego interfejsów zewnętrznych. Pod uwagę brana jest ponadto oczekiwana wydajność produktu, a także jego główne funkcje. W specyfikacji należy uwzględnić obecność usprawnień, np. związanych z ułatwieniem dostępu do obsługi technicznej czy zwiększeniem poziomu bezpieczeństwa i prywatności użytkowników. Nie bez znaczenia pozostają także wszelkie ograniczenia narzucone z woli inwestora, wynikające np. z obowiązujących standardów, zasad dotyczących integralności baz danych czy niedostatecznej ilości dostępnych zasobów.

Dlaczego warto sporządzić SRS?

Prawidłowo wykonana specyfikacja wymagań oprogramowania to nie tylko kompletne źródło wiedzy, ale też solidna podstawa umowy zawieranej przed rzeczywistym rozpoczęciem prac. Stanowi punkt odniesienia na etapie prognozowania terminów i kosztów realizacji, a jednocześnie daje możliwość znacznego ograniczenia konieczności przeprowadzania prac dodatkowych przez software house.

Przygotowanie specyfikacji wymagań oprogramowania ułatwia też zespołowi wstępne określenie własnych wymogów, a tym samym ograniczenie konieczności nanoszenia ewentualnych zmian w kodzie.

Inwestor może też przedstawić w specyfikacji SRS wczesne wyobrażenie interfejsu oprogramowania, włącznie ze słownym opisaniem każdego modułu. Bardzo przydatne okazuje się dodatkowe utworzenie ścieżek działań użytkowników – dzięki temu każda funkcjonalność może być opisana zgodnie z tym, czego oczekują od niej klienci.

Kiedy możliwa jest automatyzacja procesu tworzenia specyfikacji?

Zautomatyzowanie procesu tworzenia specyfikacji to dobre rozwiązanie dla powtarzalnych oraz wcześniej wdrażanych projektów. Automatyzacja sprawdza się także wówczas, gdy dokumentacja nie wymaga uwzględnienia żadnych unikalnych, szczególnych lub rzadkich informacji. Pójście na skróty nie zawsze jest jednak możliwe. Nierzadko bowiem projekt jedynie w założeniach sprawia wrażenie identycznego, podczas gdy w praktyce wymaga np. ręcznego dodania wyników analizy SWOT – osobnych dla każdego zastosowania lub wymogów określonej branży.

Warto pamiętać, że automatyzacja tworzenia specyfikacji pozwala na zredukowanie wielu błędów popełnianych podczas etapowego sporządzania dokumentacji, a także oszczędza cenny czas inwestora. W celu prawidłowego przeprowadzenia automatyzacji procesu przygotowania dokumentacji projektu, można skorzystać z usług zewnętrznej firmy. Wiele tego typu przedsiębiorstw udostępnia na swoich platformach szablony najczęściej stosowanych specyfikacji.

Na czym polega zarządzanie procesem tworzenia specyfikacji?

Aby zapewnić maksymalną wartość oraz skuteczność specyfikacji projektu, należy w umiejętny sposób zarządzać procesem jej tworzenia. Jeżeli pozwalają na to zasoby firmy, warto opracować wewnętrzny system opracowywania dokumentacji dla przyszłych produktów IT oraz stworzyć strukturę zespołu, który będzie się zajmował związanymi z tym obowiązkami.

Zarządzanie procesem tworzenia specyfikacji wymaga przede wszystkim sformułowania wytycznych, które ułatwią przygotowywanie oraz testowanie tego rodzaju dokumentów. Dla poszczególnych etapów procesu warto też określić konkretne cele, ukierunkowane np. na wykrywanie wad w sporządzanej treści. Pomocne może się okazać opracowanie jasnego, wspólnego standardu wydajności w zespole, który zajmuje się przygotowaniem specyfikacji dla projektu IT.

Pracowników opracowujących dobre rozwiązania warto zatem nagradzać, a tych dostarczających niedostatecznie zoptymalizowane treści – wysyłać na odpowiednie szkolenia. Informacje zawarte w dokumentacji powinny być pozyskiwane z wiarygodnych źródeł, np. od użytkowników należących do potencjalnej grupy docelowej opracowywanego oprogramowania czy aplikacji.

Jakie narzędzia można wykorzystać do przygotowania specyfikacji?

Przygotowując specyfikację, należy wyposażyć się w odpowiednie narzędzia. Poza platformami automatyzacji oraz darmowymi szablonami, warto wykorzystać elementy graficzne oraz inne formy pomocy wizualnej. Dobrym rozwiązaniem jest uwzględnienie prostych tabel i schematów, a w zależności od założeń projektu oraz indywidualnych możliwości także zdjęć i zrzutów ekranu. Wszelkie diagramy i wykresy są w stanie przedstawić programistom pożądany sposób działania opracowywanego rozwiązania informatycznego.

Dobra specyfikacja projektu różni się od słabej także odpowiednim stylem oraz formą tekstu. Nie powinna być pisana wyszukanym językiem literackim, ponieważ pozostaje przede wszystkim dokumentem technicznym oraz użytkowym. Nadrzędną zasadą jest więc zachowanie odpowiedniej hierarchii i struktury treści.

Specyfikacja powinna być napisana zwięźle, a także uzupełniona dużą ilością wypunktowań i wyliczeń. Warto używać pojęć zdefiniowanych oraz jednoznacznych, zwłaszcza w przypadku podawania cen i wartości granicznych. W ten sposób można skutecznie uniknąć burzenia jasności przekazu mało precyzyjnymi wyrażeniami Treść powinna być przede wszystkim kompletna – warto kilka razy upewnić się, że w żadnej sekcji nie brakuje kluczowych informacji.

Czy warto określić budżet projektu w specyfikacji?

W specyfikacji do projektu bardzo przydatne okazuje się określenie dostępnego budżetu. W ten sposób klient przedstawia wykonawcy maksymalną kwotę, którą może przeznaczyć na przygotowanie zlecenia. Na podstawie szacowanego budżetu, ekipa software house’u stara się stworzyć możliwie najlepszy produkt końcowy. Warto określić ramy finansowe jak najwcześniej, aby na kolejnych etapach wdrażania projektu uniknąć niepotrzebnych nieporozumień. Nie bez znaczenia pozostaje to, czy firma realizująca projekt stosuje stawki godzinowe czy ceny stałe. Pod uwagę powinny być brane także wszelkie ograniczenia czasowe. W specyfikacji należy więc dokładnie określić, w jakim terminie projekt powinien zostać zakończony.

Jak dokonać wyceny projektu bez specyfikacji?

Szczegółowa specyfikacja pozwala na otrzymanie kompletnej wyceny od wykonawcy. Dostępne dane wejściowe dają też możliwość szybszego określenia niezbędnej technologii. Wiele jednak zależy od tego, czy projekt dotyczy oprogramowania już istniejącego oraz kwestii związanych z jego rozwojem, czy też zakłada stworzenie zupełnie od podstaw nowego produktu cyfrowego. Ze względów budżetowych, nierzadko wskazane jest wstrzymanie się od sporządzania specyfikacji.

W takiej sytuacji najlepiej wysłać do software house’u zwykłe zapytanie ofertowe. Należy określić w nim cel powstania produktu IT, jego grupę docelową oraz ogólną wizję, razem z uwzględnieniem logiki biznesowej. Warto też od razu skonkretyzować, na jakie platformy oraz urządzenia zaimplementowane zostanie oprogramowanie lub aplikacja. Nie bez znaczenia pozostaje zakres planowanego projektu, włącznie z określeniem konieczności przygotowania strony graficznej oraz sprecyzowaniem terminu realizacji. Dane te pozwalają firmie na wstępne zdefiniowanie ogólnego kształtu projektu, dzięki czemu zwykle wystarczają do dokonania szacunkowej wyceny.

Jak sprawdzić poprawność specyfikacji?

Aplikacje oraz inne produkty opracowywane przez zespół software house’u nie należą niestety do dóbr namacalnych. Ich wartość jest stosunkowo nieuchwytna, a faktyczną przydatność zastosowanych rozwiązań często ocenić można dopiero podczas bezpośredniego użytkowania.

Na większości etapów opracowywania specyfikacji projektu konieczne jest więc operowanie zagadnieniami bardzo abstrakcyjnymi, a następnie ubranie ich w słowa zrozumiałe oraz jasne dla członków danego zespołu. Aby sprawdzić, czy dokumentacja stworzona samodzielnie, przez pracownika lub podwykonawcę spełnia podstawowe wymogi, warto poprosić o ocenę osoby najbardziej do tego kompetentne. Programiści mogą np. zweryfikować, czy po lekturze specyfikacji wszystkie kluczowe informacje są dla nich jasne. W miarę możliwości, dobrym rozwiązaniem jest także konsultacja z potencjalnymi użytkownikami końcowymi opracowywanego oprogramowania lub aplikacji. Są oni w stanie udzielić wielu wartościowych porad, np. sugerując, jakie dodatkowe funkcje i rozwiązania byłyby sporym udogodnieniem w obsłudze gotowego rozwiązania.

Przeprowadzanie tych działań pozwala zwykle na zaoszczędzenie wielu godzin dodatkowych analiz. Dzięki konsultacjom można też skutecznie zapobiec ewentualności poprowadzenia prac w niedobrym kierunku, a także uniknąć ryzyka przeoczenia ważnych funkcji końcowego produktu.

Jak postępować po zdaniu specyfikacji?

Na początek najlepiej szczegółowo omówić zlecenie z projekt managerem zespołu programistów. W ten sposób można wyjaśnić wszystkie obawy związane z komunikacją oraz realizowanymi procesami. Projekt managera należy przede wszystkim zapytać, w jaki sposób można zgłaszać do niego nowe pomysły. Znaczenie mają zarówno preferowane narzędzia do komunikacji, jak i struktura jej przepływu.

Warto określić także o rodzaj modelu, na podstawie którego opierać będzie się współpraca. Istotne pozostają kwestie związane z zarządzaniem organizacją pracy, włącznie z formą powiadomień w przypadku opóźnień lub niespodziewanych problemów. Podczas rozmowy można też dowiedzieć się, którzy pracownicy software house’u będą odpowiedzialni za projekt oraz jakie wymagania klienta są w stanie spełnić.

Warto ponadto sprawdzić, w jaki sposób priorytety danego projektu przekładają się na szacunki, iteracje czy procesy inicjowane przez członków zespołu. Nie bez znaczenia pozostaje sposób, w jaki dystrybuowany będzie końcowy produkt oraz jak zleceniodawca może pomóc w procesie jego opracowywania. Przed rozpoczęciem rozmowy warto też przygotować się do pytań zadanych przez projekt managera. Zwykle dotyczą one kwestii związanych z posiadaniem własnych serwerów, sugestią zastosowania preferowanych narzędzi oraz możliwości konsultacji z dyrektorem technicznym lub innym pracownikiem ds. technicznych firmy.

Kiedy rozpocznie się realizacja projektu?

Specyfikacja projektu powinna zawierać komplet informacji na temat przebiegu całego procesu jego wdrażania. Przed inauguracyjnym spotkaniem rozpoczynającym prace warto się upewnić, że dostęp do kluczowych danych posiadają wszyscy członkowie zespołu. Dotyczy to przede wszystkim informacji związanych z ewentualnym podziałem obowiązków – zespół programistów może bowiem realizować wszystkie prace, bądź też dzielić część projektu z innym zespołem. W tym drugim przypadku kluczowe znaczenie ma dobra organizacja pracy pomiędzy obiema grupami.

Należy też uwzględnić wszystkie dostępne kanały komunikacji. Najlepszym rozwiązaniem jest kombinacja cotygodniowych rozmów oraz codziennych aktualizacji przez zastosowanie różnych narzędzi do zarządzania projektami. Wysyłanie podsumowań emailem może być mocno problematyczne, a późniejsze odnalezienie historii rozmowy w naszym programie pocztowym jest mocno problematyczne.

Samo spotkanie rozpoczynające przebiega zwykle bardzo podobnie. Zespół software house’u szczegółowo wprowadzany jest w temat, co pozwala na przypisanie poszczególnym pracownikom określonych ról – głównych programistów, projekt managera odpowiedzialnego za komunikację oraz testerów oprogramowania, którzy wykrywać będą wszelkie ewentualne błędy projektu. Na tym etapie omawiane są pierwsze kwestie związane z architekturą aplikacji, a także wyborem narzędzi do komunikacji. Na koniec tworzony jest serwer pośredniczący, do którego dostęp mają zarówno członkowie zespołu programistów, jak i sam klient.

Dlaczego warto sporządzić specyfikację projektu?

Przygotowanie dobrej specyfikacji projektu wymaga nieco wiedzy teoretycznej oraz wprawy. Wiele zależy także od umiejętności zespołu pracowników, którzy zajmują się sporządzeniem wstępnej dokumentacji.

Każdemu pracownikowi software house’u bardzo jednak zależy, aby dobrze przygotować się do realizacji projektu zleceniodawcy. Klient ma z kolei pełne prawo poznać wszystkie procesy z tym związane, włącznie z organizacją pracy nad zleceniem powierzonym zespołowi. Pomóc mogą w tym jedynie odpowiednie szlaki komunikacyjne, które znacząco usprawniają współpracę w ramach wszystkie etapów opracowywania produktu IT. Nie są jednak w stanie funkcjonować bez precyzyjnie opracowanej specyfikacji do projektu. Cały proces powinien więc być dokładnie zaplanowany – dzięki temu wszyscy pracownicy dobrze poznają cele, założenia oraz niezbędne funkcjonalności przygotowanego oprogramowania lub aplikacji, a klient zyska pełen wgląd w realizację prac.

Przykładowa specyfikacja projektu

1. Wprowadzenie

1.1 Cel, powód

Identyfikacja naszego produktu, którego wymagania zostały określone w tym dokumencie. Należy opisać zakres produktu, aplikacji, strony, który zostaną objęte niniejszą specyfikacją.

Może zdarzyć się tak, że ten dokument obejmuje tylko pewien zakres funkcjonalności. Czyli jest częścią większego systemu, aplikacji, lub tylko poszczególnym jego modułem. Np. gdy mamy gotową aplikację do rezerwacji naszych obiektów, a planujemy zrobić mikro-usługę, która ma ją integrować z systemami do rezerwacji miejsc noclegowych np. Booking. Należy wszystko to opisać w niniejszej specyfikacji.

1.2 Konwencje użyte w dokumencie

W tym miejscu warto opisać wszystkie standardy użyte w tworzonej przez nas specyfikacji. Zakładamy, że będą one przestrzegane podczas pisania niniejszego dokumentu. Warto wspomnieć kiedy takie rzeczy jak podkreślenia lub „wyboldowania” mają szczególne znaczenie.

Należy także zaznaczyć jak wyglądają kwestie dziedziczenia priorytetów. Czy priorytety głównego punktu (rodzica) są dziedziczone dla jego podpunktów (dzieci). Możemy to sprowadzić do przykładu logowania. Kiedy nasz system musi posiadać system rejestracji i logowania, najwyższe priorytety realizacji mogą mieć właśnie funkcje rejestracji nowego użytkownika za pomocą adresu mailowego i hasła. Zaś dużo niższe, niewymagające realizacji na samym początku tworzenia aplikacji, rejestracje za pomocą mediów społecznościowych – bo te nie są kluczowym aspektem działania całego serwisu.

Oczywiście to tylko przykład i priorytety możesz określić samemu, lub z pomocą software house’u, z którym nawiążesz współpracę.

1.3 Odbiorcy dokumentu

Opisz dokładnie dla kogo został stworzony niniejszy dokument. Czy został przygotowany dla programistów, menedżerów projektu, pracowników marketingu, użytkowników, testerów czy może samych jego twórców i nie powinien ujrzeć światła dziennego. Dzięki temu unikniesz niepotrzebnych komplikacji. Gdy dokument zostanie napisany językiem technicznym może nie być czytelny dla osób, które mają zająć się marketingiem, czy sprzedażą. Zaś bez większych problemów i dwuznaczności przeczytają go administratorzy czy programiści.

1.4 Zakres projektu

To miejsce, w którym należy podać, oczywiście w krótki i przyjazny dla odbiorców sposób, opis oprogramowania, oraz jego cel. Warto także dodać jakie korzyści ma przynieść jego wyprodukowanie. Np. zmniejszenie czasu potrzebnego na wprowadzanie danych z różnych działów, które nie trzymają się standardów, do naszego CRMa. Albo pozyskanie większej ilości danych kontaktowych potencjalnych klientów z formularza.

Jeżeli dostępny jest gdzieś osobny dokument dotyczący wizji jaka przyświeca planowanej produkcji oprogramowania, należy w tym punkcje się do niego odnieść (zamiast powielać jego treść). Jeżeli SRS, nad którym właśnie pracujemy określa kolejną wersję rozwijanego produktu, powinien zawierać własny opis zakresu jaki mamy zrealizować. Czyli opis tylko tych funkcjonalności, które mają się pojawić ponad to co jest w istniejącym systemie.

1.5 Referencje

W tym punkcie wymień wszelkie inne dokumenty lub adresy stron internetowych, do których odnosi się niniejsza specyfikacja. Mogą to być opisy interfejsu użytkownika, umowy, standardy, albo specyfikacje wymagań serwerowych, urządzeń na jakich ma działach aplikacja itd. Należy podać na tyle wystarczającą ilość informacji by osoba, która będzie czytać ten dokument mogła uzyskać dostęp do kopii każdego wspomnianego tutaj zasobu bez zawracania głowy osobom, które mogą nie mieć o tym zielonego pojęcia.

2. Opis ogólny

Napisz ten punkt tak by ludzie, którzy będą go czytać mogli w prosty sposób zrozumieć co ma robić Twoja aplikacja.

Powinno się zasadniczo unikać przewidywania lub definiowania sposobu działania produktu, aby w przyszłości umożliwić projektantom interfejsów i inżynierom korzystanie z ich fachowej wiedzy w celu zapewnienia optymalnego rozwiązania.

Warto też wspomnieć, że zwykle ten punkt jest tworzony z punktu widzenia użytkownika, klienta lub dział marketingowy firmy (w tym drugim przypadku może być również nazywany dokumentem wymagań marketingowych). Wymagania są następnie analizowane przez (potencjalnego) twórcę / dostawcę z bardziej technicznego punktu widzenia.

2.1 Wymagania produktowe

To miejsce, w którym wpisujemy czy produkt, który mamy rozwinąć jest kolejnym elementem, który ma wejść w rodzinę istniejących już produktów, być może ma zamienić istniejącą aplikację, lub ma być nowym samodzielnym rozwiązaniem. To pozwoli określić osobie czytającej z jakim tematem na się zmierzyć i jak nastawić swoje myślenie.

Jeżeli w SRS opisujemy aplikację, która ma wejść jako element, komponent istniejącego już większego systemu trzeba podać odniesienie do wymagań rodzica, oraz opisać powiązania pomiędzy nowym a starym systemem. Dobrą praktyką, jest pokazanie tutaj diagramu przedstawiającego główne komponenty systemu, oraz połączenia jakie istnieją między nimi. Kiedy istnieją lub mają istnieć połączenia z zewnętrznymi systemami np. z CRM, ERP warto to także tutaj opisać.

2.2 Interfejsy systemowe

Opisz środowisko, w którym oprogramowanie będzie funkcjonowało, w tym język(i) programowania, technologię, sprzęt, system operacyjny oraz wszystkie inne składniki lub aplikacje, z którymi rozwiązanie powinno współistnieć. Jeżeli nie znasz się na technologii zostaw to miejsce dla software house’u

2.3 Interfejs użytkownika

To miejsce w którym możemy rozpisać poszczególne pozycje widoków (czyli naszego interfejsu). Może to obejmować przykładowe obrazy ekranu, wszelkie standardy, ograniczenia w układzie, przyciski i funkcjonalności, które będą wyświetlane użytkownikom.

Mogą tutaj się znaleźć takie informacje jak skróty klawiaturowe, standardy wyświetlania komunikatów o błędach czy pozytywnie wykonanych akcjach. Szczegółowy zakres i opis widoków powinien być udokumentowany w osobnej specyfikacji.

2.4 Interfejs oprogramowania

Opisz połączenia między tworzonym właśnie produktem a innymi określonymi komponentami oprogramowania, w tym bazy danych, systemy operacyjne, narzędzia, biblioteki i zewnętrzne narzędzia np. CRM, systemy magazynowe, może bramka SMS.

2.5 Interfejs sprzętowy

Opisz logiczne i fizyczne połączenia pomiędzy interfejsem oprogramowania, a sprzętem. Może to obejmować obsługiwane typy urządzeń, charakter przetwarzanych danych i interakcje między oprogramowaniem, a sprzętem. Nie musisz tego robić jeżeli nie wiesz co masz tutaj wpisać.

2.6 Interfejs komunikacyjny

Opisz wymagania związane z funkcjami komunikacyjnymi wymaganymi przez ten produkt. Może się zdarzyć, że chcemy nawiązać połącznie z pocztą e-mail, zewnętrznym protokołem SMTP, albo przeglądarką internetową.

Zidentyfikuj wszelkie standardy komunikacji, które będą używane w oprogramowaniu, takie jak FTP lub API. Warto tez określić wszelkie zabezpieczenia komunikacyjne, szyfrowanie i szybkość przesyłania danych, oraz ewentualne mechanizmy służące do synchronizacji danych pomiędzy innymi systemami. Np. połączenia z Allegro, czy systemem fakturowym.

3. Funkcje aplikacji

To jedno z ważniejszych miejsce w dokumencie. Opisujemy tutaj funkcje i wymagania dotyczące określonego produktu. Najprościej ujmując – jak ma działać to, co chcemy stworzyć. Następnie opisujemy to punkt po punkcie, widok po widoku.

Ta sekcja powinna być najbardziej rozbudowaną sekcją całej specyfikacji. Można ją organizować według przypadków użycia, typu użytkownika, sposobu działania etc. Nie ma tutaj większych ograniczeń. Staraj się by wszystko co tutaj podasz dało się później przeczytać i Twój odbiorca mógł zrozumieć, jednoznacznie, co miałeś na myśli.

3.1 Pierwsza funkcja aplikacji

To może być np. rejestracja, albo strona główna naszego serwisu. Staramy się rozpisywać całość element po elemencie, lub funkcję po funkcji.

Każdą z tych rzeczy rozpisujemy jako osobny podpunkt

3.1.1 Priorytet realizacji.

Jeżeli chodzi o priorytet należy określić czy jest on wysoki, średni czy niski. Można określić tutaj także takie rzeczy jak koszty i ryzyko, jakie wiąże się z wytworzeniem tej części projektu, w skali od 1 do 5, lub 1 do 10.

3.1.2 Sekwencje działań

Opisz krok po kroku co robi użytkownik i co wchodzi w składowe widoku, na którym operuje.

Np. Użytkownik po wejściu na stronę widzi formularz składający się z pól:

• Imię i nazwisko
• E-mail
• Hasło
• Pole do akceptacji regulaminu
• Pole do akceptacji zgody o przetwarzaniu danych

Określ jakie pola są wymagane, jakie nie i co ma się stać gdy użytkownik kliknie w przycisk wysłania formularza.

3.1.3 Wymagania funkcjonalne

Wymień szczegółowe wymagania funkcjonalne związane z działaniem tej funkcjonalności. Wymień szczegóły możliwości w jakiej zachodzi dany przypadek.

Np. aby wykonać tą funkcję użytkownik musi posiadać konto w systemie i być zalogowany. Należy opisać w jaki sposób aplikacja powinna reagować na błędy i nieprawidłowe dane wprowadzone przez użytkownika. Wymagania należy formułować w sposób zwięzły i jednoznaczny.

4. Inne elementy

Wszystkie inne elementy jakie nie zostały wcześniej opisane w dokumencie, a które to są niezbędne do realizacji zadania