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

12

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

Арам Кочарян
источник
9
Я предполагаю, что он имеет в виду, что что-то не может быть обязательным (как в «требовании») и необязательным (как в «не обязательном»)
scrwtp
2
Это действительно относится к английскому языку. И я бы просто назвал их «варианты».
Blrfl
13
@Blrfl Это не относится к английскому языку. В английском языке выражение «необязательные требования» противоречиво. Тем не менее, он имеет широко распространенное значение в разработке программного обеспечения, и существуют альтернативные способы выражения этой концепции в контексте программного проекта. Не имеет смысла иметь его где-либо, но здесь.
Томас Оуэнс
3
@ThomasOwens: я не согласен. Любая область, где задания имеют требования, может столкнуться с этой проблемой, что сделает это вопросом управления проектом. Это также оксюморон, что делает его хорошим кормом для английского языка, и в первой теме первого часто задаваемого вопроса там говорится, что выбор слова - по теме. Но одень себя.
Blrfl
5
«Вещи, которые не будут построены» - это то, что означает во многих проектах.

Ответы:

13

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

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

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

Томас Оуэнс
источник
1
Связанным термином является «случай изменения», который является требованием, которое ожидается в определенный момент в будущем, но сейчас не входит в сферу применения. Собирая изменения, вы можете попытаться избежать действий в текущем проекте, которые усложняют изменения. Делая это, вы должны следить за YAGNI, хотя.
Крис C
ИМХО, «необязательное требование» подразумевает необязательное в настоящем времени и требование в будущем времени, которое также может читать необязательное потенциальное требование. В любом случае, я согласен с тем, что выход за рамки допустимого является более подходящим в бизнес-случае, когда необходимо управлять ожиданиями клиентов.
Эван Плейс,
25

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

Идиоты
источник
2
С точки зрения разработки требований, «приятно иметь функции» по-прежнему необходимо отражать в качестве требования (в спецификации, в пользовательской истории, в качестве приемочных тестов - однако ваш процесс требует, чтобы требования были собраны) и отслеживать в течение всего срока службы. проэкт.
Томас Оуэнс
11

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

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

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

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


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

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

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

    абстрактный

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

комар
источник
Я даже не знал, что это RFC. Я не удивлен, что что-то подобное существует, хотя, как стандарт IEEE, стандарт ISO, RFC или какой-либо другой подобный опубликованный документ.
Томас Оуэнс
Этот документ кажется слишком конкретным, чтобы его можно было широко применять в качестве руководства для требований к программному обеспечению. Он не озаглавлен «Ключевые слова для требований», он озаглавлен «Ключевые слова для требований в RFC», а в Директиве 6 он намеренно ограничивает свою сферу применения.
Роберт Харви
1
@RobertHarvey, хорошо, я хотел ответить на вопрос о том, что нужно искать лучшее слово, чтобы заменить устоявшийся профессиональный термин на четко определенную и задокументированную семантику только потому, что они считают, что это не идеальный английский. Что касается того, чтобы быть слишком конкретным или нет, это был бы совсем другой вопрос, вы не думаете? Я, например, могу представить множество случаев, когда я предпочел бы категоризацию в стиле MoSCoW .
комнат
@gnat, ему не нужен глагол. На этот пост еще не ответили Как лучше называть «необязательные требования»?
Пейсер
7

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

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

PaulHurleyuk
источник
4

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

Майкл Даррант
источник
2

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

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

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

mhoran_psprep
источник
1

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

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

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

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

Maxood
источник
1
Вопрос требует другого термина для «необязательных требований», а не для классификации требований.
Яннис
1
Если бы он знал классификацию, он никогда бы не сказал, что дополнительные требования противоречат друг другу в разработке программного обеспечения. :)
Maxood
1
хорошие описания, но я все еще немного раздражен этой фразой - либо что-то требуется, либо нет. Я думаю, что мы превратили «требование» в отдельную сущность, что означает «формальная потребность клиента» ...
Арам Кочарян
@Maxood Хммм? Термин противоречив, а не концепция, вопрос обсуждает термин. Есть ли у вас какие-либо ссылки на то, что этот термин является частью какой-либо формальной (или широко принятой) модели требований? Я знаю, что это обычное дело, но такие вещи, как «Необязательные требования всегда будут частью разработки программного обеспечения» без единой ссылки, на самом деле не моя чашка чая.
Яннис
@ Yannis Rizos Когда я сказал «Дополнительные требования всегда будут частью разработки программного обеспечения», я имел в виду это в концептуальном контексте. Поскольку инжиниринг - это выработка эффективного решения в рамках бюджета с учетом противоречивых требований. Кроме того, спрашивающий никогда не упоминает необязательное требование в качестве термина здесь, в вопросе, и я тоже
Maxood
1

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

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

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

Дэнни Варод
источник
0

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

Марк Адлер
источник
0

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

calum_b
источник
Я думаю, что «нулевой приоритет» может быть ближе к «необязательному».
Пейсер
0

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

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

Замочить
источник
0

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

Крейг Шварц
источник
0

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

g1cmz
источник
Хм, так что лучше сказать "необязательные требования"?
Пейсер
0

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

Billjk
источник