Specyfikacja, inaczej zwana SRS. Każda firma ma swój szablon. Każda firma stara się to usystematyzować i każda firma chce aby specyfikacja służyła do zareklamowania funkcjonalności.
Jest to błąd. Specyfikacja w największym skrócie powinna opisywać to czego dana funkcjonalność nie może robić i jakie są jej ograniczenia. Najlepiej jest ją pisać w sceptycznym języku.
Zapobiega to temu że interesariusz będzie miał inne wyobrażenie o tym co zostanie zaimplementowane i co będzie dana rzecz robić bo każdy z nas wpada w pułapkę myślenia że skoro dana
Funkcjonalność umie wykonywać rzecz X i Y to i umie Z. Jednak często jest tak że jednak ona tego nie umie i mamy zonk i nieprzyjemne sytuacje.
Dobra jak już opisaliśmy że specyfikacja nie służy reklamowaniu funkcjonalności to możemy przejść do tego co każda specyfikacja powinna zawierać. Pisząc te zdanie wpadła do mnie koncepcja tego
Że wypiszę to w podpunktach. Będzie ładnie i konkretnie i zwięźle. Bo jak chciałem opisać jedną rzecz dotyczącą tego że nie używamy do reklamowania to poświęciłem temu 4 linijki…
DO BRZEGU. SPECYFIKACJA POWINNA ZAWIERAĆ:
Wstęp biznesowy. Wprowadzenie do wymagań. Cel biznesowy. Inne itd. Opis procesu(słynne bpmn) itd.
Często pomijana część wymagań. Traktujemy programistów jak robotów i nie opisujemy o co w tym chodzi i po co i jak i dlaczego. Dlatego bardzo ważne jest to żeby każda specyfikacja zawierała w sobie cel
Biznesowy. Kontekst. Zakres projektu. Lista interesariuszy, ich analiza, modele dziedziny i inne które nie przychodzą mi teraz do głowy.
Model funkcjonalny
Opis co robi rozwiązanie. Przykładowo diagram przypadków użycia. Dekompozycję funkcjonalną. Diagram wymagań i ich powiązań. I inne które nie przychodzą mi do głowy.
Dane i ich modele
Modele danych. Jakie dane potrzebujemy. Skąd i powiązania miedzy nimi. Tutaj można zastosować diagramy klas. Diagramy związków encji czy zwyczajne tabele z opisem danych.
Opisy wymagań
Czyli typowe tabelki wymagań z opisami. Tak to są te tabelki które wypełniają wszyscy a całą resztę olewają. Nazwa takich tabelek to przeważnie WB1234. Właściciel tych wymagań to jedna i ta sama osoba i każde z nich ma
Priorytet krytyczny 😉
Słownik pojęć.
Bardzo często ratuje on wymagania. Słowniki dają bardzo dużo. Mamy dyrektorów X i dyrektorów Y. Nazywają się tak samo czyli Dyrektor. Bez słownika byśmy ich nie rozróżnili. Dzięki słownikom mamy to jasno opisane.
Nie będę tu wspominać o skrótach używanych w różnych organizacjach bo jest ich tak dużo że bez słownika byśmy nic nie zrozumieli 😉
No i tyle. Mało i dużo jednocześnie. Można w tych 5 punktach zrobić kilkusetstronne specyfikacje.
