Как лучше сформулировать необязательное требование в разработке программного обеспечения? Фраза противоречива. Я использовал «Неосновные требования» в предыдущих проектах.
terminology
requirements
Арам Кочарян
источник
источник
Ответы:
Можно использовать термин «вне рамок требования». Это означает, что требование было зафиксировано в вашем процессе и отслеживается, но было определено, что это требование выходит за рамки текущей области применения системы по ряду причин, таких как бюджет, график, время, или осуществимость.
Однако фраза «необязательное требование» обычно используется для обозначения чего-либо, что находится в области применения, но не обязательно требуется системой. Это мера приоритета требования. По моему опыту, требования часто расставляются по приоритетам как обязательные, желательные или необязательные (хотя есть и другие схемы). Чтобы проект считался завершенным и полностью функциональным, все обязательные требования должны быть выполнены. При наличии достаточных ресурсов желательные требования будут реализованы далее. Наконец, все, что считается необязательным, будет включено.
Я считаю, что путаница происходит от термина «требование». В английском языке требование - это «вещь, которая необходима» или «обязательное, обязательное или необходимое условие». Однако в программной инженерии термин требование является просто документированной характеристикой программной системы. Понятие необязательного и обязательного описания приоритета документированной характеристики программного комплекса.
источник
Мы называем их «приятными в использовании» функциями, а не требованиями.
источник
Для документации по требованиям к программному обеспечению формулировка « Необязательные требования» вполне приемлема, если вы используете этот термин в соответствии с RFC 2119. Ключевые слова для обозначения уровней требований, т. Е. Для обозначения элементов, которые действительно являются необязательными.
Когда ваш текст спецификации подразумевает глагол вместо прилагательного, используйте «MAY» вместо «OPTIONAL».
Так как он небольшой и его легко читать, текст RFC полностью цитируется ниже:
Не повредит, если ваша документация ссылается на RFC как источник определений:
источник
Я ценю, что это не ответ на ваш вопрос, но в моем мире это все еще требование, даже если по какой-то причине вы не собираетесь его выполнять.
Мне нравится подход MoSCoW (должен иметь, должен иметь, мог бы иметь, не будет на этот раз) к категоризации требований с пользователями, наряду с другими факторами (в моем регулируемом мире требования могут быть критическими или некритическими, и многие спор разгорается из-за необязательных, но критических требований.)
источник
Лучшее слово для необязательного требования - « Рекомендация »
источник
Как насчет определения его в качестве дополнительной функции или дополнительных задач. Это будет сделано только в том случае, если в определенный момент в проекте будет определено, что есть время и деньги для выполнения этих функций.
Они также могут быть вызваны, если происходит внешнее событие. Если клиенты переходят на Windows 8, необходимо выполнить следующие задачи ...
Описание функции должно включать крайний срок для определения того, будут ли они выполнены.
источник
Требования подразделяются на 4 области в программной инженерии:
Теперь требования могут быть необязательными или обязательными , в зависимости от вышеупомянутых 4 категорий, которые я обрисовал выше. Необязательные требования также могут попадать в сферу рассматриваемой системы или выходить за ее рамки. Необязательные требования - это хороший способ избежать ползучести прицела и точного определения объема.
Необязательные требования всегда будут частью разработки программного обеспечения, поскольку они помогают нам определить область применения и являются хорошим средством для предотвращения Scope Creep. Нельзя сказать, что они противоречат инженерным практикам SDLC. Однако требования должны быть приоритетными и четко определенными.
источник
В шаблоне Volere используется термин «Зал ожидания».
источник
В моем бизнесе (космические корабли) они называются либо «целями», указывая на то, что они задокументированы, и усилия будут потрачены на их достижение, но система все равно будет считаться успешной, если они не достигнуты; «желания» (не настоящее слово, но вы здесь), указывающие, что кто-то хочет их, и они пытаются достичь статуса целей, но еще не приняты или не задокументированы; или «ползучие требования», которые представляют собой более уничижительную версию желаний, указывающую на вещи, которые пытаются занять ресурсы, но которые не стоят этого в проекте, пытающемся достичь «достаточно хороших» результатов, которые могут поставить под угрозу или поставить под угрозу достижение реальных требований.
источник
Если ваши требования имеют приоритет , вы можете считать их приоритетными .
источник
Я весьма удивлен, что никто не упомянул, что они называются «целями». Каждая компания, в которой я работал, назвала их так. Они обозначаются использованием слов «воля» или «должен» вместо «должен». Иногда они включаются в фигурные скобки, когда говорят о числах. Например, система должна работать непрерывно без необходимости вмешательства оператора в течение 100 {250} часов. Это означает, что требование, которое должно быть выполнено, составляет 100 часов, а цель - 250 часов.
В качестве дополнительного примечания, очень редко кто-либо действительно разрабатывает дизайн, чтобы удовлетворить объективное требование, если только не используется какой-либо стимул.
источник
Термин «Желание» иногда используется для необязательных требований. Однако это может не подходить для официального документа.
источник
Я удивлен, что все ответы касаются требований к отслеживанию при разработке проекта. Несмотря на то, что я являюсь разработчиком, я никогда не беспокоился об этой терминологии в этом контексте. Когда я впервые прочитал вопрос, я предположил, что он связан со спецификацией продукта пользователя, а не с разработкой продукта. Например, энциклопедия может перечислить цветной принтер в качестве необязательного требования. Это необходимо, если вы хотите в полной мере использовать приложение, но необязательно, если вы хотите просматривать экран. Но что, если у вас есть, например, монохромный принтер? Как понять, работает ли ваше приложение с явным ограничением, что некоторые фотографии могут выглядеть не так хорошо? Или вообще не печатать? Как я должен проверить обзор принтера, чтобы проверить, является ли чернила требованием или дополнительным требованием требования в многофункциональном принтере? Другими словами, я все еще могу сканировать? Некоторые советы по терминологии и тому, что искать, приветствуются как разработчик / продавец продукта, так и потребитель.
источник
Я бы назвал их «дополнительными функциями», а не дополнительными требованиями. Требования звучат как то, что вам нужно , а функции - как дополнение к оригинальному продукту.
источник