VulCode

Specyfikacja wymagań

Wymagania jako historie użytkownika, wymagania niefunkcjonalne i kryteria odbioru.

Specyfikacja wymagań: Rezerwacje sal
Cel
  1. Klienci rezerwują salę online, a recepcja nie prowadzi już kalendarza w zeszycie.
Role
  1. •Klient
  2. •Recepcja
  3. •Administrator
Wymagania funkcjonalne
  1. 1.Jako Klient chcę zarezerwować salę na wybrany termin, aby nie dzwonić w godzinach pracy recepcji.
  2. 2.Jako Recepcja chcę widzieć rezerwacje dnia na jednej liście, aby przygotować sale.
  3. 3.Jako Administrator chcę blokować terminy przerw technicznych, aby nikt ich nie zarezerwował.
Wymagania niefunkcjonalne
  1. •Bezpieczeństwo: role, logowanie, kopie zapasowe: do uzupełnienia
  2. •Dostępność: WCAG 2.1 na poziomie AA: do uzupełnienia
  3. •RODO: dane osobowe i ich przechowywanie: do uzupełnienia
Integracje
  1. •Kalendarz Google recepcji (do sprawdzenia uprawnień)
Kryteria odbioru
  1. •Rezerwacja na zajęty termin jest niemożliwa
  2. i 1 kolejny punkt
Dalej w dokumencie: Poza zakresem.

Wypełnij i pobierz

Dokument zmienia się na bieżąco, gdy wypełniasz 8 pól. Wszystko dzieje się w Twojej przeglądarce, nic nie wysyłamy.

Projekt
Wymagania funkcjonalne
Pozostałe wymagania
Wymagania niefunkcjonalne do opisania
specyfikacja-wymagan.md
Specyfikacja wymagań: do uzupełnienia

Cel

do uzupełnienia

Role

  • do uzupełnienia

Wymagania funkcjonalne

  1. do uzupełnienia

Wymagania niefunkcjonalne

  • do uzupełnienia

Integracje

  • do uzupełnienia

Kryteria odbioru

  • do uzupełnienia

Poza zakresem

  • do uzupełnienia

Kiedy użyć specyfikacji

Specyfikacja szczegółowo opisuje funkcje, ekrany, reguły i kryteria odbioru. Pisze ją zwykle wykonawca albo analityk, razem z zamawiającym.

Jeśli chcesz stałej ceny za projekt,

to stała cena jest możliwa, gdy umiesz opisać, co ma działać i jak to sprawdzisz. Jeśli opis kończy się na hasłach, najpierw potrzebne jest rozpoznanie.

Jeśli funkcje opisujesz hasłami, na przykład "panel administracyjny",

to zapisz je jako historie użytkownika: kto, co chce zrobić i po co. Hasło każdy wykonawca wyceni inaczej.

Jeśli nie masz doświadczenia technicznego,

to nie opisuj tabel w bazie danych ani kolorów przycisków. Specyfikacja powstaje z briefu, często w płatnym etapie analizy. Brief aplikacji

Jeśli zależy Ci na jakości przy odbiorze,

to wpisz kryteria odbioru. Stała cena chroni budżet, ale nie jakość. Jakość chronią kryteria odbioru i wgląd w kod w trakcie.

Co dalej: od briefu do odbioru

Po każdym kroku zostaje dokument, na którym opiera się następny.

Brief projektu

Brief

Zamawiający opisuje problem, cel, użytkowników, priorytety i ograniczenia.

Specyfikacja wymagań
Brief projektu

Analiza

Specyfikacja powstaje z briefu, często w płatnym etapie analizy, razem z wykonawcą albo analitykiem.

Oferta według specyfikacji
Specyfikacja wymagań
Brief projektu

Wycena

Opis tego, co ma działać i jak to sprawdzić, pozwala na stałą cenę za dobrze opisany etap.

Odbiór według kryteriów
Oferta według specyfikacji
Specyfikacja wymagań
Brief projektu

Odbiór

Kryteria odbioru mówią, kiedy funkcja jest gotowa, i chronią jakość.

Pytania

Najpierw o tym, co dzieje się z wpisanymi danymi, potem o samym dokumencie.

Masz gotowy dokument?

Wyślij go nam razem z pytaniem. Odpiszemy w godzinę z wyceną.