Krótka odpowiedź : 830-1998 nie jest standardem, jest zalecaną najlepszą praktyką pisania SRS w stylu z 1998 roku.
Nie mogę znaleźć sposobu, w jaki został on zastąpiony (nawet przy zaawansowanym wyszukiwaniu IEEE :()
Myślę jednak, że dzieje się tak, ponieważ cała metoda określania wymagań zmieniła się drastycznie w ostatnich latach.
Odtąd próbuję odpowiedzieć na nieco zmodyfikowane pytanie:
Jaka jest najlepsza praktyka w branży / Jakie są zalecane najlepsze praktyki dotyczące pisania SRS w stylu z 2012 roku?
O klasycznych metodach:
Zwykle używam zaleceń IEEE 1471 do dokumentacji oprogramowania, chociaż ostatnio została ona również zastąpiona przez ISO / IEC 42010. Jest to bardzo złożony rodzaj dokumentacji, jest głównie używany do przekazywania, chociaż głównie zawiera wymagania (rozdział 7 w nowy dokument w stylu ISO)
Dość dobrą książką na temat dokumentacji formalnej jest Documenting Software Architectures , zaskakująco dobra książka to stara książka iconix , a stara klasyka to przypadki efektywnego użycia w Cockburn .
O tym, jak obecnie odbywa się to w branży:
Prawdę mówiąc, formalna dokumentacja projektu, a zwłaszcza dokumentacja wymagań, została zabita głównie w czasach Agile , ponieważ Manifest Agile zniechęca formalną dokumentację. Nie ma jednej, pojedynczej, dużej specyfikacji formalnej, ale zamiast tego istnieją tak zwane historie użytkowników , zaległości produktowe i tym podobne. Wynika to z iteracyjnego rozwoju, tylko nieliczne funkcje są określone nieformalnie na każdy cykl 2-4 tygodni. Znana książka to Zastosowane historie użytkowników .
Istnieją tak zwane specyfikacje „wykonywalne”, które są formalne , ponieważ są to zasadniczo języki specyficzne dla domeny (DSL) do testowania. Nie są ani lepsze ani gorsze od OCL UML , ale być może łatwiej je zrozumieć, ale mogą też być mniej naukowe. Większość z nich nosi nazwę frameworków BDD, a przykłady obejmują FitNesse , Cucumber , Jasmine - znajdziesz ich sporo . Istnieją również znane książki o BDD i TDD w ogóle.
Ponadto specyfikacja opracowana przez inżynierów oprogramowania została zastąpiona przez projekt UX , w tym architekturę informacji i projekt interakcji, więc nie jest to robione przez ludzi, którzy potrafią obecnie kodować, co czasami może prowadzić do konfliktu. To niezły przykład tego, jak się wygląda (to nie jest standard!), Ale znajdziesz więcej w społeczności UX / interakcji, ale jest nawet dla nich osobna strona wymiany stosów. Mają własne standardy, zalecane najlepsze praktyki itp.
Ale co, jeśli chcesz trzymać się starych metod, np. do pracy na uniwersytecie?
Zasadniczo staraj się przestrzegać IEEE 830 (nie mogę znaleźć na ich stronie, z czym był zastępowany, chociaż IEEE nigdy nie był z tym dobry, myślę, że to dlatego, że nie ma to niestety znaczenia), i upewnij się, że spróbujesz do rekordowego użytecznych informacji (na przykład nie sądzę, że pojedyncza postać aktor kij -> pojedynczy pęcherzyk z czasownika-wydawany jest uważany za użyteczny), z którego ogólne cele tych użytkowników, ogólny zakres użytkowników i ogólne metody z użycie można odtworzyć w dowolnym momencie.
Dlaczego polecasz książki? Dlaczego zamiast tego nie pokazujesz mi standardów?
Ponownie wydaje mi się, że ten dokument został „zastąpiony”, ponieważ dzisiaj mamy trochę chaosu wokół specyfikacji wymagań: istnieje wiele różnych punktów widzenia na temat tego, jak należy to zrobić.
Nie ma jednego organu, który byłby w stanie powiedzieć: „w ten sposób należy sporządzać specyfikacje” . Istnieją najlepsze praktyki , a ja starałem się przedstawić reprezentatywną listę dokumentów i wskazówek , choć w żadnym wypadku nie kompletną i być może stronniczą.
Na koniec dnia ważne jest, czy dokument, który tworzysz, jest w stanie zrealizować wszystkie cele, które mają wszyscy ludzie, którzy kiedykolwiek go czytają : co ludzie chcą zobaczyć, co ludzie powinni wiedzieć, aby zrozumieć wymagania są dość dobrze opisane w tych książkach i są to najlepsze praktyki same w sobie, aczkolwiek w znacznie mniejszych społecznościach niż jedna, niepodzielna społeczność informatyczna, jaką mieliśmy w 1998 roku.