#etykieta produktu
Specyfikacja wymagań oprogramowania (SRS document) opisuje, w jaki sposób należy opracować system oprogramowania. Mówiąc najprościej, SRS zapewnia wszystkim zaangażowanym mapę drogową dla tego projektu.
oferuje wysokiej jakości definicje funkcjonalnych i niefunkcjonalnych specyfikacji oprogramowania, a także może zawierać przypadki użycia, które ilustrują, w jaki sposób użytkownik wchodzi w interakcję z systemem po zakończeniu.,
Uwaga: pomożemy Ci napisać specyfikację wymagań oprogramowania. Poproś o połączenie z naszym CTO, wypełniając ten formularz.
spis treści
dlaczego dokument SRS jest ważny?
Załóżmy, że chcesz utworzyć aplikację do czatu o określonym wyglądzie i funkcjonalności i chciałbyś, aby była skierowana specjalnie do przedsiębiorstw. Uważasz, że możesz wyciąć dodatkowe funkcje, których komercyjne aplikacje czatu używają do odwołania się do opinii publicznej i skupić się na funkcjach, których potrzebują przedsiębiorstwa. Ale nie jesteś deweloperem.,
więc musisz zlecić rozwój aplikacji na zewnątrz. Ale musisz również upewnić się, że ktokolwiek zatrudnisz, aby przekształcić swój pomysł w rzeczywistość, wie dokładnie, co próbujesz osiągnąć. Bez wszystkich szczegółów, aby zakończyć aplikację, czas i koszty mogą szybko wymknąć się spod kontroli. Programiści mogą źle skręcić i muszą refaktorować Kod, jeśli gotowy produkt nie pasuje do obrazu, który miałeś w głowie.
dokument SRS zmusza cię do złożenia pomysłu na papier, aby pokryć wszystkie te szczegóły. Musisz przetłumaczyć ten pomysł na język, który rozumieją Programiści., Dokument SRS opisuje, czego chce klient i co zapewni deweloperzy. Jest to pisemna umowa na każdy szczegół aplikacji.
posiadanie jasnego zestawu wymagań gwarantuje, że zespół programistów tworzy oprogramowanie spełniające potrzeby klientów. SRS pomoże w oszacowaniu kosztów pracy i pokryciu zakresu projektu. Daje również programistom wyobrażenie o stosie technologii, którego będą potrzebować i pomaga im zaplanować pracę, ale to nie wszystko:
- projektanci uzyskują wgląd w projekt za pośrednictwem dokumentów SRS, dzięki czemu mogą dopasować projekt do przypadku użycia.,
- testerzy otrzymują wytyczne do tworzenia przypadków testowych, które odpowiadają potrzebom firmy.
- użytkownicy końcowi używają SRS do zrozumienia oprogramowania.
- zapewnia inwestorom Przegląd funkcji systemu, dzięki czemu mogą podejmować decyzje inwestycyjne.
SRS jest ważny, ponieważ jest jednym źródłem informacji i oczekiwań, co zapobiega nieporozumieniom między kierownikami projektów, programistami, projektantami i testerami.
co obejmuje SRS?,
SRS powinien mieć wystarczającą ilość informacji dla programistów, aby ukończyć opisane oprogramowanie. Nie tylko określa opis rozwijanego oprogramowania, ale także cel, któremu będzie ono służyć: co oprogramowanie ma robić i jak powinno działać.,
różnica między wymaganiami funkcjonalnymi i niefunkcjonalnymi
wymagania funkcjonalne są celami nowego systemu, który projektujesz., Opisują system i sposób jego działania, aby pomóc w realizacji zadań użytkownika. Definiują one, w jaki sposób system będzie reagował na wprowadzanie danych przez użytkownika i zawierają szczegółowe informacje na temat obliczeń, wprowadzania danych i procesów biznesowych. Możesz rozważyć wymagania funkcjonalne szczegółowy opis funkcji aplikacji i potrzeb użytkownika. Bez spełnienia wymagań funkcjonalnych system nie będzie działał.
podczas gdy wymagania funkcjonalne określają, co robi system, wymagania niefunkcjonalne opisują, jak system to zrobi. Wymagania niefunkcjonalne nie wpływają na funkcjonalność aplikacji., Nawet bez spełnienia wymagań niefunkcjonalnych, system wykona pożądane zadania.
wymagania niefunkcjonalne są również ważne, ponieważ określają ogólne cechy, które wpływają na wrażenia użytkownika. Zamiast skupiać się na wymaganiach użytkowników, skupiają się na oczekiwaniach użytkowników i obejmują takie tematy, jak wydajność, bezpieczeństwo, niezawodność, dostępność i użyteczność.,
Jak napisać dokument specyfikacji wymagań oprogramowania
najlepiej jest zorganizować proces, którego używasz do napisania dokumentu SRS, zaczynając od szkieletu i ogólnych informacji na temat rozwijanego oprogramowania, a kończąc na dodaniu szczegółów do projektu. Oto sześć kroków związanych z tworzeniem dokumentu SRS:
Pobierz dokument specyfikacji wymagań oprogramowania
pomogliśmy ponad 200 firmom zbudować ich oprogramowanie. Wynajmij naszego analityka biznesowego z 6-letnim doświadczeniem, aby napisał dla Ciebie SRS.,
poproś SRS
Utwórz Kontur
pierwszym krokiem w procesie jest utworzenie konturu dla Twojego SRS. Możesz go utworzyć samodzielnie lub użyć istniejącego szablonu SRS jako punktu wyjścia. Oto podstawowy przykład zarysu SRS:
pobierz ebook
- wprowadzenie
- cel
- przeznaczenie
- zakres
- definicje
- ogólny opis
- potrzeby użytkownika
- założenia i zależności
- funkcje i wymagania systemu
- wymagania funkcjonalne
- wymagania interfejsu zewnętrznego
- funkcje systemu
- wymagania niefunkcjonalne
zdefiniuj cel
gdy masz zarys, musisz go dopasować., Zacznij od zdefiniowania celu produktu na wstępie swojego SRS. Tutaj opiszesz docelową grupę odbiorców i sposób, w jaki będą oni korzystać z produktu. Oto jak powinieneś ustrukturyzować przeznaczenie:
- określ zakres produktu
- opisz wartość, którą dostarczy
- pokaż, kto będzie używał oprogramowania
- szczegółowo, jak to pomoże w zadaniu docelowego użytkownika
daj przegląd
Po zdefiniowaniu przeznaczenia produktu, podsumuj, jak będzie on działał., Tutaj podasz ogólny opis funkcji oprogramowania i ich dopasowania do potrzeb użytkownika.
opiszesz również założenia, jakie stawiasz na funkcjonalność produktu i wszystko, od czego zależy on w obecnym ekosystemie technologicznym.
opisz wymagania funkcjonalne i niefunkcjonalne
teraz, gdy napisałeś ogólne informacje, nadszedł czas, aby uzyskać bardziej szczegółowe. Uzupełnienie przeglądu przed rozpoczęciem pracy nad funkcjonalnymi i niefunkcjonalnymi wymaganiami daje odniesienie, aby upewnić się, że spełniasz podstawowe potrzeby użytkownika podczas wypełniania szczegółów.,
ten szczegółowy opis wymagań systemu jest najważniejszym elementem dokumentu SRS. Opisz wymagania funkcjonalne wystarczająco szczegółowo, aby programiści mogli przystąpić do pracy oraz wymagania niefunkcjonalne, takie jak specyfikacje zabezpieczeń i wydajność.
tutaj dodajesz przypadki użycia, aby obrazowo opisać, w jaki sposób użytkownik będzie współdziałał z Twoim systemem. To tam, gdzie cele projektu są szczegółowe i będzie mierzyć, jak projekt postępuje podczas rozwoju.,
Dodaj dodatkowe szczegóły
ostatnim krokiem w tworzeniu projektu dokumentu SRS jest dodanie wszelkich szczegółów, które mogłyby pomóc programistom zakończyć pracę w postaci załączników, glosariuszy terminów i odniesień.
uzyskaj zatwierdzenie
Po dodaniu wystarczającej liczby szczegółów do SRS, aby opisać, co system ma zrobić, nadszedł czas, aby interesariusze zatwierdzili dokument.
najprawdopodobniej będziesz musiał zrobić prezentację osobom zaangażowanym w proces rozwoju., Mogą poprosić o zmiany, a przed ostatecznym zatwierdzeniem będziesz musiał zaktualizować dokument SRS na podstawie opinii zainteresowanych stron.
to dobry znak. Oznacza to, że zarówno Programiści, jak i interesariusze sprawiają, że dokument jest bardziej precyzyjny, więc projekt nie idzie w złym kierunku.
jak pisać przypadki użycia Oprogramowania w SRS
przypadek użycia opisuje, w jaki sposób użytkownik będzie współdziałał z systemem. Będzie opisywać produkt z punktu widzenia użytkownika końcowego w prostym formacie opowieści. Spisywanie przypadków użycia zmusza cię do zastanowienia się, co użytkownicy zrobią z oprogramowaniem i jak zareaguje., Jest to prawdziwa wizualizacja wymagań funkcjonalnych.
oto kroki, które możesz wykonać, aby napisać przypadek użycia:
- opisz użytkowników końcowych swojego produktu.
- skup się na jednym z tych użytkowników.
- podziel interakcje tego użytkownika na przypadki użycia. Każda interakcja jest przypadkiem użycia.
- opisz sekwencję zdarzeń dla każdego przypadku użycia.
- napisz szczegółowy opis działań użytkownika i sposobu reakcji systemu.
- rozwiń każdy przypadek użycia za pomocą alternatywnych działań użytkownika i odpowiedzi systemowych.
- powtórz 1-6 dla każdego typu użytkownika końcowego.,
jakie są cechy wielkiego SRS?
istnieją specyficzne cechy, które każdy SRS powinien mieć. Przeglądając tę listę i porównując ją ze swoimi SRS, możesz mieć pewność, że będzie to przydatny dokument dla wszystkich zainteresowanych stron.
dokument SRS powinien być łatwy do zrozumienia. Nic nie powinno być niejasne, więc nie ma nieporozumień między zainteresowanymi stronami.,
mierzalne
wymagania w dokumencie SRS muszą być mierzalne, aby gotowy produkt mógł zostać zweryfikowany i zweryfikowany zgodnie ze specyfikacjami.
Complete
dokument SRS powinien zawierać wystarczającą ilość informacji dla zespołu programistów, aby ukończyć produkt i dla testerów, aby potwierdzić, że produkt spełnia potrzeby użytkownika bez błędów.
wymagania powinny pasować do realiów obecnego środowiska, w tym budżetu, harmonogramu i technologii. Nie powinny zależeć od nadchodzących przełomów technologicznych.,
Elastyczny
ponieważ w środowisku pracy może się coś zmienić, twój dokument SRS powinien być wystarczająco elastyczny, aby umożliwić aktualizacje. Nie dodawaj zbędnych informacji do wielu sekcji, które muszą być aktualizowane przy każdej zmianie.
weryfikowalne
każdy w zespole programistów powinien mieć dostęp do dokumentu, aby mógł się do niego odwoływać tak często, jak to konieczne. Wymagania muszą być precyzyjne, aby członkowie zespołu nie musieli prosić o więcej szczegółów. Wszystkie powinny być dostępne w dokumencie SRS.,
spójne
wymagania powinny pasować do siebie. Jedna sekcja dokumentu wymagań nie powinna kolidować z inną. Dokument powinien być sformatowany konsekwentnie i stosować tę samą terminologię w całym tekście.
Brak ograniczeń implementacji
dokument SRS powinien być wystarczająco szczegółowy, aby zakończyć pracę, ale nie powinien być zbyt szczegółowy, ponieważ może to ograniczyć rozwój. Wiele rozwoju zależy od usług innych firm, nad którymi programiści nie mają kontroli.,
dokładne
cele w dokumencie wymagań powinny być precyzyjne, aby uniknąć nieporozumień. Unikaj następujących luk:
- : „aplikacja powinna załadować się w ciągu 3 sekund, jeśli można to zrobić.”
- ” produkt MVP powinien zostać wydany jak najszybciej.”
- subiektywność: „interfejs użytkownika powinien być przyjazny dla użytkownika.”
- superlatywy: „to powinna być najlepsza aplikacja w swojej klasie.”
- Comparative: „Ta aplikacja powinna być lepsza niż Slack.,”
A Software Requirement Specification (SRS) Example
oto skrócony przykład dokumentu SRS dla aplikacji do czatu dla przedsiębiorstw o nazwie eChat:
wprowadzenie
ten dokument zawiera szczegóły planu projektu rozwoju ” eChat.”
jest przeznaczony dla programistów, projektantów i testerów pracujących nad” eChat”, a także inwestorów projektowych., Plan ten będzie zawierał podsumowanie:
- jak system będzie działał
- zakres projektu z punktu widzenia rozwoju
- technologia użyta do opracowania projektu i
- metryki używane do określenia postępu projektu
- ogólny opis
firmy potrzebują narzędzi do komunikacji zdalnej, zwłaszcza teraz, gdy więcej osób pracuje w domu. Problem polega na tym, że większość firm korzysta z wielu aplikacji, aby to osiągnąć: jedna do czatu tekstowego, jedna do czatu wideo i jedna do konferencji i spotkań., „eChat” rozwiąże ten problem, łącząc te funkcje w jednej aplikacji.
pobierz białą księgę
Klienci
klienci będą korporacyjni firmy. Nie będzie skierowany do ogółu społeczeństwa.
funkcjonalność
- użytkownicy powinni mieć możliwość rejestracji za pomocą korporacyjnych kont LDAP.,
- użytkownicy powinni mieć możliwość tworzenia grup czatów ad hoc składających się z zestawów użytkowników i wysyłania prywatnych wiadomości do poszczególnych użytkowników.
- użytkownicy powinni mieć możliwość prowadzenia czatów tekstowych, które mogą dzielić na wątki.
- aplikacja powinna być w stanie obsługiwać grupowy czat wideo do 100 użytkowników na raz.
Platforma
aplikacja zostanie opracowana w React Native, aby umożliwić tworzenie aplikacji internetowej, aplikacji mobilnej na iOS i aplikacji mobilnej na Androida.
te aplikacje będą łączyć się z zbudowanym przez REST API .,Net Core do przechowywania i pobierania danych z bazy danych MySQL.
uwierzytelnianie odbywa się poprzez istniejące instalacje LDAP.
obowiązki programistyczne
programiści z zespołu „eChat” będą odpowiedzialni za napisanie całego kodu aplikacji, rozwój bazy danych i zarządzanie wydaniami.,
klasa i cechy użytkownika
pojawi się Klasa użytkowników o nazwie admin, która będzie miała uprawnienia do dostępu do wszystkich funkcji aplikacji, w tym:
- tworzenie kanałów, w których wielu użytkowników może wchodzić w interakcje
- udostępnianie tych kanałów całej firmie lub prywatne dla grupy osób
- usuwanie tych kanałów
- archiwizowanie tych kanałów
użytkownicy standardowi będą mieli dostęp do wszystkich funkcji aplikacji z wyjątkiem wymienione powyżej.,
funkcje systemu
wymagania funkcjonalne
- użytkownicy powinni mieć możliwość tworzenia grup czatów ad hoc składających się z zestawów użytkowników i wysyłania prywatnych wiadomości do innych użytkowników.
- użytkownicy powinni mieć możliwość prowadzenia czatów tekstowych, które mogą dzielić na wątki.
- Czaty powinny być archiwizowane w nieskończoność, aby użytkownicy mogli odwoływać się do poprzednich czatów.
- użytkownicy powinni mieć możliwość przesyłania plików do czatów w celach informacyjnych.
- wymagania interfejsu zewnętrznego
interfejsy użytkownika
- oprogramowanie Front-end: React Native
- oprogramowanie Back-end: .,
- iPhone
- Android
- wymagania niefunkcjonalne
wymagania wydajnościowe
- aplikacja powinna załadować się i być użyteczna w ciągu 3 sekund
- aplikacja powinna zaktualizować interfejs na interakcji w ciągu 2 sekund
- baza danych powinna być znormalizowana, aby zapobiec nadmiarowym danym i poprawić wydajność
- baza danych powinna być dystrybuowana, aby zapobiec przestojom
- li>
wymagania bezpieczeństwa
- bazy danych powinny wykorzystywać sharding jako zbędne, aby zapobiec utracie danych.,
- kopie zapasowe baz danych powinny być wykonywane co godzinę i być przechowywane przez jeden tydzień.
wymagania bezpieczeństwa
- wszelkie klucze używane dla REST API powinny być bezpiecznie przechowywane.
- tylko REST API powinno być w stanie połączyć się z bazami danych.
- bazy danych powinny znajdować się za firewallem.
atrybuty jakości oprogramowania
- dostępność: ponieważ ta aplikacja ma kluczowe znaczenie dla komunikacji biznesowej, naszym celem będzie dostępność czterech dziewiątek (99,99%).,
- poprawność: aplikacja nigdy nie powinna pozwalać nikomu na czytanie wiadomości lub dyskusji nie przeznaczonych dla tej osoby.
- Konserwacja: aplikacja powinna korzystać z ciągłej integracji, aby funkcje i poprawki błędów mogły być wdrożone szybko bez przestojów.
- użyteczność: interfejs powinien być łatwy do nauczenia się bez samouczka i umożliwiać użytkownikom osiąganie celów bez błędów.
podsumowanie
dokument SRS jest niezbędną częścią realizacji projektu programistycznego., Jest to mapa drogowa, która nadaje kierunek wszystkim zaangażowanym w projekt, dzięki czemu końcowy produkt spełnia potrzeby użytkownika.
bez kompletnego dokumentu SRS w miejscu przed rozpoczęciem projektu, trudno będzie stwierdzić, kiedy projekt jest gotowy i może sidetrack rozwoju do tworzenia niezamierzonych funkcji. Dokument SRS daje możliwość dokładnego oszacowania projektu i efektywnego przypisywania zadań.
Tworzenie dokumentu SRS może być czasochłonnym i skrupulatnym procesem., Na szczęście zespół w Relevant pomógł ponad 200 firmom stworzyć dokumenty SRS i wprowadzić na rynek nowe produkty. Jesteśmy gotowi pomóc w kolejnym projekcie oprogramowania, po prostu napisz do nas.