6 kroków do napisania dokumentu SRS, który działa + szablon

6 kroków do napisania dokumentu SRS, który działa + szablon

dokumenty specyfikacji oprogramowania są czasami postrzegane jako artefakty, które mają sens tylko dla programistów. Jednak dokument SRS może pójść dalej i stać się przewodnikiem dla specjalistów ds. marketingu, interesariuszy, zespołów projektowych, a nawet użytkowników.

Ten artykuł wyjaśni, dlaczego dokumentacja oprogramowania ma znaczenie i jak napisać dokument SRS, aby stał się praktycznym przewodnikiem dla wszystkich specjalistów zespołu.

Co To jest dokument SRS i dlaczego ma znaczenie?

dokument SRS (software requirement specification) to artefakt, który zawiera wymagania, oczekiwania i standardy dotyczące przyszłego produktu. Może obejmować dokumenty tekstowe, arkusze kalkulacyjne, Schematy, precedensy i inne elementy, które wyjaśniają wizję produktu. Innymi słowy, dokument SRS zawiera szczegółowy opis tego, jak produkt powinien działać i jak zespół ds. rozwoju produktu powinien go wdrożyć.

wyobraź sobie, że to jak budowanie statku. Masz wizję masztu lub żagla, a nawet możesz sobie wyobrazić, jak podróżuje przez fale. Trzeba jednak bardziej rygorystycznych szczegółów, aby umieścić statek na wodzie.

to samo dotyczy rozwoju produktu. Możesz mieć jasną wizję aplikacji, którą chcesz zbudować, ze wszystkimi funkcjami, elementami projektu i przyciskami. Jednak słowny opis funkcji nie wystarczy, aby Programiści wdrożyli ten pomysł.

aby wynik pasował do obrazu w twojej głowie, musisz dokładnie wyjaśnić na papierze, jak powinna działać funkcja. Dokument SRS jest doskonałym narzędziem do opisywania takich szczegółów technicznych.

kto pisze dokument SRS?

napisanie dokumentu SRS oznacza przeniesienie ogólnych opisów funkcji, zadań i celów do szczegółowego planu ich technicznej realizacji.

dokumenty SRS są zwykle pisane przez kierowników produktów i projektów lub analityków biznesowych, którzy bezpośrednio komunikują się z klientami lub przeprowadzają badania użytkowników (którzy również pracują na szkieletach i wiedzą, jak powinien zachowywać się produkt) i zbierają wymagania przyszłych produktów.

tymczasem ten dokument. Dobry dokument SRS nie jest wyłącznie techniczny, ponieważ obejmuje również cele biznesowe, metryki, problemy użytkowników, personas użytkowników itp.

3 powody, dla których dokument SRS jest ważny

tak więc ogólna wartość dokumentu SRS jest jasna. Oto powody, dla których dokumenty specyfikacji wymagań oprogramowania są niezbędne:

SRS jest punktem komunikacyjnym

jako żywy dokument, dokument SRS służy jako platforma komunikacji między wszystkimi specjalistami: deweloperzy, specjaliści od marketingu i współzałożyciele.

wyjaśniając szczegóły w dokumencie SRS, formalnie lub nieformalnie, menedżerowie uzgadniają z klientami oczekiwania dotyczące wyników. W międzyczasie, jeśli wprowadzone zostaną zmiany w wymaganiach, klient i / lub właściciel produktu mogą je sprawdzić i zatwierdzić w dokumencie. A deweloperzy są odpowiedzialni za spełnienie tych oczekiwań.

ostateczny Opis funkcji

SRS dokumentuje finalne wersje oprogramowania, które pochodziły z założeń omówionych wcześniej z klientami. Podczas spotkań i rozmów telefonicznych, testów użytkowników i wywiadów wersje produktów mogą się bardzo często zmieniać. Czasami nawet menedżerowie produktu mogą zostać przytłoczeni istniejącymi iteracjami produktów. Plik SRS pomaga ujednolicić wszystkie te wymagania w jeden standard i wyeliminować wszelkie nieporozumienia dotyczące wymagań produktu.

SRS jest standardowym przewodnikiem dla programistów produktów

oprócz opisu wymagań dotyczących produktu, dokument SRS prowadzi zespół programistów o krokach, które powinni wykonać, aby zbudować produkt, którego chce klient.

w zależności od organizacji projektu programiści mogą lub nie mogą być zaangażowani w część analityczną projektu. W obu przypadkach muszą dojść do wniosku, jak powinien funkcjonować system, zdefiniować wymagania i parametry kodu, aby mu odpowiadały.

podobnie specjaliści ds. kontroli jakości muszą zrozumieć wszystkie aspekty techniczne, które kryją się za koncepcją produktu. Tak więc dokumentacja SRS służy jako standard planowania i przeprowadzania testów jakości.

wreszcie projektanci uzyskują wgląd w projekt za pośrednictwem dokumentów SRS, aby dopasować projekt do przypadku użycia.

6 kroki do pisania dobrego dokumentu SRS

wymagania funkcjonalne i niefunkcjonalne zajmują dużą część każdego dokumentu SRS. Product managerowie nie biorą tych wymagań znikąd. Są one wynikiem dokładnej komunikacji z klientami oraz dogłębnych badań użytkowników i technicznych. Oto główne kroki pisania doskonałej dokumentacji SRS:

punkt 1. Komunikacja z interesariuszem

usuwamy pierwszą warstwę niepewności, pytając interesariuszy o ich oczekiwania wobec produktu. Oczywiście, taki Wywiad daje tylko trochę zrozumienia wymagań. Jest to jednak nadal świetny punkt wyjścia do badań.

w Uptech najpierw rozmawiamy z klientem w przedsprzedaży i rozpoczynamy rozmowę, próbując dowiedzieć się, czy pasujemy do siebie. Staramy się skrystalizować najdrobniejsze szczegóły dotyczące klienta, aby zrozumieć jego pomysł.

jednak prosta komunikacja nie daje wystarczającej ilości informacji o docelowej grupie odbiorców produktu oraz ich pragnieniach i potrzebach. Więc przechodzimy do etapu odkrywania, aby to wyjaśnić.

punkt 2. Etap odkrywania

etap odkrywania ma kluczowe znaczenie w pisaniu dokumentacji SRS. Na tym etapie mamy możliwość zbadania problemu, który produkt powinien rozwiązać, zainteresowań i potrzeb. Naszym celem jest zidentyfikowanie problemów użytkowników i zdefiniowanie hipotez możliwych rozwiązań ich rozwiązania. Dzięki takiemu podejściu możemy uczynić aplikację wartościową dla użytkownika.

przypadki użycia a historie użytkowników

wszystkie dane użytkownika stają się częścią dokumentu SRS jako przypadki użycia i historie użytkowników. Różnica między tymi dwiema kategoriami jest szeroko dyskutowana wśród społeczności zajmującej się rozwojem produktów.

Mówiąc najprościej, historie użytkowników są bardziej skupione na wynikach i korzyściach, jakie użytkownik otrzymuje podczas korzystania z funkcji. Natomiast przypadki użycia bardziej szczegółowo opisują samą funkcję.

na przykład po wielu wywiadach z użytkownikami w projekcie Yaza doszliśmy do wniosku, że aplikacja powinna mieć czat. Historia użytkownika w takim przypadku brzmiałaby tak :” jako użytkownik chcę porozmawiać z potencjalnym właścicielem domu.”

tymczasem przypadek użycia tej historii opisałby każdy krok użytkownika do osiągnięcia tego celu – ” jako użytkownik, muszę dodać kontakt do mojej listy czatów i wysłać mu/jej wiadomość, aby…”.

Punkt 3. Zbuduj strukturę

po zakończeniu odkrywania przechodzimy do pisania dokumentacji SRS. Po pierwsze, potrzebujemy krótkiej struktury dokumentu. Zawartość dokumentu SRS może się znacznie różnić, ale typowa struktura dokumentacji SRS wyglądałaby następująco:

1. Wstęp

wstęp zawiera podsumowanie treści dokumentu. Ma odpowiedzieć na następujące pytania:

• Krótki opis zawartości dokumentu;
• zamierzonych czytelników tego dokumentu;
• idei tworzonego oprogramowania;
• zamierzonych czytelników.

1.1 cele biznesowe

Utwórz listę celów, które chcesz osiągnąć w projekcie, takich jak stworzenie MVP, stworzenie wieloplatformowej aplikacji mobilnej lub uruchomienie strony internetowej.

poza tym Ta sekcja powinna odzwierciedlać cele i wskaźniki sukcesu Twojej firmy. Chociaż niektórzy mogą wykluczyć tę część z dokumentu, konieczne jest wskazanie tych rzeczy, ponieważ mają one bezpośredni wpływ na badania i rozwój.

1.3 przeznaczenie

jak wyobrażasz sobie, że dana osoba będzie używać Twojego produktu? Jakie są funkcje, które zapewniasz dla tego typu zastosowań? Opisz wszystkie możliwe sposoby, w jakie dana osoba może wykorzystać twój produkt w dowolnej roli użytkownika, którą pełni.

1.4 Zakres

ta część opisuje zakres pracy, którą musisz wykonać, aby wprowadzić swój pomysł w życie.

1.5 definicje i akronimy

ten dokument zawiera definicje terminów używanych w dokumencie, aby zapewnić pełne zrozumienie przez użytkowników.

‍

2. Ogólny opis

oto część, w której wyjaśnisz pomysł aplikacji, skąd pochodzi i dlaczego może być interesująca dla użytkowników.

2.1 potrzeby użytkownika

oprogramowanie, które jest zbudowane dla wszystkich, nikomu nie służy. Ale jeśli wiesz dokładnie, kim jest twoja grupa docelowa, gdzie pracują i ich bóle, będziesz miał większe szanse na dostarczenie aplikacji, która jest powszechnie przyjęta przez użytkowników.

‍

3. Funkcje i wymagania systemu

teraz nadszedł czas, aby przedstawić wymagania techniczne przyszłego oprogramowania. Opisz cechy, które będzie zawierał twój produkt, wraz ze standardami, które określają jakość tych produktów.

3.1 wymagania funkcjonalne

wymagania funkcjonalne to Specyfikacje systemu, bez których oprogramowanie nie będzie działać poprawnie. Definicja, którą podasz swoim funkcjom oprogramowania, określi, w jaki sposób będą one dalej wdrażane.

3.2 Wymagania niefunkcjonalne

podczas gdy wymagania funkcjonalne określają, jaka będzie funkcja systemu, wymagania niefunkcjonalne określają, w jaki sposób system będzie wdrażał te funkcje, na przykład szybkość realizacji.

3.3 tech Stack

tech stack to zestaw rozwiązań technicznych służących do tworzenia i uruchamiania oprogramowania lub projektu. Kluczowe znaczenie ma wskazanie go w dokumencie SRS, ponieważ określa on wszystkie inne szczegóły techniczne.

punkt 4. Zrób ogólny opis

zanim zagłębisz się w szczegóły swojego produktu, przedstaw ogólny przegląd głównych funkcji aplikacji. Po prostu wyjaśnij cel aplikacji, jej funkcje i sposób, w jaki rozwiązują problem użytkownika.

Krok 5. Zdefiniuj wymagania funkcjonalne i niefunkcjonalne

rdzeń dokumentu SRS będzie zwykle składał się z wymagań funkcjonalnych i niefunkcjonalnych produktu. Dzięki takim specyfikacjom można dodać więcej szczegółów do ogólnego przeglądu, a tym samym poprowadzić zespół przez specyfikację techniczną aplikacji.

różnica między wymaganiami funkcjonalnymi i niefunkcjonalnymi jest kolejnym punktem zwrotnym w społeczności rozwoju produktów. Podzieliliśmy się naszą wiedzą na ten temat w tym artykule.

Krok 6. Upewnij się, że zatwierdzenie Klienta na tej samej stronie

jest długo oczekiwaną częścią rozwoju. Jednak zmiany klienta mogą czasami negować całą ilość pracy, wykonanej w pewnym momencie projektu.

aby uniknąć presji, zalecamy wyrażenie zgody na małe części kompletnej dokumentacji SRS, zamiast przesyłania całego pakietu dokumentów na raz. Pomaga to szybko rozwiązać pewne problemy i jest mniej kłopotliwe.

porady ekspertów na temat pisania świetnej dokumentacji SRS

potrzeba czasu, aby doskonalić umiejętności pisania doskonałej dokumentacji SRS. Z naszego doświadczenia wyciągnęliśmy listę porad ekspertów na temat pisania dokumentacji SRS. Oto kilka spostrzeżeń, które sprawią, że Twoja dokumentacja SRS będzie skuteczna:

Uprość to

to nie jest tajemnica, ale proste rzeczy rządzą światem. Z pewnością dotyczy to każdego rodzaju dokumentacji, nad którą pracujesz. Twój SRS to ujednolicony opis przyszłego produktu dla całego zespołu. Oznacza to, że język, struktura i sformułowania dokumentu SRS powinny być jak najbardziej lakoniczne.

Uwzględnij cele biznesowe

chociaż dokument SRS koncentruje się przede wszystkim na cechach technicznych, w tym celach biznesowych jest dobrą praktyką. Dokument SRS jest instrukcją dla zespołu programistów i podsumowaniem produktu dla specjalistów innych niż tech związanych z produktem. Co więcej, uwzględnienie wymagań biznesowych, takich jak wskaźniki i cele, sprawi, że Twoje SRS stanie się jednolitym instrumentem dla całego zespołu.

Dodaj dane użytkownika

etap odkrywania zwykle ujawnia najcenniejsze informacje o użytkowniku. Dodanie tych informacji do dokumentu SRS sprawi, że będzie to pomocny dokument dla zespołu projektowego i programistycznego.

traktuj swój SRS jak żywy dokument

dokument SRS nie powinien być statyczny, nawet jeśli skompilowałeś wszystkie niezbędne pakiety dla swojego projektu. W zwinnych ekosystemach projekty rozwijają się, zyskując nowe funkcje z każdą kolejną iteracją. Wszystkie takie zmiany i modyfikacje powinny być przekazane w dokumencie SRS i uzgodnione z klientem.

wniosek

pisanie dokumentów SRS wymaga głębokich badań, analiz i wysiłku. Jednak kompleksowy dokument SRS, który obejmuje charakterystykę biznesową, szczegóły techniczne i dane użytkownika, opłaci się dzięki oszałamiającemu produktowi, który spełnia oczekiwania zarówno Klienta, jak i użytkowników.

Uptech ma pięć lat doświadczenia w budowaniu produktów dla prężnie rozwijających się startupów. Wiemy, jak zbadać potrzeby użytkownika i sprawić, by dokument SRS był skutecznym narzędziem do zarządzania projektami, a nie stosem Papierów pokrytych pyłem.

F. A. Q.

co to jest SRS?

SRS to dokument zawierający szczegółowy opis specyfikacji technicznych i wymagań aplikacji lub oprogramowania. SRS instruuje również programistów, jak wdrożyć pomysł produktu, aby dopasować go do oczekiwań klienta.

jaki jest cel dokumentu SRS?

celem dokumentu SRS jest podanie opisu technicznego cech produktu, dostarczenie wymagań technicznych i nietechnicznych oraz poprowadzenie zespołu programistów do wdrożenia.

kto pisze dokumenty SRS?

w zależności od składu zespołu, dokumenty SRS są zwykle pisane przez:

• Product Manager;
• Kierownik Projektu;
• Analityk Biznesowy;
• inżynier techniczny.