Лучшее слово для необязательных требований? [закрыто]

Как лучше сформулировать необязательное требование в разработке программного обеспечения? Фраза противоречива. Я использовал «Неосновные требования» в предыдущих проектах.

Можно использовать термин «вне рамок требования». Это означает, что требование было зафиксировано в вашем процессе и отслеживается, но было определено, что это требование выходит за рамки текущей области применения системы по ряду причин, таких как бюджет, график, время, или осуществимость.

Однако фраза «необязательное требование» обычно используется для обозначения чего-либо, что находится в области применения, но не обязательно требуется системой. Это мера приоритета требования. По моему опыту, требования часто расставляются по приоритетам как обязательные, желательные или необязательные (хотя есть и другие схемы). Чтобы проект считался завершенным и полностью функциональным, все обязательные требования должны быть выполнены. При наличии достаточных ресурсов желательные требования будут реализованы далее. Наконец, все, что считается необязательным, будет включено.

Я считаю, что путаница происходит от термина «требование». В английском языке требование - это «вещь, которая необходима» или «обязательное, обязательное или необходимое условие». Однако в программной инженерии термин требование является просто документированной характеристикой программной системы. Понятие необязательного и обязательного описания приоритета документированной характеристики программного комплекса.

Мы называем их «приятными в использовании» функциями, а не требованиями.

Для документации по требованиям к программному обеспечению формулировка « Необязательные требования» вполне приемлема, если вы используете этот термин в соответствии с RFC 2119. Ключевые слова для обозначения уровней требований, т. Е. Для обозначения элементов, которые действительно являются необязательными.

Когда ваш текст спецификации подразумевает глагол вместо прилагательного, используйте «MAY» вместо «OPTIONAL».

Так как он небольшой и его легко читать, текст RFC полностью цитируется ниже:

    Сетевая рабочая группа С. Браднера
    Запрос комментариев: 2119 Гарвардский университет
    ППГ: 14 марта 1997 г.
    Категория: Лучшая текущая практика


            Ключевые слова для использования в RFC для указания уровней требований

    Статус этой заметки

       В этом документе указывается наилучшая текущая практика Интернета для
       Интернет-сообщество, и просит обсуждения и предложения для
       улучшения. Распространение этой заметки не ограничено.

    абстрактный

       Во многих стандартах отслеживания документов несколько слов используются для обозначения
       требования в спецификации. Эти слова часто
       капитализируются. Этот документ определяет эти слова, как они должны быть
       истолковано в документах IETF. Авторы, которые следуют этим рекомендациям
       следует включить эту фразу в начале их документа:

          Ключевые слова "ДОЛЖЕН", "НЕ ДОЛЖЕН", "ТРЕБУЕТСЯ", "ДОЛЖЕН", "ДОЛЖЕН"
          НЕ »,« СЛЕДУЕТ »,« НЕ СЛЕДУЕТ »,« РЕКОМЕНДУЕТСЯ »,« МОЖЕТ »и
          «ДОПОЛНИТЕЛЬНО» в этом документе следует толковать, как описано в
          RFC 2119.

       Обратите внимание, что сила этих слов модифицируется требованием
       уровень документа, в котором они используются.

    1. ДОЛЖНО Это слово или термины «ОБЯЗАТЕЛЬНО» или «ДОЛЖНО» означают, что
       определение является абсолютным требованием спецификации.

    2. НЕ ДОЛЖНА. Эта фраза или фраза «НЕ ДОЛЖНЫ» означают, что
       определение является абсолютным запретом спецификации.

    3. СЛЕДУЕТ, чтобы это слово или прилагательное «РЕКОМЕНДОВАНО» означало, что
       могут существовать веские причины в определенных обстоятельствах игнорировать
       конкретный пункт, но все последствия должны быть поняты и
       тщательно взвесить, прежде чем выбрать другой курс.

    4. НЕ ДОЛЖНА Эта фраза или фраза «НЕ РЕКОМЕНДУЕТСЯ» означают, что
       в определенных обстоятельствах могут существовать веские причины
       конкретное поведение приемлемо или даже полезно, но полное
       последствия должны быть поняты, и дело тщательно взвесить
       перед реализацией любого поведения, описанного с помощью этого ярлыка.

    5. МОЖЕТ Это слово, или прилагательное «ДОПОЛНИТЕЛЬНО», означает, что предмет
       действительно необязательно. Один продавец может включить товар, потому что
       конкретный рынок требует этого или потому что продавец чувствует, что
       это улучшает продукт, в то время как другой поставщик может опустить тот же элемент.
       Реализация, которая не включает конкретную опцию, ДОЛЖНА быть
       готовы взаимодействовать с другой реализацией, которая делает
       включить опцию, хотя, возможно, с ограниченной функциональностью. в
       В том же духе реализация, которая включает в себя конкретный вариант
       ДОЛЖЕН быть готов взаимодействовать с другой реализацией, которая
       не включает опцию (кроме, конечно, для функции
       вариант обеспечивает.)

    6. Руководство по использованию этих императивов

       Императивы типа, определенного в этой записке, должны использоваться с осторожностью
       и экономно. В частности, они ДОЛЖНЫ использоваться только там, где это
       фактически требуется для взаимодействия или для ограничения поведения, которое имеет
       возможность причинения вреда (например, ограничение повторных передач)
       Например, они не должны использоваться, чтобы попытаться навязать определенный метод
       на разработчиках, где метод не требуется для совместимости.

    7. Вопросы безопасности

       Эти термины часто используются для определения поведения с безопасностью
       последствия. Влияние на безопасность отказа от реализации ДОЛЖНО или
       СЛЕДУЕТ, или делать что-то, о чем говорится в спецификации, НЕ ДОЛЖНО или СЛЕДУЕТ
       НЕ может быть сделано, может быть очень тонким. Авторы документа должны занять время
       разработать последствия для безопасности не следуя
       рекомендации или требования, так как большинство разработчиков не будет иметь
       был полезен опыт и обсуждения, которые произвели
       Спецификация.

    8. Благодарности

       Определения этих терминов представляют собой смесь определений, принятых
       из ряда RFC. Кроме того, предложения были
       включены из ряда людей, включая Роберта Уллмана, Томаса
       Нартен, Нил МакБарнетт и Роберт Элз.

Не повредит, если ваша документация ссылается на RFC как источник определений:

В этом документе используются определения, основанные на определениях, указанных в RFC 2119 .

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

Мне нравится подход MoSCoW (должен иметь, должен иметь, мог бы иметь, не будет на этот раз) к категоризации требований с пользователями, наряду с другими факторами (в моем регулируемом мире требования могут быть критическими или некритическими, и многие спор разгорается из-за необязательных, но критических требований.)

Лучшее слово для необязательного требования - « Рекомендация »

Как насчет определения его в качестве дополнительной функции или дополнительных задач. Это будет сделано только в том случае, если в определенный момент в проекте будет определено, что есть время и деньги для выполнения этих функций.

Они также могут быть вызваны, если происходит внешнее событие. Если клиенты переходят на Windows 8, необходимо выполнить следующие задачи ...

Описание функции должно включать крайний срок для определения того, будут ли они выполнены.

Требования подразделяются на 4 области в программной инженерии:

1. Бизнес-требования : ориентируется на общие бизнес-цели и задачи системы
2. Пользовательские требования : фокусируется на целях пользователя и на том, что пользователи должны делать, чтобы использовать систему для достижения бизнес-целей
3. Функциональные требования : какие функции и задачи должна выполнять система для достижения бизнес-целей
4. Нефункциональные требования . Какие требования существуют, кроме функциональных? Это включает в себя среду, ограничения, интерфейс, вопросы обслуживания и т. Д.

Теперь требования могут быть необязательными или обязательными , в зависимости от вышеупомянутых 4 категорий, которые я обрисовал выше. Необязательные требования также могут попадать в сферу рассматриваемой системы или выходить за ее рамки. Необязательные требования - это хороший способ избежать ползучести прицела и точного определения объема.

Необязательные требования всегда будут частью разработки программного обеспечения, поскольку они помогают нам определить область применения и являются хорошим средством для предотвращения Scope Creep. Нельзя сказать, что они противоречат инженерным практикам SDLC. Однако требования должны быть приоритетными и четко определенными.

В шаблоне Volere используется термин «Зал ожидания».

... Этот шаблон предназначен для использования в качестве основы для ваших требований спецификаций. Шаблон обеспечивает для каждого из типов требований, подходящих для современных деловых, научных и программных систем. Он предоставляет контрольный список, структуру и прослеживаемость для ваших требований ... Шаблон не зависит от инструмента и успешно используется с Yonix, Requisite, DOORS, Caliber RM, IRqA и другими популярными инструментами ...

Техники Волера описаны в книге Сьюзен Робертсон и Джеймс Робертсон « Освоение процесса требований» ...

В моем бизнесе (космические корабли) они называются либо «целями», указывая на то, что они задокументированы, и усилия будут потрачены на их достижение, но система все равно будет считаться успешной, если они не достигнуты; «желания» (не настоящее слово, но вы здесь), указывающие, что кто-то хочет их, и они пытаются достичь статуса целей, но еще не приняты или не задокументированы; или «ползучие требования», которые представляют собой более уничижительную версию желаний, указывающую на вещи, которые пытаются занять ресурсы, но которые не стоят этого в проекте, пытающемся достичь «достаточно хороших» результатов, которые могут поставить под угрозу или поставить под угрозу достижение реальных требований.

Если ваши требования имеют приоритет , вы можете считать их приоритетными .

Я весьма удивлен, что никто не упомянул, что они называются «целями». Каждая компания, в которой я работал, назвала их так. Они обозначаются использованием слов «воля» или «должен» вместо «должен». Иногда они включаются в фигурные скобки, когда говорят о числах. Например, система должна работать непрерывно без необходимости вмешательства оператора в течение 100 {250} часов. Это означает, что требование, которое должно быть выполнено, составляет 100 часов, а цель - 250 часов.

В качестве дополнительного примечания, очень редко кто-либо действительно разрабатывает дизайн, чтобы удовлетворить объективное требование, если только не используется какой-либо стимул.

Термин «Желание» иногда используется для необязательных требований. Однако это может не подходить для официального документа.

Я удивлен, что все ответы касаются требований к отслеживанию при разработке проекта. Несмотря на то, что я являюсь разработчиком, я никогда не беспокоился об этой терминологии в этом контексте. Когда я впервые прочитал вопрос, я предположил, что он связан со спецификацией продукта пользователя, а не с разработкой продукта. Например, энциклопедия может перечислить цветной принтер в качестве необязательного требования. Это необходимо, если вы хотите в полной мере использовать приложение, но необязательно, если вы хотите просматривать экран. Но что, если у вас есть, например, монохромный принтер? Как понять, работает ли ваше приложение с явным ограничением, что некоторые фотографии могут выглядеть не так хорошо? Или вообще не печатать? Как я должен проверить обзор принтера, чтобы проверить, является ли чернила требованием или дополнительным требованием требования в многофункциональном принтере? Другими словами, я все еще могу сканировать? Некоторые советы по терминологии и тому, что искать, приветствуются как разработчик / продавец продукта, так и потребитель.

Я бы назвал их «дополнительными функциями», а не дополнительными требованиями. Требования звучат как то, что вам нужно , а функции - как дополнение к оригинальному продукту.