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

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.

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.

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

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 .

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).

Lepszym określeniem opcjonalnego wymogu jest „ zalecenie ”

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.

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.

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 ...

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ń.

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

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ą.

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

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.

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