Jaka jest różnica między wymaganiami a specyfikacjami? [Zamknięte]

122

Zadanie polegało na opracowaniu wymagań i specyfikacji dla projektu, który rozpoczyna nasza grupa.

Uświadomiłem sobie, że nie znam różnicy; wyszukiwarka Google po prostu bardziej mnie zdezorientowała - wydaje się, że niektórzy twierdzą, że specyfikacje są wymaganiami, ale na niższym poziomie.

requirements specifications

Zgadzam się z odpowiedziami o wysokim głosowaniu, ale uważam również, że określenie specyfikacja jest czasem używane jako bardziej ogólny termin w branży oprogramowania w odniesieniu do każdego dokumentu opisującego system lub oprogramowanie. Jako dowód - Google „specyfikacja wymagań”. Kiedy jest używany w ten sposób, oznacza to dokument, który coś określa - tzn .: określa wymagania dla oprogramowania. Nie będę oceniać, czy to prawidłowe użycie tego słowa, czy nie. Chciałem tylko zauważyć, że specyfikacja nie zawsze oznacza to samo dla wszystkich.

— Shane Wealti,

1

Tak, dlatego ludzie powinni powiedzieć „Wymagania biznesowe” i „Specyfikacja projektu” / „Specyfikacja techniczna” lub coś w tym rodzaju. Same słowa są dość niejasne.

— user606723,

Pomyśl o tym w ten sposób (z grubsza): Wymagania = dokument wymagań i specyfikacje = przypadek użycia / dokumentacja projektowa

— doktorat

4

Dlaczego nie zapytasz osoby, dla której je tworzysz? Tylko oni mogą odpowiedzieć na to, co jest potrzebne w konkretnym przypadku .

— Jaap

Ten artykuł zawiera dokładną odpowiedź: ece.cmu.edu/~koopman/des_s99/requirements_specs

— Julien-L

129

Dźwiękowa odpowiedź brzmi, że wymagania są tym, co powinien zrobić Twój program, a specyfikacje są takie, jak planujesz to zrobić.

Innym sposobem spojrzenia na to jest to, że wymagania reprezentują aplikację z perspektywy użytkownika lub całej firmy. Specyfikacja reprezentuje aplikację z punktu widzenia zespołu technicznego. Specyfikacje i wymagania z grubsza przekazują te same informacje, ale dwóm zupełnie innym odbiorcom.

— Bryan Oakley
źródło

4

To, co / jak ugryzienie dźwięku jest właściwe, w pewnym sensie; ale mylące, ponieważ można również spojrzeć na specyfikację programu jako opisującą to , co powinien zrobić, a projekt jest taki, jak powinien to zrobić. Innym jest deklaratywny pl (jak prolog i SQL), w którym podajesz co nie jak . Jednym z rozwiązań jest to, że są one hierarchiczną abstrakcją, w której rodzic mówi co, a dzieci - jak (na zewnątrz kontra wewnątrz). Wolę swój drugi pogląd, który jest bliżej do „co to za ” vs „co to jest ”, czyli korzyści w porównaniu z funkcji.

— 13ren

Generalnie zgodziłbym się z tobą, ale to tylko „kolejna” opinia, a nie poprawna odpowiedź. Na przykład spójrz na stronę Wiki dotyczącą wymagań ( en.wikipedia.org/wiki/Requirement ). Istnieją wymagania niefunkcjonalne, które z definicji dotyczą zespołu technicznego. Lub wymagania architektoniczne i ograniczenia, znów techniczne, ale nie nazywają ich „specyfikacjami”. Myślę, że nie ma poprawnej odpowiedzi i zawsze będzie „rozmazana” od firmy do firmy i od programisty do programisty.

— Jeach

1

Spójrz na odpowiedź „Adam Wuerl” poniżej, myślę, że jest to najbardziej dokładne stwierdzenie na zadane pytanie.

— Jeach

1

@Jeach: „poniżej” [sic] jest względne. W tej chwili może być poniżej tego postu, ale może się przenieść powyżej, co utrudni zrozumienie twojego komentarza

— Bryan Oakley,

1

Inna perspektywa. Wikipedia definiuje specyfikacje jako „zestaw wymagań”. Oznacza to, że specyfikacja może być tylko 1 wymaganiem, s: = {r1}. Wydaje się bardziej, że potoczne „wymagania” są wymaganiami „wysokiego poziomu”, podczas gdy „specyfikacje techniczne” są wymaganiami niskiego poziomu, rzeczą LOD.

— Lance Pollard

38

Wymagania dokumentują, co jest potrzebne - nie powinny określać, w jaki sposób, ale co.

Specyfikacje dokumentują sposób spełnienia wymagań - powinny one określać, w jaki sposób.

W wielu miejscach dokumenty te nie są oddzielne i są używane zamiennie.

— Oded
źródło

2

W mojej firmie zwykle używamy terminów „specyfikacji wymagań” do tego, co (określasz, zapisujesz szczegóły, co do czego), oraz „specyfikacji projektu” do tego, w jaki sposób (określasz, zapisujesz szczegóły, w jaki sposób plan go wdrożyć).

— Giorgio

16

Jestem inżynierem systemów w dziedzinie lotnictwa, gdzie oba terminy są szeroko stosowane. Rozróżnienie jest jasne i nie jest tak skomplikowane, jak robią to inni.

Specyfikacja jest dokumentem, który określa system lub produkt, np specyfikacji rozwoju prime-punkt dla F-14. Istnieje wiele sekcji / treści w specyfikacji: wymagania, definicje, dokumenty referencyjne, glosariusz, informacje weryfikacyjne itp.

Wymogiem jest jedno stwierdzenie czegoś produkt lub system musi zrobić. Specyfikacja może zawierać setki wymagań. Metodologia starej szkoły mówi, że w wymaganiu należy użyć słowa „musi”, aby oddzielić wymagania od stwierdzeń faktów lub definicji. (Nie jestem pewien, czy nowiutkie, zwinne dzieci trzymają się tego wszystkiego, czy nie; wybredność ma swoje zastosowanie, ale czasami jest trochę wybredna).

Tak więc specyfikacja jest dokumentem pełnym wymagań, a także innymi informacjami pomocniczymi i pomocniczymi.

— Adam Wuerl
źródło

4

Jak powiedziałem w innym komentarzu, jest bardzo rozmazany dla wszystkich i prawdopodobnie zawsze będzie. Ale w oparciu o moje własne BARDZO obszerne badania na ten dokładnie temat, powiedziałbym, że twoja odpowiedź jest najdokładniejsza z moich własnych wniosków / wniosków.

— Jeach

2

Zawsze pomocny, aby uzyskać prawdziwy wkład inżyniera. Dzięki!

— LeWoody,

Alternatywnie specyfikacja może mieć 0 wymagań. Twój przykład jest naprawdę dobry dla bardzo specyficznej dyscypliny inżynierii lotniczej. Nie jestem pewien, czy ogólnie dotyczy to dziedziny programowania / programowania. Gdy większość oprogramowania zależy od wymagań biznesowych, warto zacząć od szczegółowego dokumentu wymagań biznesowych przed oceną ograniczeń technicznych i zaprojektowaniem rozwiązania. Specyfikacja techniczna będzie zgodna z BRD, dokumentuje ograniczenia i zapewnia szczegółowe i szczegółowe podejście do spełnienia wymagań biznesowych w BRD.

— Bryan „BJ” Hoffpauir Jr.

1

@ Bryan'BJ'Hoffpauir Jestem pewien, że istnieją przypadki, w których dokumenty są oznaczone specyfikacjami i nie mają w nich żadnych wymagań, ale twierdziłbym, że jest to niewłaściwe użycie tego terminu. Specyfikacja to dokument wymagań - koniec historii. Jest to powszechnie akceptowany termin sztuki obejmujący wiele dziedzin, takich jak lotnictwo i obrona, i jest nieosiągalny w inżynierii systemów, która jest dyscypliną odpowiedzialną za wymagania i weryfikację. Nawet w przypadku, gdy opisujesz ten termin, ma zastosowanie: BRD jest specyfikacją, specyfikacja techniczna również brzmi jak taka, z różnymi rodzajami wymagań.

— Adam Wuerl,

13

Wymagania:

Określ potrzeby lub warunki, które należy spełnić w przypadku nowego lub zmienionego produktu, biorąc pod uwagę potencjalnie sprzeczne wymagania różnych zainteresowanych stron.

Dane techniczne:

Zapewniają precyzyjne wyobrażenie o problemie do rozwiązania, dzięki czemu mogą efektywnie zaprojektować system i oszacować koszty alternatywnych rozwiązań. Dostarczają one testerom wskazówek dotyczących weryfikacji (kwalifikacji) każdego wymagania technicznego.

Cytat pochodzi z „Podstawy inżynierii systemów ^* ”.

Wymagania oparte są na potrzebach interesariuszy, specyfikacje są bardziej szczegółowym i technicznym dokumentem. Różnią się, ale mówią o tym samym.

_{* Defense Acquisition University Press, 2001. Tekst w wersji PDF .}

— talabes
źródło

Myślę, że ważne jest, aby twoja definicja mówiła, że specyfikacja definiuje PROBLEM. W ten sposób specyfikacja PROBLEMU jest wymagana. Specyfikacja SOLUTION lub DESIGN jest częścią projektu.

— LeWoody,

6

Wymagania to opis użytkowników, co powinien zrobić gotowy produkt.

Specyfikacja to ogólnie opis techniczny rozwiązania, obejmujący wymagania i wiele więcej - np. Koszty, szczegóły techniczne, problemy itp.

Dlatego jednym z głównych punktów jest to, że wymagania muszą być na pierwszym miejscu, zanim można będzie napisać specyfikację.

(Zwróć uwagę na terminologię - produkt i rozwiązanie - to samo, ale z różnych perspektyw ...)

— Arj
źródło

1

Zamieniłbym terminy „produkt” i „rozwiązanie”, ponieważ rozwiązanie dotyczy zazwyczaj problemu klienta, podczas gdy produkt zwykle dotyczy sprzedawcy (tzn. Realizatora technicznego). Podobnym kontrastem jest korzyść / funkcja, gdzie korzyść jest pod względem klienta (jaki jest dla nich użytek), a funkcja pod względem implementacji (co to właściwie jest , abyśmy mogli to zrobić).

— 13ren,

1

Rozumiem twój punkt widzenia, ale myślę, że którykolwiek z kątów odpowiednio opisuje sytuację. Uznałem, że klient będzie kupował produkt - tak jak ty, kiedy idziesz do sklepu. Sprzedawca oprogramowania zaproponowałby wówczas rozwiązanie podstawowego problemu. Gdybym miał wybrać rozwiązanie mojego problemu, prawdopodobnie pomyślałbym: „Potrzebuję produktu, który działa xyz”, a nie „Potrzebuję rozwiązania mojego problemu z abc”. Myślę, że to tylko kwestia preferencji.

— Arj

ciekawy. Widzę klientów „szukających produktu”, gdy istnieje ustalona kategoria produktu. Ale szukają tego produktu, ponieważ już odkryli, że rozwiąże on ich problem - tzn. Szukają tego produktu nie dla samego siebie, ale jako rozwiązanie. Prawdą jest również to, że sprzedawca sprzedaje swój produkt jako „rozwiązanie” - ale dzieje się tak, ponieważ próbują komunikować się z klientami (którzy szukają rozwiązań swoich problemów) i budować coś, co będzie potrzebne. Właściwie budowanie produktu (to znaczy rzecz sama w sobie i jej funkcje niezależnie od tego , dlaczego są potrzebne)

— 13ren

Widzę klientów „szukających produktu”, gdy istnieje ustalona kategoria produktu - ale szukają go jako rozwiązania problemu / potrzeby, którą mają. Sprzedawcy sprzedają swoje produkty jako „rozwiązania” - ponieważ komunikują się z klientami (którzy mają problemy z wymaganiem rozwiązań). Podczas budowania produktu (sama rzecz i jej cechy, a nie dlaczego ją budują). Jednym argumentem jest to, że problem może mieć bardzo różne rozwiązania - ale produkt to jedna konkretna rzecz.

— 13ren

[wyjaśniając, dlaczego dwa komentarze]: Komentarze SO są takim bólem - naciśnięcie „return” spowoduje przesłanie komentarza, nawet jeśli jest to wielowierszowy obszar tekstowy. A jeśli zajmie Ci to więcej niż 5 minut, nie zaakceptuje edycji. Musisz go przesłać jako drugi komentarz. Edytowałem tylko po to, żeby pasowała do długości. westchnienie . Następnym razem po prostu rozłożę dwa komentarze w pierwszej kolejności ... [w każdym razie, zgadzam się, że punkt widzenia - kupujący / sprzedawca - jest głównym wyróżnieniem. Niepokoi mnie twoja terminologia, ale myślę, że to pogłębia moje zrozumienie, próbując

— wyjaśnić,

4

Wymagania - co powinien (musi) zrobić system lub podsystem.

Specyfikacja - czym jest składnik, podsystem lub system.

Ma to kluczowe znaczenie w branży produkcji wyrobów medycznych, ponieważ należy przeprowadzić weryfikację pod kątem wymagań (dane wejściowe), aby wykazać, że masz prawidłowe specyfikacje (dane wyjściowe). Typowe pułapki w tej branży polegają na tym, że firmy (1) zapominają zdefiniować wymagania (ponieważ nie rozumieją różnicy między wymaganiem a specyfikacją); (2) Przeprowadź weryfikację tylko na podstawie specyfikacji i (3) Nie upewniaj się, że wymagania zostały dokładnie przetłumaczone na specyfikacje podzespołów i komponentów.

Po zakończeniu tej czynności należy sprawdzić poprawność wymagań użytkownika dotyczących produktu.

— Paul Bacchus
źródło

3

Być może zamieszanie polega na tym, że słyszałem, że specyfikacje odnoszą się do dokumentów specyfikacji wymagań biznesowych lub standardowych dokumentów IRSE SRS (specyfikacji wymagań oprogramowania).

Przykład szablonu SRS standardu IEEE

Słyszałem również, że określenie specyfikacje odnosi się bardziej nieformalnie do specyfikacji technicznych, które wyjaśniają decyzje projektowe i plan wdrożenia.

EDYCJA: Właśnie zauważyłem, że link jest nieprawidłowy ... Wkrótce opublikuję poprawny link.

— wałek klonowy
źródło

1

Dobra uwaga na temat terminu SRS!

— LeWoody,

2

Link jest teraz całkowicie zepsuty. Nie jestem pewien, na co wskazywał, ani na jaki materiał powinien wskazywać.

3

Specyfikacja jest wymogiem, który przeszedł wykonalność i jest gotowy do wdrożenia. Jest to wymóg, który ewoluował do fazy projektowania.

Innymi słowy:

Wymaganiem jest zachowanie (lub brak zachowania) „zgodnie z planem” lub „zgodnie z życzeniem”
Specyfikacja to zachowanie (lub brak zachowania) „do zbudowania” lub „jak zbudowane”

Przykład:

wymaganie: 1. użytkownik naciska przycisk OK 2. system drukuje fakturę
specyfikacja: 1. użytkownik naciska przycisk OK 2. system drukuje fakturę

Jak widać, zawartość obu może być taka sama. Różnica polega na tym, że wymaganie jest artefaktem analizy. Specyfikacja jest artefaktem projektowym.

W końcowej dokumentacji powykonawczej zwykle znajduje się słowo „specyfikacja” zamiast „wymaganie”, ponieważ wymagania zostały przekształcone w specyfikacje.

Uwaga: powyższy przykład zawiera elementy projektu z powodu ograniczeń projektowych.

— fox.bailey
źródło

0

Wymagania są tym, co robi aplikacja

Specyfikacje dotyczą tego, w jaki sposób aplikacja robi to, co robi.

Muszą być ortogonalne!

Menedżerowie produktu piszą wymagania, główni inżynierowie piszą specyfikacje.

— jayunit100
źródło

2

Nie jestem pewien, czy są całkowicie ortogonalne, przynajmniej w praktyce. Niestety jest dużo szarości.

— LeWoody

Są szare tylko wtedy, gdy pominiesz modyfikatory - Wymagania biznesowe, wymagania funkcjonalne, wymagania niefunkcjonalne odnoszą się do możliwości systemu (CO on robi). Specyfikacje techniczne są ortogonalne w stosunku do wymagań biznesowych (JAK to robi).

— Bryan „BJ” Hoffpauir Jr.

0

Jeden ze sposobów, być może niewłaściwy, na to spojrzeć:

Wymagania to rzeczy (możliwości, funkcje, zachowania itp.), Które zapewniają wartość dla użytkownika. Nie dotyczy wewnętrznych; ważne są tylko dane wejściowe i wyjściowe skrzynki (i może rozmiar, kształt i kolor).

Specyfikacje to rzeczy (możliwości, funkcje, zachowania itp.), Które włączają tę wartość dla użytkownika. Tutaj wewnętrzne elementy skrzynki są ważne, ponieważ wraz z zewnętrznymi interfejsami i wyżej wymienionymi cechami definiują cały system.

— berad
źródło

czy to tylko Twoja opinia, czy możesz jakoś to zrobić?

— komar

2

@gnat, myślałem, że to zostało rozwiązane w pierwszym wierszu? Jasne, wynika to z doświadczenia i nie twierdzę, że nic innego - z tego, co uznaję, jest to dość subiektywne pytanie na dość subiektywnym forum, a ten post sugeruje, że pytania powinny być tak obiektywne, jak to możliwe, ale niewiele wspomina o odpowiedziach . Ale mam jeden na imię i masz o wiele więcej, więc jestem otwarty na edukację :-)

— berad

0

W moich badaniach znalazłem Specyfikacje do wykorzystania w patentach i budownictwie mieszkaniowym (w ramach umowy).

Definicja wymagania ze Słownika Webna's Webnaster (3rd New Int'l Ed.) To:

a) coś, co jest potrzebne lub potrzebne: konieczność b) coś wymaganego lub wymaganego: wymagany lub niezbędny warunek: wymagana jakość, kurs lub rodzaj szkolenia

Myślę, że powyższe pokazuje, że są wyraźnie różne. Wydaje mi się, że można nazwać wymagania niższego poziomu specyfikacji, ale myślę, że jest to wypaczenie terminu „wymaganie”.

— LeWoody
źródło

0

W poprzedniej firmie tworzącej produkty komercyjne mieliśmy następujące wyróżnienie:

Wymagania są tym, co musi zrobić system. Mogą mieć niższy poziom, szczegółowe wymagania i mogą być funkcjonalne lub niefunkcjonalne.

Specyfikacje to rzeczy, które faktycznie wykonuje system w takiej postaci. Na przykład możesz mieć wymaganie określające, że system powinien mieć zachowanie X w temperaturze –10 ° C. Rzeczywista specyfikacja systemu może być taka, że system ma X w temperaturze –5 ° C; byłoby to w arkuszu wysłanym do potencjalnych klientów, którzy chcieliby kupić system.

Uwaga: w tym przypadku specyfikacja nie odpowiada wymaganiu.

— RoyD
źródło

-1

Pomyśl, zbudujesz wieżowiec na lądzie.

Teraz musisz rozważyć wymagania przed rozpoczęciem, takie jak:

Inżynier architektury lub projektowania
Inżynier ds. Testów gleby
Zespół testujący ciśnienie wiatru
Rozbiórka
Koparka
Moc człowieka
Zaopatrzenie w wodę
Pracownicy mieszkają / odpoczywają
Wystarczający fundusz
Zarządzanie projektami
Zarządzanie jakością
Bezpieczeństwo i kontrola bezpieczeństwa

Itp.

Teraz powyższa zawartość jest częścią Wymagań do zbudowania wieżowca. Od powyższego zespołu otrzymujesz wynik techniczny, który są one częścią zawodu.

Dokładnie to dzieje się w branży oprogramowania, grupie profesjonalnych ludzi zaangażowanych w dostarczanie wiedzy w celu opracowania specyfikacji technicznych, takich jak ktoś, kto pracuje nad projektowaniem interfejsu użytkownika, projektem OO, projektem bazy danych, projektem graficznym, projektem przypadku testowego, kodowaniem, integracją , zespół wdrożeniowy itp.

Powyższy ustęp będzie częścią podręcznika, który możesz nazwać Specyfikacją Techniczną.

— Mohammed Hoq
źródło

1

Myślę, że mylisz wymagania z zasobami ( en.wikipedia.org/wiki/Resource_%28project_management%29 ).

— Jay Elston,