Jaki standard zastąpił 830-1998?

Zastanawiałem się, jak formalnie dokumentować projekty oprogramowania i dowiedziałem się o IEEE 830-1998: Zalecana praktyka dotycząca specyfikacji wymagań oprogramowania . Jednak, jak widać z tego linku, został on zastąpiony.

Wiem, że 830-1998, a prawdopodobnie nawet 830-1993, są prawdopodobnie odpowiednie do użycia. Jeśli jednak nic innego nie chciałbym wiedzieć, który standard go zastąpił. W tym przypadku może to nie mieć znaczenia, ale jeśli inne standardy zostaną zastąpione bardziej technicznymi sprawami, myślę, że dobrym pomysłem byłoby powiązanie gdzieś tego, który standard zastąpił inny (jeśli nie jest to inny w tej samej linii (830, w tym walizka)).

Warto zaznaczyć, że:

1. Najnowszy standard wyszukiwania „Specyfikacji wymagań programowych” lub „Wymagań programowych” w witrynie IEEE Standards Association to 830–1993,
2. Aktualna wersja SWEBOK z 2004 r. Zawiera odniesienia 830–1993 ( pkt 2.5 ),
3. Artykuł Wikipedii w dokumencie nie wspomina, że ​​standard został zastąpiony.

TLDR: Jak znaleźć, który standard zastąpił inny, a który zajął miejsce 830-1998?

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.

Znalazłem to na stronie IEEE: http://standards.ieee.org/findstds/standard/29148-2011.html

Standardowy 29148: 2011 seens zastępuje IEEE 830: 1998.

Ten standard zastępuje IEEE 830-1998, IEEE 1233-1998, IEEE 1362-1998.

ISO / IEC / IEEE 29148: 2011 zawiera przepisy dotyczące procesów i produktów związanych z inżynierią wymagań dla systemów i produktów oraz usług w całym cyklu życia.

Definiuje konstrukcję dobrego wymagania, zapewnia atrybuty i charakterystykę wymagań oraz omawia iteracyjne i rekurencyjne stosowanie procesów wymagań w całym cyklu życia.