Краще слово для необов'язкових вимог? [зачинено]

Що краще за необов’язкові вимоги в інженерії програмного забезпечення? Фраза суперечлива. Я використовував "Неосновні вимоги" в попередніх проектах.

Термін "вимога поза сферою", можливо, може бути використаний. Це означає, що ця вимога була охоплена у вашому процесі та відстежується, але було визначено, що ця вимога виходить за межі поточної сфери дії системи через низку причин, таких як бюджет, графік, час, або доцільність.

Однак словосполучення "необов'язкова вимога" зазвичай використовується для позначення чогось, що є сферою дії, але не обов'язково вимагається системою. Це міра пріоритетності вимоги. На мій досвід, вимоги часто надають пріоритет як обов'язкові, бажані чи необов'язкові (хоча існують і інші схеми). Для того, щоб проект вважався завершеним і повністю функціональним, всі обов'язкові вимоги повинні бути виконані. З урахуванням достатніх ресурсів бажані вимоги будуть впроваджені далі. Нарешті, буде включено все, що вважається необов’язковим

Я вважаю, що плутанина походить від терміна "вимога". В англійській мові вимога - "річ, яка потрібна" або "обов'язкова, обов'язкова або необхідна умова". Однак в інженерії програмного забезпечення термін вимога є просто документально підтвердженою характеристикою програмної системи. Концепція факультативного та обов'язкового описує пріоритет документально підтвердженої характеристики програмної системи.

Ми називаємо їх функціями "приємно мати" на відміну від вимог.

Для документації з вимогами до програмного забезпечення формулювання Додаткових вимог є цілком нормальним, якщо ви використовуєте цей термін відповідно до ключових слів RFC 2119 для вказівки рівнів вимог - тобто для позначення предметів, які справді є необов'язковими.

Коли ваш текст специфікації передбачає дієслово замість прикметника, використовуйте "МАЙ" замість "ОПЦІОНАЛЬНО".

Оскільки він невеликий і легкий для читання, текст RFC повністю цитується нижче:

    Мережева робоча група С. Бреднер
    Запит щодо коментарів: 2119 Гарвардський університет
    BCP: 14 березня 1997 року
    Категорія: Краща поточна практика


            Ключові слова для використання в RFC для вказівки рівнів вимог

    Статус цієї Пам'ятки

       Цей документ визначає найкращі поточні практики в Інтернеті для цієї програми
       Інтернет-спільнота, і вимагає обговорення та пропозицій щодо
       поліпшення. Поширення цієї примітки необмежене.

    Анотація

       У багатьох стандартних документаційних документах для позначення використовується кілька слів
       вимоги в специфікації. Ці слова часто
       з великої літери. Цей документ визначає ці слова такими, якими вони мають бути
       інтерпретується в документах IETF. Автори, які дотримуються цих вказівок
       слід включити цю фразу біля початку документа:

          Ключові слова "ОБОВ'ЯЗКОВО", "НЕ ПОВИННІ", "ПОТРІБНО", "ОБОВ'ЯЗКУЙТЕСЬ", "ЗАГАДИТИ
          НЕ "," ПОТРІБНО "," ПОТРІБНО "," РЕКОМЕНДОВАНО "," МОЖЕ "та
          "ОПЦІОНАЛЬНИЙ" у цьому документі слід тлумачити так, як описано в
          RFC 2119.

       Зауважте, що сила цих слів змінена вимогою
       рівень документа, в якому вони використовуються.

    1. ОБОВ'ЯЗКОВО Це слово або терміни "ПОТРІБНО" або "ОБОВ'ЯЗКОВО" означають, що
       визначення є абсолютною вимогою специфікації.

    2. НЕ ПОВИННІ ЦЕ словосполучення або фраза "НЕ БУДЕ" означають, що
       визначення є абсолютною забороною специфікації.

    3. ПОТРІБНО Це слово, або прикметник «РЕКОМЕНДУЙ», означають, що там
       можуть існувати обґрунтовані причини, за яких обставин ігнорувати а
       конкретного пункту, але слід розуміти і повне значення
       ретельно зваживши перед вибором іншого курсу.

    4. НЕ БУДЕ НЕ ЦЕ словосполучення або фраза "НЕ РЕКОМЕНДУЄ" означають це
       можуть існувати поважні причини, зокрема, обставини, коли
       конкретна поведінка є прийнятною або навіть корисною, але повною
       наслідки слід розуміти, а справу ретельно зважувати
       перш ніж застосовувати будь-яку поведінку, описану з цією міткою.

    5. МОЖЕ Це слово або прикметник "ОПОРАЧНО" означають, що предмет
       справді необов’язково. Один постачальник може вирішити включити товар, оскільки: a
       конкретний ринок вимагає цього або тому, що продавець відчуває це
       він вдосконалює товар, тоді як інший продавець може пропустити той самий товар.
       ВІДПОВІДЬ, яка не включає певний варіант
       готовий взаємодіяти з іншою реалізацією, яка це робить
       включіть опцію, хоча можливо зі зниженою функціональністю. В
       таку ж саму реалізацію, яка включає в себе певний варіант
       ПОВИНЕН бути готовим до взаємодії з іншою реалізацією, яка
       не включає опцію (крім, звичайно, для функції
       опція передбачена.)

    6. Керівництво щодо використання цих імперативів

       Імперативи типу, визначені в цій примітці, повинні використовуватися обережно
       і щадно. Зокрема, їх ОБОВ'ЯЗКОВО використовувати лише там, де вони є
       насправді необхідні для взаємодії або обмеження поведінки
       потенціал заподіяння шкоди (наприклад, обмеження повторної передачі) Для
       Наприклад, вони не повинні використовуватися для спроби нав'язати певний метод
       на виконавцях, де метод не потрібен для взаємодії.

    7. Міркування безпеки

       Ці терміни часто використовуються для визначення поведінки із захистом
       наслідки. Вплив на безпеку невиконання ПОВИННО або
       ПОТРІБНО, або виконуючи те, що специфікація каже, ПОВИННО НЕ БУДЕТ або
       НЕ робити це може бути дуже тонким. Автори документів повинні брати час
       розробити наслідки для безпеки, які не слід виконувати
       рекомендації або вимоги, як і більшість виконавців, не матимуть
       мали користь із досвіду та обговорень, які спричинили за собою
       специфікація.

    8. Подяка

       Визначення цих термінів - це сукупність прийнятих визначень
       від ряду RFC. Крім того, були пропозиції
       включений від ряду людей, включаючи Роберта Уллмана, Томаса
       Нартен, Ніл Макбернет і Роберт Ельц.

Не завадить, якщо ваша документація посилається на RFC як джерело визначень:

У цьому документі використовуються визначення, засновані на визначених у RFC 2119 .

Я вдячний, що це не відповідь на ваше запитання, але в моєму світі це все ж є вимогою, навіть якщо з будь-якої причини ви не збираєтесь її виконувати.

Мені подобається підхід MoSCoW (Повинен мати, повинен мати, міг би, не матиме цього разу) класифікувати вимоги до користувачів разом з іншими факторами (у моєму регульованому світі вимоги можуть бути критичними або некритичними, і багато аргумент спалахує над необов'язковими, але критичними вимогами.)

Краще слово для необов'язкової вимоги - " Рекомендація "

Як щодо визначення його як необов’язкової функції чи необов’язкових завдань. Це буде зроблено лише в тому випадку, якщо на певному етапі проекту буде визначено, що є час і гроші, щоб виконати ці функції.

Вони також можуть бути спровоковані, якщо станеться зовнішня подія. Якщо клієнти переходять на Windows 8, необхідно виконати наступні завдання ...

Опис функції повинен містити граничний термін для визначення, чи вони будуть виконані.

Вимоги класифіковані на 4 області в програмуванні:

1. Вимоги до бізнесу : Зосереджується на загальних бізнес-цілях та цілях системи
2. Вимоги користувачів : зосереджується на цілях користувача та те, що користувачі повинні зробити, щоб використовувати систему для досягнення бізнес-цілей
3. Функціональні вимоги : які функціональні можливості та завдання виконує система для досягнення бізнес-цілей
4. Нефункціональні вимоги : Які вимоги існують, крім функціональних. Сюди входять середовище, обмеження, інтерфейс, проблеми з технічним обслуговуванням тощо.

Тепер вимоги можуть бути необов’язковими або обов'язковими , залежно від вищевказаних 4 категорій, які я окреслив вище. Необов'язкові вимоги також можуть потрапляти в сферу розглядуваної системи або поза її сферою. Додаткові вимоги є хорошим засобом уникнути Scope Creep і визначення вашої сфери в точних термінах.

Необов'язкові вимоги завжди будуть частиною інженерії програмного забезпечення, оскільки вони допомагають нам визначити сферу застосування та є хорошим засобом уникнути пробігу. Ніколи не можна сказати, що вони суперечать інженерній практиці SDLC. Однак вимоги мають бути пріоритетними та чітко визначеними.

У шаблоні Volere використовується термін "Зал очікування".

... Цей шаблон призначений для використання в якості основи для ваших вимог. У шаблоні передбачено кожен із типів вимог, відповідних сучасним бізнес, науковим та програмним системам. Він забезпечує контрольний список, структуру та простежуваність за вашими вимогами ... Шаблон не залежить від інструменту, і він успішно використовується з Yonix, Requisite, DOORS, Calibre RM, IRqA та іншими популярними інструментами ...

Методи Волера описані в книзі Освоєння процесу вимог Сюзанні Робертсон та Джеймса Робертсона ...

У моєму бізнесі (космічному апараті) їх називають або "цілями", що вказує на те, що вони задокументовані і зусилля будуть витрачені на їхнє задоволення, але система все одно буде вважатися успішною, якщо вони не будуть виконані; "бажання" (не справжнє слово, але ви є), що вказує на те, що хтось їх хоче, і вони намагаються досягти статусу цілей, але ще не прийняті і не задокументовані; або "повзучі вимоги", що є більш зневажливим варіантом бажань, що вказує на речі, які намагаються зайняти ресурси, але які не варті того в проекті, що намагається досягти "достатньо хорошого", коли вони будуть компрометувати або загрожувати досягненню реальних вимог.

Якщо ваші вимоги є пріоритетними , ви можете вважати їх низькими пріоритетними вимогами .

Я дуже здивований, що ніхто не згадував, що це називається "цілями". Кожна компанія, в якій я працював, називала їх так. Вони позначаються вживанням слів "буде" або "повинен" замість "повинен". Іноді вони включаються в брекети, коли говорять про числа. наприклад, Система повинна працювати постійно, не потребуючи уваги оператора протягом 100 {250} годин. Це означає, що вимога, яку необхідно виконати, становить 100 годин, але мета - 250 годин.

Як зауваження, дуже рідко хто-небудь насправді розробляє проект, щоб задовольнити об'єктивні вимоги, якщо тільки не є якийсь стимул.

Термін "Бажання" іноді використовується для необов'язкових вимог. Однак, формальний документ може не підійти.

Я здивований, що всі відповіді стосуються вимог відстеження розвитку проекту. Незважаючи на те, що я розробник, я ніколи не хвилювався над цим термінологією в цьому контексті. Коли я вперше прочитав питання, я припустив, що це стосується специфікації продукту користувача, а не розробки продукту. Наприклад, енциклопедія може перелічити кольоровий принтер як необов'язкові вимоги. Його потрібно, якщо ви хочете повністю скористатися додатком, але необов’язково, якщо ви хочете переглянути екран. Але що робити, якщо у вас був, наприклад, монохромний принтер? Як зрозуміти, чи працює ваш додаток із прихованим обмеженням, що деякі фотографії можуть виглядати не так добре? Або взагалі не друкують? Як інший приклад, як я повинен перевірити перевірку принтера, щоб перевірити, чи є чорнило вимогою або необов'язковою вимогою в багатофункціональному принтері? Іншими словами, чи можу я ще сканувати? Деякі підказки щодо термінології та того, що шукати, будуть вітатися і як розробник / продавець продукту, і як споживач.

Я б назвав їх "додатковими функціями", а не необов'язковими вимогами. Вимоги звучать як щось, що вам доведеться мати , тоді як функції звучать як доповнення до оригінального продукту.