Temat: Specyfikacja wymagań a Specyfikacja rozwiązania

Czytam sobie syllabus "REQB Ceryfikowany profesjonalista inżynierii wymagań" i zrobił mi się mały mętlik w głowie. Wcześniej miałem przekonanie, że analityk zbiera wymagania, analizuje je i opisuje w dokumencie SRS (Specyfikacja wymagań na oprogramowanie). Potem już projektanci tworzą projekt techniczny. W syllabusie przygotowującym do certyfikatu REQB wprowadzone są pojęcia "Specyfikacja wymagań" i "Specyfikacja rozwiązania". W pierwszym momencie wydawało mi się, że "Specyfikacja rozwiązania" to projekt techniczny ale w dokumencie tym napisane jest:

"Specyfikacje rozwiązania są nazywane również specyfikacjami funkcjonalnymi, specyfikacjami wymagań systemowych lub specyfikacjami wymagań na oprogramowanie. Opisują one obszar rozwiązania. Specyfikacja funkcjonalna jest dokumentem który jasno opisuje wymagania techniczne rozwiązania. Specyfikacja funkcjonalna jest podstawą dalszego wytwarzania systemu, dlatego też musi dostarczać precyzyjnej informacji o wszystkich aspektach funkcjonowania oprogramowania. W oparciu o te dane, architekci i programiści są w stanie efektywnie zaprojektować techniczne aspekty systemu".

Jak to zatem rozumieć ? Czy "Specyfikacja rozwiązania" opisana w syllabusie to właśnie SRS ?
Czym zatem jest "Specyfikacja wymagań" ? Jeśli "Specyfikacja rozwiązania" i SRS to to samo to czy występuje jeszcze jakiś formalny dokument pomiędzy tym dokumentem a projektem technicznym ?

Sprawę dodatkowo komplikuje mi "model V" przedstawiony w tym dokumencie. Według niego mamy take powiązania z testami:

1) "definicja i analiza wymagań" -> "testy akceptacyjne"
2) "projekt funkcjonalny systemu" -> "testy systemowe"
3) "projekt techniczny" -> "testy integracji"
4) "projekt komponentów (modułów)" -> "testy jednostkowe"

czym się różni tutaj "projekt funkcjonalny" od "projektu technicznego" ?
Czy "projekt funkcjonalny" to to samo co "Specyfikacja rozwiązania" ?

Będę wdzięczny za wyjaśnienie powyższych wątpliwości.

Przy okazji chciałbym jeszcze zapytać o jeszcze jedną rzecz. Jak wygląda określanie typów danych w projektach informatycznych ? Wydaje mi się, że taka wiedza powinna wypływać od klienta (przy współudziale informatyka) bo klient będzie wiedział najlepiej jaką długość powinno mieć pole tekstowe. Jeśli informacje o typach danych pojawiają się dopiero w projekcie technicznym to czy projektant rozmawia z klientem w celu ustalenia tych szczegółów ?Krzysztof Sorocki edytował(a) ten post dnia 17.11.12 o godzinie 20:51

Temat: Specyfikacja wymagań a Specyfikacja rozwiązania

Przyznam się, że dla mnie to bełkot firm posiadających patenty na certyfikaty (szkolenia, egzaminy i certyfikaty są objęte prawem autorskim).

Najlepszy moim zdaniem, bo "najprostszy" to model rodem OMG to jest CIP/PIM/PSM

1. wymaganie biznesowe: chcemy poprawić obsługę klientów o 15% (ankiety na klientach)

2. projekt analityczny i zalecane rozwiązanie po analizie biznesowej: nie możemy dalej zapominać i gubić o 1/5 zamówień, wszystkie muszą być realizowane, rozwiązanie jakie może pomóc to oprogramowanie, które pomoże rejestrować zamówienia i nadzorować ich realizację, tak żeby nikt niczego nie zapomniał

3. Wymaganie na oprogramowanie: powinno pozwalać rejestrować zamówienia i śledzić ich status

4. Specyfikacja rozwiązania: model dziedziny systemu czyli logika tego co mają zaimplementować programiści

5. programiści biorą swoja technologię (gotowe framworki itp.) implementuję logikę biznesową ze specyfikacji i mamy oprogramowanie.

testy:
1. czy wynik finansowy faktycznie poprawi się po poprawie jakości? Zapewne tak, w czym problem? Rozwiązanie mamy jako wynik analizy pkt. 2 czego efektem jest wymaganie funkcjonalne 3.

W związku z tym, należy opisać (zaprojektować) logikę działania narzędzia, które jest nam potrzebne pkt. 4.

Jak już to mamy robimy przetarg na wykonanie, zamówieniem jest specyfikacja 4. uzupełniona wymaganiami jakościowymi. pkt. 5.

Koniec

Temat: Specyfikacja wymagań a Specyfikacja rozwiązania

A dokument SRS w którym są opisane wymagania włącznie z przypadkami użycia, diagramami klas, diagramami aktywności to będzie owa "Specyfikacja rozwiązania" ?

Na którym etapie ustalać z użytkownikami typy danych (np. długość zmiennych tekstowych) ? Czy to powinien robić analityk czy dopiero projektant kontaktuje się z użytkownikiem w tym celu ?

A gdzie na Twojej liście jest projekt techniczny ?Krzysztof Sorocki edytował(a) ten post dnia 20.11.12 o godzinie 17:56

Temat: Specyfikacja wymagań a Specyfikacja rozwiązania

Krzysztof Sorocki:
A dokument SRS w którym są opisane wymagania włącznie z przypadkami użycia, diagramami klas, diagramami aktywności to będzie owa "Specyfikacja rozwiązania" ?

Przede wszystkim: definicja SRS? Bo kazdy ma swoją..:(
Tak więc nie wiem co to jest SRS, wiem co to są:
- wymagania funkcjonalne (przypadki użycia)
- wymagania poza-funkcjonalne (ograniczenia, wymagania jakościowe)
- model logiki systemu (model dziedziny systemu)

Na którym etapie ustalać z użytkownikami typy danych (np. długość zmiennych tekstowych) ? Czy to powinien robić analityk czy dopiero projektant kontaktuje się z użytkownikiem w tym celu ?

Przypadki użycia poprawnie zdefiniowane maja stan wejścia i wyjścia, to nic innego jak dane wymagane i otrzymane, zamawiający napisze "składa się z maks. 20 znaków", typ danych to: char, valuetype itp... Typy danych to implementacja a nie wymagania....

A gdzie na Twojej liście jest projekt techniczny ?

a co to takiego?

Temat: Specyfikacja wymagań a Specyfikacja rozwiązania

Jarek Żeliński:

Krzysztof Sorocki:
A dokument SRS w którym są opisane wymagania włącznie z przypadkami użycia, diagramami klas, diagramami aktywności to będzie owa "Specyfikacja rozwiązania" ?

Przede wszystkim: definicja SRS? Bo kazdy ma swoją..:(

Każdemu wolno mieć swoją. Ale nie do końca powinien. Patrz IEEE-830. Jednak jest to znormalizowane, choć oczywiście nieobowiązkowe.

Tak więc nie wiem co to jest SRS, wiem co to są:
- wymagania funkcjonalne (przypadki użycia)

Nie do końca zgadzam się z tą tezą. Wg szkoły, którą praktykuję, przypadki użycia są wymaganiami funkcjonalnymi tylko w szczególnych przypadkach. Przypadek użycia pozostaje w relacji z wymaganiami w relacji jeden-do-wielu. Właściwie to PU ma wiele kroków, a każdy krok może mieć wiele wymagań funkcjonalnych (nawet w relacji wiele-do-wielu, jeśli jest jakieś wymaganie funkcjonalne reużywane przez wiele kroków).

- wymagania poza-funkcjonalne (ograniczenia, wymagania jakościowe)
- model logiki systemu (model dziedziny systemu)

Model dziedziny jest diabelnie ważny, ale nigdy do końca nie rozumiałem, dlaczego Jarek stawia go aż tak strasznie wysoko. Ale nie kwestionuję, skoro nie do końca rozumiem - myślę, że powody muszą być całkiem racjonalne.

Na którym etapie ustalać z użytkownikami typy danych (np. długość zmiennych tekstowych) ? Czy to powinien robić analityk czy dopiero projektant kontaktuje się z użytkownikiem w tym celu ?

Przypadki użycia poprawnie zdefiniowane maja stan wejścia i wyjścia, to nic innego jak dane wymagane i otrzymane, zamawiający napisze "składa się z maks. 20 znaków", typ danych to: char, valuetype itp... Typy danych to implementacja a nie wymagania....

Info o tym, co będzie przechowywane i czym się cechuje - na etapie wymagań. Ale typ pola jest platform-related i to bardzo. Tak jak Jarek napisał - typ danych to implementacja. Nie napiszesz w specyfikacji wymagań "Pole Nazwisko - typ Varchar(50)Bytes", bo to się sprawdzi na Oracle'u, a w innym silniku niekoniecznie - pani Krysia (szef działu kadr) ma w poważaniu, jaki będzie to typ pola. Jej się maja mieścić wszystkie nazwiska i koniec. Nie mówiąc o tym, ze może w ogóle nie rozumieć takich rzeczy i opóźnić przez to sign-off.
Ja bym w każdym razie nie ryzykował.

REQB sie troche gubi w zeznaniach. Jak robiłem ten certyfikat w zeszłym roku to miałem niejasne wrażenie, że ten zbiór reguł jest nie do końca spójny logicznie i miałem ochotę trochę ich popytać. "Ich", czyli Niemców z Bambergu. Ale na ochocie się skończyło. Praca, rodzina, kapela - jakoś mało czasu na działalność społeczną zostaje :)
Jak Cię interesuje, Krzysztof, co to konkretnie było, to mogę pogrzebać w notatkach.

Temat: Specyfikacja wymagań a Specyfikacja rozwiązania

Patrz IEEE-830. Jednak jest to znormalizowane, choć oczywiście nieobowiązkowe.

nie wiele tu jest, opisałem to tu:
http://it-consulting.pl/autoinstalator/wordpress/2008/...

mamy tylko tyle, że wymagania mają być fajne, nie ma tam definicji wymagania...

Tak więc nie wiem co to jest SRS, wiem co to są:
- wymagania funkcjonalne (przypadki użycia)

Nie do końca zgadzam się z tą tezą. Wg szkoły, którą praktykuję, przypadki użycia są wymaganiami funkcjonalnymi tylko w szczególnych przypadkach.

w jakich nie są?

- model logiki systemu (model dziedziny systemu)

Model dziedziny jest diabelnie ważny, ale nigdy do końca nie rozumiałem, dlaczego Jarek stawia go aż tak strasznie wysoko. Ale nie kwestionuję, skoro nie do końca rozumiem - myślę, że powody muszą być całkiem racjonalne.

Bo to jedyne miejsce gdzie mamy opisaną logikę systemu (tego co i jak ma system przetwarzać). Nie da się z pomocą PU lub "wymagań funkcjonalnych" opisać np. tego jak należy zdjąć z magazynu towar zachowując kolejność terminów przydatności do spożycia i jednocześnie największej marży, to "algorytmy" czyli nic innego jak "metody operacji klas dziedzinowych". Owszem, można te "algorytmy" spisać "na boku" co nie zmienia faktu, że i tak trzeba je jakoś kontekstowo pokojarzyć. Czynie tu pewne dodatkowe założenie: środowisko obiektowe implementacji.

Przypadki użycia poprawnie zdefiniowane maja stan wejścia i wyjścia, to nic innego jak dane wymagane i otrzymane, zamawiający napisze "składa się z maks. 20 znaków", typ danych to: char, valuetype itp... Typy danych to implementacja a nie wymagania....

Info o tym, co będzie przechowywane i czym się cechuje - na etapie wymagań. Ale typ pola jest platform-related i to bardzo.

proste typy danych tak do momentu gdy nie nabiera znaczenia to, że adres może być typem (value object) albo zlepkiem pół tekstowych.

REQB sie troche gubi w zeznaniach. Jak robiłem ten certyfikat w zeszłym roku to miałem niejasne wrażenie, że ten zbiór reguł jest nie do końca spójny logicznie i miałem ochotę trochę ich popytać.

studiując literaturę o wymaganiach mam podobne wrażenie, w zasadzie trudno napisać "co ma powstać" nie robiąc projektu tego czegoś na jakimś poziomie ogólności/szczegółowości, niestety nabieram coraz większego przekonania, że same PU niczego nie definiują. bez projektu niczego nie zakodujemy...
http://it-consulting.pl/autoinstalator/wordpress/2012/...

coraz bardziej przekonuje się, że samo "zarządzanie wymaganiami" bez ścisłych definicji wymagań i "mapowania" ich to co ma powstać 9w kodzie, architekturze itp.) to bicie i utwardzanie tej samej piany ...

Temat: Specyfikacja wymagań a Specyfikacja rozwiązania

Jarek Żeliński:

Tak więc nie wiem co to jest SRS, wiem co to są:
- wymagania funkcjonalne (przypadki użycia)

Nie do końca zgadzam się z tą tezą. Wg szkoły, którą praktykuję, przypadki użycia są wymaganiami funkcjonalnymi tylko w szczególnych przypadkach.

w jakich nie są?

Inaczej - trochę nieprecyzyjnie się wyraziłem. Idąc za Robertsonami użyłbym tu anglojęzycznego określenia, że są one "composite requirements"-ami. To znaczy nie są to atomowe wymagania funkcjonalne, którym można przyznać atomowe kryteria akceptacji, a "zespoły" wymagań. Brak analizy PU na kawałki i szukania "czynników pierwszych" niesie ryzyko przeoczenia.
Tyle że nie każdy PU jest wymaganiem złożonym, a nie każde WZ jest przypadkiem użycia.

Brakowało przydawki "atomowymi" lub "niepodzielnymi".

Temat: Specyfikacja wymagań a Specyfikacja rozwiązania

Bartosz Andrzejewski:

Jarek Żeliński:

Tak więc nie wiem co to jest SRS, wiem co to są:
- wymagania funkcjonalne (przypadki użycia)

Nie do końca zgadzam się z tą tezą. Wg szkoły, którą praktykuję, przypadki użycia są wymaganiami funkcjonalnymi tylko w szczególnych przypadkach.

w jakich nie są?

Inaczej - trochę nieprecyzyjnie się wyraziłem. Idąc za Robertsonami użyłbym tu anglojęzycznego określenia, że są one "composite requirements"-ami. To znaczy nie są to atomowe wymagania funkcjonalne, którym można przyznać atomowe kryteria akceptacji, a "zespoły" wymagań.

to moim zdaniem kwestia definicji przypadku użycia, ja bazuje "po bożemu" na tej ze specyfikacji UML:

"Use cases are a means for specifying required usages of a system. Typically, they are used to capture the requirements of a system, that is, what a system is supposed to do." (źr. OMG Unified Modeling LanguageTM (OMG UML), Superstructure Version 2.4.1)

wiele szkoleń i książęk "z wymagań" udziwnia to tworząc chaos definicyjny ...

Brak analizy PU na kawałki i szukania "czynników pierwszych" niesie ryzyko przeoczenia.
Tyle że nie każdy PU jest wymaganiem złożonym, a nie każde WZ jest przypadkiem użycia.

wg. przytoczonej definicji UML
PU=wymaganie funkcjonalne
a ograniczenie skojarzone z PU to wymaganie poza funkcjonalne (jakościowe, jak kto woli)Jarek Żeliński edytował(a) ten post dnia 30.11.12 o godzinie 20:58