Lepsze słowo na temat wymagań opcjonalnych? [Zamknięte]

12

Jakie jest lepsze słowo na opcjonalne wymaganie w inżynierii oprogramowania? Fraza jest sprzeczna. Użyłem „wymagań innych niż podstawowe” w poprzednich projektach.

Aram Kocharyan
źródło
9
Myślę, że ma na myśli, że coś nie może być zarówno wymagane (jak w „wymaganiu”), jak i opcjonalne (jak w „
niewymaganym
2
To naprawdę należy do angielskiego. I nazwałbym je „opcjami”.
Blrfl,
13
@Blrfl To nie należy do angielskiego. W języku angielskim wyrażenie „wymagania opcjonalne” jest sprzeczne. Ma to jednak powszechnie akceptowane znaczenie w tworzeniu oprogramowania i istnieją alternatywne sposoby sformułowania tej koncepcji w kontekście projektu oprogramowania. Nie ma sensu mieć go nigdzie indziej niż tutaj.
Thomas Owens
3
@ThomasOwens: Nie zgadzam się. Każde pole, w którym zadania mają wymagania, może napotkać ten problem, co uczyniłoby to pytanie zarządzania projektami. Jest to również oksymoron, dzięki czemu jest dobrą paszą dla języka angielskiego, a pierwszy temat w pierwszym FAQ mówi, że wybór słowa jest na temat. Ale dopasuj się.
Blrfl,
5
„Rzeczy, które nie zostaną zbudowane” to to, co oznacza w wielu projektach.

Odpowiedzi:

13

Można ewentualnie użyć terminu „wymóg poza zakresem”. Oznacza to, że wymaganie zostało przechwycone w procesie i można je śledzić, ale ustalono, że wymaganie wykracza poza obecny zakres systemu z wielu powodów, takich jak budżet, harmonogram, czas, lub wykonalność.

Jednak wyrażenie „opcjonalne wymaganie” jest powszechnie używane do oznaczenia zakresu, ale niekoniecznie wymaganego przez system. Jest to miara priorytetu wymagania. Z moich doświadczeń wynika, że ​​wymagania są często traktowane priorytetowo jako obowiązkowe, pożądane lub opcjonalne (chociaż istnieją również inne systemy). Aby projekt mógł zostać uznany za kompletny i w pełni funkcjonalny, muszą zostać spełnione wszystkie obowiązkowe wymagania. Biorąc pod uwagę wystarczające zasoby, pożądane wymagania zostaną następnie wdrożone. Wreszcie, uwzględnione zostanie wszystko, co zostanie uznane za opcjonalne.

Uważam, że zamieszanie pochodzi od terminu „wymóg”. W języku angielskim wymaganie to „rzecz, która jest potrzebna” lub „warunek obowiązkowy, obowiązkowy lub konieczny”. Jednak w inżynierii oprogramowania wymóg ten jest po prostu udokumentowaną cechą systemu oprogramowania. Pojęcie opcjonalne i obowiązkowe opisuje priorytet udokumentowanej cechy systemu oprogramowania.

Thomas Owens
źródło
1
Powiązanym terminem jest „przypadek zmiany”, który jest wymogiem, który jest oczekiwany w pewnym momencie w przyszłości, ale nie jest obecnie objęty zakresem. Przechwytując przypadki zmian, możesz uniknąć robienia czegoś w bieżącym projekcie, co utrudnia przypadki zmian. Robiąc to, musisz jednak uważać na YAGNI.
Kris C
IMHO, „opcjonalne wymaganie” oznacza opcjonalne w czasie teraźniejszym i wymaganie w czasie przyszłym, które może również odczytać opcjonalne potencjalne wymaganie. Tak czy inaczej, zgadzam się, że poza zakresem jest bardziej odpowiednie w przypadku biznesowym, w którym należy zarządzać oczekiwaniami klientów.
Evan Plaice,
25

Nazywamy je funkcjami „miło mieć” w przeciwieństwie do wymagań.

Kretynowie
źródło
2
Z punktu widzenia inżynierii wymagań „miłe mieć funkcje” nadal muszą być wychwytywane jako wymaganie (w specyfikacji, jako historia użytkownika, jako testy akceptacyjne - jednak proces dyktuje, że wymagania są wychwytywane) i śledzone przez całe życie projekt.
Thomas Owens
11

W przypadku dokumentacji wymagań programowych sformułowanie Wymagania opcjonalne jest całkowicie OK, o ile używasz tego terminu zgodnie z RFC 2119 Słowa kluczowe do wskazania poziomów wymagań - tj. Do wskazania pozycji, które są naprawdę opcjonalne.

Jeśli tekst specyfikacji zawiera czasownik zamiast przymiotnika, użyj „MAY” zamiast „OPTIONAL”.

Ponieważ jest mały i łatwy do odczytania, tekst RFC jest w pełni cytowany poniżej:

    Network Working Group S. Bradner
    Prośba o komentarze: 2119 Harvard University
    BCP: 14 marca 1997 r
    Kategoria: Najlepsza bieżąca praktyka


            Słowa kluczowe używane w dokumentach RFC w celu wskazania poziomów wymagań

    Status tej notatki

       Niniejszy dokument określa najlepsze praktyki internetowe dotyczące Internetu
       Społeczność internetowa, prosi o dyskusję i sugestie dotyczące
       ulepszenia. Dystrybucja tej notatki jest nieograniczona.

    Abstrakcyjny

       W wielu standardach dokumentów śledzenia używa się kilku słów do oznaczenia
       wymagania w specyfikacji. Te słowa są często
       skapitalizowane. Ten dokument definiuje te słowa tak, jak powinny być
       interpretowane w dokumentach IETF. Autorzy przestrzegający tych wytycznych
       powinien dołączyć tę frazę na początku swojego dokumentu:

          Słowa kluczowe „MUSZĄ”, „MUSI NIE”, „WYMAGANE”, „MUSZĄ”, „MUSZĄ”
          NIE ”,„ POWINNO ”,„ NIE POWINNO ”,„ POLECAM ”,„ MOŻE ”i
          „OPCJONALNIE” w tym dokumencie należy interpretować zgodnie z opisem w
          RFC 2119.

       Zauważ, że siła tych słów jest modyfikowana przez wymaganie
       poziom dokumentu, w którym są używane.

    1. MUSI To słowo lub określenia „WYMAGANE” lub „MUSZĄ” oznaczać, że
       definicja jest bezwzględnym wymogiem specyfikacji.

    2. NIE WOLNO Ta fraza lub fraza „NIE MUSZĄ” oznaczają, że
       definicja jest absolutnym zakazem specyfikacji.

    3. POWINIEN To słowo lub przymiotnik „ZALECANE” oznaczają, że istnieje
       mogą istnieć ważne powody w szczególnych okolicznościach, aby zignorować
       konkretny element, ale pełne implikacje muszą być zrozumiane i
       dokładnie zważyć przed wyborem innego kursu.

    4. NIE POWINIENE To wyrażenie lub wyrażenie „NIEZALECANE” oznaczają to
       mogą istnieć uzasadnione powody w szczególnych okolicznościach, gdy:
       określone zachowanie jest dopuszczalne, a nawet przydatne, ale pełne
       implikacje należy zrozumieć, a przypadek dokładnie zważyć
       przed wdrożeniem jakiegokolwiek zachowania opisanego za pomocą tej etykiety.

    5. MOŻE To słowo lub przymiotnik „OPCJONALNIE” oznaczają, że rzecz jest
       naprawdę opcjonalne. Jeden sprzedawca może włączyć element, ponieważ
       wymaga tego konkretny rynek lub dlatego, że sprzedawca to odczuwa
       ulepsza produkt, podczas gdy inny sprzedawca może pominąć ten sam produkt.
       Implementacja, która nie zawiera konkretnej opcji MUSI być
       przygotowany do współpracy z innym wdrożeniem, które ma
       uwzględnij tę opcję, choć być może ze zmniejszoną funkcjonalnością. w
       podobnie jak implementacja, która zawiera określoną opcję
       MUSI być przygotowany do współpracy z innym wdrożeniem, które
       nie obejmuje opcji (z wyjątkiem oczywiście funkcji
       opcja zapewnia.)

    6. Wskazówki dotyczące korzystania z tych imperatywów

       Konieczne jest ostrożne stosowanie imperatywów określonych w tej notatce
       i oszczędnie. W szczególności MUSZĄ być używane tylko tam, gdzie jest
       faktycznie wymagane do współpracy lub ograniczenia zachowania, które ma
       możliwość wyrządzenia szkody (np. ograniczenie retransmisji)
       na przykład nie można ich używać do próby narzucenia określonej metody
       na implementatorach, w których metoda nie jest wymagana do zapewnienia interoperacyjności.

    7. Uwagi dotyczące bezpieczeństwa

       Terminy te są często używane do określania zachowania z bezpieczeństwem
       implikacje. Wpływ na bezpieczeństwo braku wdrożenia MUST lub
       POWINIEN, lub robić coś, co mówi specyfikacja NIE MUSI lub POWINIEN
       NIE do zrobienia może być bardzo subtelne. Autorzy dokumentów powinni poświęcić trochę czasu
       opracować implikacje bezpieczeństwa wynikające z nieprzestrzegania
       zalecenia lub wymagania, których większość implementatorów nie będzie miała
       skorzystał z doświadczenia i dyskusji, które doprowadziły do
       specyfikacja.

    8. Podziękowania

       Definicje tych terminów stanowią mieszankę przyjętych definicji
       z wielu RFC. Ponadto sugestie zostały
       zarejestrowanych od wielu osób, w tym Roberta Ullmanna, Thomasa
       Narten, Neal McBurnett i Robert Elz.

Nie zaszkodzi, jeśli twoja dokumentacja odwołuje się do RFC jako źródła definicji:

W tym dokumencie zastosowano definicje oparte na definicjach określonych w RFC 2119 .

komar
źródło
Nawet nie wiedziałem, że to RFC. Nie dziwię się jednak, że coś takiego istnieje, jako standard IEEE, ISO, RFC lub inny podobny opublikowany dokument.
Thomas Owens
Ten dokument wydaje się zbyt specyficzny, aby mógł być szeroko stosowany jako wytyczne dotyczące wymagań oprogramowania. Nie jest zatytułowany „Słowa kluczowe dla wymagań”, zatytułowany „Słowa kluczowe dla wymagań w RFC”, a w dyrektywie 6 celowo ogranicza swój zakres.
Robert Harvey
1
@RobertHarvey dobrze, moim celem było zajęcie się pytaniem, że należy szukać lepszego słowa, aby zastąpić ustalony termin zawodowy dobrze zdefiniowaną i udokumentowaną semantyką tylko dlatego, że uważają, że nie jest to doskonały angielski. Jeśli chodzi o to, że jest zbyt szczegółowe, czy nie, byłoby to zupełnie inne pytanie, nie sądzisz? Mogę sobie wyobrazić wiele przypadków, w których wolałbym kategoryzować styl MoSCoW .
komara
@gnat, On nie potrzebuje czasownika. W tym poście nie ma odpowiedzi Jakie jest lepsze słowo „opcjonalne wymagania”?
Pacerier
7

Rozumiem, że to nie jest odpowiedź na twoje pytanie, ale w moim świecie wciąż jest to wymóg, nawet jeśli z jakiegokolwiek powodu nie zamierzasz go spełnić.

Lubię podejście MoSCoW (Must Have, powinien mieć, mógłbym, nie będę miał tego czasu) do kategoryzowania wymagań z użytkownikami, a także innych czynników (w moim regulowanym świecie wymagania mogą być krytyczne lub niekrytyczne, a wiele spiera się o opcjonalne, ale krytyczne wymagania).

PaulHurleyuk
źródło
4

Lepszym określeniem opcjonalnego wymogu jest „ zalecenie

Michael Durrant
źródło
2

Co powiesz na zidentyfikowanie go jako funkcji opcjonalnej lub zadań opcjonalnych. Zostanie to wykonane tylko wtedy, gdy w pewnym momencie projektu zostanie ustalone, że dostępny jest czas i pieniądze na dokończenie tych funkcji.

Można je również uruchomić w przypadku wystąpienia zdarzenia zewnętrznego. Jeśli klienci przejdą na system Windows 8, należy wykonać następujące zadania ...

Opis funkcji powinien zawierać termin ustalenia, czy zostaną one wykonane.

mhoran_psprep
źródło
1

Wymagania są podzielone na 4 obszary w inżynierii oprogramowania:

  1. Wymagania biznesowe : Koncentruje się na ogólnych celach biznesowych i założeniach systemu
  2. Wymagania użytkownika : Koncentruje się na celach użytkownika i tym, co użytkownicy muszą zrobić, aby użyć systemu do osiągnięcia celów biznesowych
  3. Wymagania funkcjonalne : Jakie funkcje i zadania musi wykonać system, aby osiągnąć cele biznesowe
  4. Wymagania niefunkcjonalne : Jakie są wymagania inne niż funkcjonalne. Obejmuje to środowisko, ograniczenia, interfejs, problemy z konserwacją itp.

Teraz wymagania mogą być opcjonalne lub obowiązkowe , w zależności od powyższych 4 kategorii, które opisałem powyżej. Wymagania opcjonalne mogą również wchodzić w zakres rozważanego systemu lub poza jego zakres. Wymagania opcjonalne to dobry sposób na uniknięcie pełzania zakresu i precyzyjne zdefiniowanie zakresu.

Wymagania opcjonalne zawsze będą częścią inżynierii oprogramowania, ponieważ pomagają nam zidentyfikować zakres i są dobrym sposobem na uniknięcie pełzania zakresu. Nigdy nie można powiedzieć, że są one sprzeczne z praktykami inżynierskimi SDLC. Wymagania muszą jednak zostać uszeregowane według priorytetów i dobrze określone.

Maxood
źródło
1
Pytanie wymaga innego terminu „wymagania opcjonalne”, a nie kategoryzacji wymagań.
yannis
1
Gdyby znał kategoryzację, nigdy nie powiedziałby, że wymagania opcjonalne są sprzeczne w inżynierii oprogramowania. :)
Maxood,
1
dobre opisy, ale wciąż jestem trochę zirytowany tym zwrotem - albo coś jest wymagane, albo nie jest. Myślę, że wprowadziliśmy „wymóg” w oddzielny byt, co oznacza „formalną potrzebę klienta” ...
Aram Kocharyan
@Maxood Hmmm? Termin jest sprzeczny, a nie koncepcja, pytanie omawia termin. Czy masz jakieś wzmianki, że termin ten jest częścią dowolnego formalnego (lub powszechnie akceptowanego) modelu wymagań? Wiem, że to powszechne, ale rzucanie takimi rzeczami jak „Wymagania opcjonalne zawsze będą częścią inżynierii oprogramowania” bez jednego odniesienia, nie jest tak naprawdę moją filiżanką herbaty.
yannis
@ Yannis Rizos Kiedy powiedziałem „Wymagania opcjonalne zawsze będą częścią inżynierii oprogramowania”, miałem na myśli to w kontekście koncepcyjnym. Ponieważ inżynieria polega na wypracowaniu skutecznego rozwiązania w ramach budżetu przy jednoczesnym zrównoważeniu sprzecznych wymagań. Pytający nigdy nie wymienia tutaj
Opcji
1

W szablonie Volere używany jest termin „poczekalnia”.

... Ten szablon jest przeznaczony do użycia jako podstawa specyfikacji wymagań. Szablon określa każdy z typów wymagań odpowiednich dla dzisiejszych systemów biznesowych, naukowych i oprogramowania. Zapewnia listę kontrolną, strukturę i identyfikowalność dla twoich wymagań ... Szablon jest niezależny od narzędzi i został z powodzeniem używany z Yonix, Requisite, DOORS, Calibre RM, IRqA i innymi popularnymi narzędziami ...

Techniki Volere zostały opisane w książce Mastering the Requirements Process autorstwa Suzanne Robertson i James Robertson ...

Danny Varod
źródło
0

W mojej firmie (statki kosmiczne) są one nazywane „celami”, co oznacza, że ​​są udokumentowane i wysiłek zostanie poświęcony na ich spełnienie, ale system nadal będzie uważany za sukces, jeśli nie zostanie osiągnięty; „pragnienia” (nie jest to prawdziwe słowo, ale tam jesteś), wskazujące, że ktoś chce ich i stara się osiągnąć status celów, ale nie są jeszcze akceptowane ani dokumentowane; lub „pełzające wymagania”, które są bardziej uwłaczającą wersją pragnień wskazujących na rzeczy, które próbują przejąć zasoby, ale które nie są tego warte w projekcie próbującym osiągnąć „wystarczająco dobry”, w którym zagroziłyby lub groziłyby spełnieniem rzeczywistych wymagań.

Mark Adler
źródło
0

Jeśli twoje wymagania są traktowane priorytetowo , możesz uznać je za wymagania o niskim priorytecie .

calum_b
źródło
Myślę, że „zero priorytetu” może być bliższe „opcjonalnemu”.
Pacerier
0

Dziwi mnie, że nikt nie wspomniał, że są to tak zwane „cele”. Każda firma, w której pracowałem, tak je nazywa. Są one oznaczone słowami „wola” lub „powinien” zamiast „powinien”. Czasami są one uwzględnione w nawiasach klamrowych, gdy mówimy o liczbach. np. system będzie działał w sposób ciągły bez potrzeby uwagi operatora przez 100 {250} godzin. Oznacza to, że wymóg, który należy spełnić, to 100 godzin, ale cel to 250 godzin.

Na marginesie, bardzo rzadko ktokolwiek faktycznie planuje spełnienie obiektywnego wymogu, chyba że wiąże się to z jakąś zachętą.

Maczać
źródło
0

Termin „pragnienie” jest czasem używany w przypadku wymagań opcjonalnych. Jednak formalny dokument może nie być odpowiedni.

Craig Schwarze
źródło
0

Dziwi mnie, że wszystkie odpowiedzi dotyczą wymagań związanych z śledzeniem w trakcie opracowywania projektu. Mimo, że jestem programistą, nigdy nie martwiłem się zbytnio tą terminologią w tym kontekście. Kiedy po raz pierwszy przeczytałem pytanie, założyłem, że odnosi się ono do specyfikacji produktu użytkownika, a nie do rozwoju produktu. Na przykład encyklopedia może wymieniać drukarkę kolorową jako wymaganie opcjonalne. Jest to wymagane, jeśli chcesz w pełni korzystać z aplikacji, ale opcjonalne, jeśli chcesz wyświetlić ekran. Ale co, jeśli masz na przykład drukarkę monochromatyczną? Jak wyjaśnić, czy aplikacja działa z oczywistym ograniczeniem, że niektóre zdjęcia mogą nie wyglądać tak dobrze? Czy w ogóle nie wydrukuje? jak powinienem sprawdzić recenzję drukarki, aby sprawdzić, czy atrament jest wymaganiem, czy opcjonalnym wymaganiem w drukarce wielofunkcyjnej? Innymi słowy, czy nadal mogę skanować? Niektóre wskazówki dotyczące terminologii i tego, czego szukać, byłyby mile widziane zarówno jako twórca / sprzedawca produktu, jak i konsument.

g1cmz
źródło
Uhm, więc jakie jest lepsze określenie „opcjonalne wymagania”?
Pacerier
0

Nazwałbym je „funkcjami opcjonalnymi”, a nie wymaganiami opcjonalnymi. Wymagania brzmią jak coś, co musisz mieć , a funkcje brzmią jak dodatek do oryginalnego produktu.

Billjk
źródło