26maj/103
Jaki powinien być Twój SRS?
Twój SRS powinien być (*):
- Poprawny
- Jednoznaczny
- Kompletny
- Spójny
- Uporządkowany według ważności i/lub stabilności wymagań
- Weryfikowalny
- Modyfikowalny
- Łatwy do śledzenia (ang. traceable) [zna ktoś może lepsze tłumaczenie?]
Czy możesz szczerze powiedzieć, że Twój ostatni SRS miał wszystkie powyższe cechy?
(*) Na podstawie standardu IEEE 830-1998.
Maj 27th, 2010 - 07:56
Znam tę listę i uważam, że to lista „ogólników”, bo jak to sprawdzić? Wszystkie te cechy specyfikacji są deklaratywne więc w zasadzie „każda” spełnia te wymagania. Po drugie specyfikacja „spełniająca” powyższe wymagania może opisywać coś co nie jest potrzebne – słynne chyba już „to jest dokładnie to co chcieliśmy ale nie to czego potrzebujemy”… Dla mnie ta norma to nieprzydatny bełkot. Miernikiem jakości SRS jest w moim mniemaniu:
- ocena programistów, którzy na jej podstawie tworzą oprogramowanie
- ocena użytkownika, że mu ono (to oprogramowanie) pomogło.
Osobiście „obstawiam” na metody polegające na specyfikowaniu wymagań polegajace na pierwotnym szczególowym opisaniu biznesowego celu projektu (perspektywa zamawiajacego czyli przyszlego użytkownika) oraz zaprojektowaniu oprogramowania wspierającego realizację tych celów.
Pierwsze to model biznesowy (np. modele procesowe) a drugie to model w postaci specyfikacji oprogramowania (np. metodami obiektowymi). Dokłądnei jak budowa wieżowca: najpier analiza do czego posłuży, potem projekt architektoniczny i szczególy instalacji a potem wykonawca, ktory z tych rysunków zrobi to co miało powstać.
Maj 27th, 2010 - 11:50
Dzięki Jarek za ciekawy komentarz!
Część punktów z tej listy można sprawdzić np. za pomocą przeglądów, spotkań z klientem, etc. Część natomiast można zapewnić stosując odpowiednie wzorce dokumentów oraz dobre praktyki specyfikowania wymagań. Wydaje mi się, że dobrze jest po prostu co jakiś czas zapytać samego siebie np.: „W jaki sposób mógłbym zweryfikować wymaganie ABC?”, „Czy wymaganie ABC jest wystarczająco jednoznaczne?”, „Czy to nowe wymagania jest spójne z resztą?”, itp.
Ocena programistów? Jak najbardziej! Można przecież zrobić przegląd właśnie przez programistów. Tylko wcześniej trzeba też odpowiednio wyedukować programistów, na co powinni zwracać uwagę.
Ocena użytkownika, czy oprogramowanie mu pomogło? Czy to nie jest już za późno? Użytkownik będzie w stanie stwierdzić to po wdrożeniu systemu (lub chociaż jego części) oraz jakimś czasie użytkowania, a wtedy już może być za późno na zmiany w wymaganiach.
Całkowicie się z Tobą zgadzam, jeśli chodzi o sam proces zbierania wymagań, czyli najpierw procesy biznesowe, które pomogą nam zrozumieć specyfikę działania klienta oraz problemy, które chcemy rozwiązać, a dopiero później przechodzimy na niższy poziom wymagań, w którym omawiamy oprogramowanie i rozwiązania problemów. Zresztą na mojej liście spraw do zrobienia na blogu jest właśnie pozycja dotycząca procesu oraz samego modelowania procesów biznesowych.
Czerwiec 22nd, 2010 - 11:37
traceable wg translate.goole.com to sprawdzalny.
W sumie niegłupie tłumaczenie.
W końcu po to nam powiązanie wymagania z np. celem biznesowym albo z kawałkiem projektu technicznego by móc sprawdzić czy wszystko jest OK.
Z innej strony.
Traceable pojawia się zazwyczaj w zdaniu: sth is traceable to sth, np. requirement is traceable to high-level requirement.
Po polsku mogłoby być: coś jest powiązane z czymś.
Być może tłumaczeniem traceable powinno być „powiązane”, czyli „SRS powinien być powiązany”. A po to by nie było SRSów-zombie