В разработке продукта и оптимизации процессов, требование является особой документально физической или функциональной необходимости, что конкретный дизайн, продукт или цели процесса удовлетворения. Он обычно используется в формальном смысле в инженерном проектировании, включая, например, системную инженерию, разработку программного обеспечения или корпоративную инженерию. Это широкая концепция, которая может относиться к любой необходимой (или иногда желаемой) функции, атрибуту, возможностям, характеристике или качеству системы, чтобы она имела ценность и полезность для потребителя, организации, внутреннего пользователя или другой заинтересованной стороны. Требования могут иметь разный уровень специфичности; например, спецификация требования или «спецификация» требования (часто неточно называемая «спецификацией / спецификациями», но на самом деле существуют разные виды спецификаций) относится к явному, в высшей степени объективному / ясному (и часто количественному) требованию (или иногда набор требований), которым должен удовлетворять материал, дизайн, продукт или услуга.
Набор требований используется в качестве входных данных на этапах проектирования разработки продукта. Требования также являются важным входом в процесс проверки, поскольку тесты должны быть связаны с конкретными требованиями. Требования показывают, какие элементы и функции необходимы для конкретного проекта. Когда используются итерационные методы разработки программного обеспечения или гибкие методы, системные требования постепенно разрабатываются параллельно с проектированием и внедрением. С водопадом модель требование разработано до разработки и реализации.
Термин « требование » используется в сообществе разработчиков программного обеспечения, по крайней мере, с 1960-х годов.
Согласно Руководству по бизнес-анализу Свод знаний® версии 2 от IIBA ( BABOK ), требование:
Это определение основано на IEEE 610.12-1990: Стандартном глоссарии терминологии программной инженерии IEEE.
Можно сказать, что требования относятся к двум областям:
Требования к продукту и процессу тесно взаимосвязаны; можно сказать, что требование к продукту определяет автоматизацию, необходимую для поддержки требований к процессу, в то время как требование к процессу может указывать на действия, необходимые для поддержки требований к продукту. Например, требование максимальной стоимости разработки (требование к процессу) может быть наложено, чтобы помочь достичь требования максимальной продажной цены (требование к продукту); требование, чтобы продукт был поддерживаемым (требование к продукту), часто решается путем введения требований по соблюдению определенных стилей разработки (например, объектно-ориентированное программирование ), руководств по стилю или процесса обзора / проверки (требования к процессу).
Требования обычно классифицируются по типам, созданным на разных этапах развития, при этом таксономия зависит от используемой модели в целом. Например, следующая схема была разработана Международным институтом бизнес-анализа в их своде знаний по бизнес-анализу (см. Также FURPS и Типы требований ).
Характеристики хороших требований по-разному формулируются разными авторами, причем каждый автор обычно подчеркивает характеристики, наиболее подходящие для их общего обсуждения или конкретной области технологии, к которой обращается. Однако обычно признаются следующие характеристики.
Характеристика | Объяснение |
---|---|
Унитарный (Сплоченный) | Требование касается одного и только одного. |
Полный | Требование полностью изложено в одном месте без недостающей информации. |
Последовательный | Требование не противоречит никаким другим требованиям и полностью соответствует всей официальной внешней документации. |
Несопряженный ( атомарный ) | Требование атомарно, т. Е. Не содержит союзов. Например, «Поле почтового индекса должно подтверждать почтовые индексы США и Канады» должно быть записано как два отдельных требования: (1) «Поле почтового индекса должно подтверждать американские почтовые индексы» и (2) «Поле почтового индекса должно подтверждать почтовые индексы Канады. коды ». |
Прослеживаемый | Требование полностью или частично удовлетворяет потребности бизнеса, заявленные заинтересованными сторонами и официально задокументированные. |
Текущий | Требование не устарело с течением времени. |
Однозначный | Требование сформулировано кратко, без использования технического жаргона, аббревиатур (если иное не определено в документе с требованиями) или другого эзотерического словоблудия. Он выражает объективные факты, а не субъективные мнения. Это подлежит одному и только одному толкованию. Избегайте нечетких тем, прилагательных, предлогов, глаголов и субъективных фраз. Избегайте отрицательных и сложных утверждений. |
Укажите важность | Многие требования представляют собой характеристики, определяемые заинтересованными сторонами, отсутствие которых приведет к серьезному или даже фатальному дефициту. Другие представляют собой функции, которые могут быть реализованы, если позволяет время и бюджет. В требовании должен быть указан уровень важности. |
Поддающийся проверке | Реализация требования может быть определена с помощью основных возможных методов: инспекции, демонстрации, тестирования (с использованием инструментов) или анализа (включая подтвержденное моделирование и симуляцию). |
Есть еще много атрибутов, которые необходимо учитывать, которые влияют на качество требований. Если требования подчиняются правилам целостности данных (например), то точность / правильность и достоверность / авторизация также являются достойными атрибутами. Прослеживаемость подтверждает, что набор требований удовлетворяет потребность (не больше и не меньше, чем требуется).
К вышесказанному некоторые добавляют «Внешнее наблюдение», то есть требование определяет характеристики продукта, которые наблюдаются извне или которые испытывает пользователь. Такие сторонники утверждают, что требования, которые определяют внутреннюю архитектуру, дизайн, реализацию или решения по тестированию, вероятно, являются ограничениями и должны быть четко сформулированы в разделе «Ограничения» документа «Требования». Противоположная точка зрения состоит в том, что эта перспектива ошибочна по двум причинам. Во-первых, перспектива не учитывает, что пользовательский опыт может поддерживаться требованиями, не воспринимаемыми пользователем. Например, требование предоставить пользователю геокодированную информацию может поддерживаться требованием интерфейса с внешним сторонним деловым партнером. Интерфейс будет незаметен для пользователя, хотя представление информации, полученной через интерфейс, определенно не будет. Во-вторых, ограничение ограничивает варианты дизайна, тогда как требование определяет характеристики дизайна. В продолжение примера: требование выбора интерфейса веб-службы отличается от ограничения, ограничивающего альтернативные варианты проектирования методами, совместимыми с архитектурой единого входа.
Все требования должны поддаваться проверке. Самый распространенный метод - тестовый. Если это не так, следует использовать другой метод проверки (например, анализ, демонстрация, инспекция или анализ проекта).
Некоторые требования по самой своей структуре не поддаются проверке. К ним относятся требования, которые гласят, что система никогда или всегда не должна проявлять определенное свойство. Для надлежащего тестирования этих требований потребуется бесконечный цикл тестирования. Такие требования должны быть переписаны, чтобы их можно было проверить. Как указано выше, все требования должны поддаваться проверке.
Нефункциональные требования, которые невозможно проверить на уровне программного обеспечения, по-прежнему должны храниться в качестве документации о намерениях клиента. Однако их можно связать с требованиями к процессу, которые определены как практический способ их удовлетворения. Например, нефункциональное требование быть свободным от бэкдоров можно удовлетворить, заменив его требованием процесса использовать парное программирование. Другие нефункциональные требования будут отслеживаться до других компонентов системы и проверяться на этом уровне. Например, надежность системы часто проверяется анализом на системном уровне. Программное обеспечение авионики с его сложными требованиями к безопасности должно соответствовать процессу разработки DO-178B.
Действия, которые приводят к выработке требований к системе или программному обеспечению. Разработка требований может включать в себя технико-экономическое обоснование или этап концептуального анализа проекта и выявление требований (сбор, понимание, анализ и формулирование потребностей заинтересованных сторон ) и анализ требований, анализ (проверка на согласованность и полноту), спецификацию (документирование требования) и валидации (проверка правильности указанных требований).
Требования подвержены проблемам двусмысленности, неполноты и непоследовательности. Было показано, что такие методы, как тщательный осмотр, помогают справиться с этими проблемами. Неоднозначности, неполнота и несоответствия, которые могут быть устранены на этапе требований, обычно требуют на порядок меньших затрат на исправление, чем когда те же проблемы обнаруживаются на более поздних этапах разработки продукта. Анализ требований направлен на решение этих проблем.
Существует инженерный компромисс между требованиями, которые слишком расплывчаты, и требованиями, которые настолько подробны, что они
Гибкие подходы развивались как способ преодоления этих проблем путем определения базовых требований на высоком уровне и детальной проработки деталей точно в срок или в последний ответственный момент.
Требования обычно пишутся как средство связи между различными заинтересованными сторонами. Это означает, что требования должны быть понятны как обычным пользователям, так и разработчикам. Один из распространенных способов задокументировать требование - указать, что система должна делать. Пример: «Подрядчик должен доставить продукт не позднее даты xyz». Другие методы включают варианты использования и пользовательские истории.
Требования обычно меняются со временем. После определения и утверждения требования должны подпадать под контроль изменений. Для многих проектов требования изменяются до того, как система будет завершена. Отчасти это связано со сложностью компьютерного программного обеспечения и тем фактом, что пользователи не знают, чего хотят, прежде чем увидят это. Эта характеристика требований привела к исследованиям и практике управления требованиями.
Существует несколько конкурирующих взглядов на то, что такое требования, и как ими следует управлять и использовать. Двумя ведущими организациями в отрасли являются IEEE и IIBA. Обе эти группы имеют разные, но похожие определения требований.
Многие проекты были успешными при минимальном согласовании требований или без него. Кроме того, некоторые свидетельства указывают на то, что определение требований может снизить креативность и эффективность дизайна. Требования препятствуют творчеству и дизайну, потому что дизайнеры становятся чрезмерно озабоченными предоставленной информацией. В более общем плане некоторые исследования показывают, что требования к программному обеспечению - это иллюзия, созданная неверным представлением проектных решений как требований в ситуациях, когда реальные требования не очевидны.
Между тем, большинство методологий гибкой разработки программного обеспечения ставят под сомнение необходимость предварительного подробного описания требований к программному обеспечению, которые они считают подвижной целью. Вместо этого экстремальное программирование, например, описывает требования неформально, используя истории пользователей (короткие резюме, помещаемые в учетную карточку, объясняющие один аспект того, что должна делать система), и считает своим долгом напрямую попросить разъяснений у клиента. Гибкие методологии пытаются уловить требования в серии автоматизированных приемочных испытаний.
Расползание объема может происходить из-за изменения требований во времени. В управлении требованиями изменение требований разрешено, но если они не отслеживаются должным образом или предшествующие шаги (бизнес-цели, затем требования пользователей) не регулируются дополнительным надзором или не рассматриваются как затраты и потенциальный сбой программы, то изменения требований легко и, вероятно, произойдут. Изменения требований легко происходят быстрее, чем разработчики могут производить работу, и в результате усилия откатываются назад.
Существует несколько таксономий требований в зависимости от того, в какой структуре они работают. (Например, заявленные стандарты IEEE, Vice IIBA или подходы Министерства обороны США). Различный язык и процессы в разных местах или обычная речь могут вызвать путаницу и отклонение от желаемого процесса.
Процесс, которым управляют люди, подвержен человеческим недостаткам в управлении, когда удобство, желания или политика могут привести к исключениям или прямому подрыву процесса и отклонениям от того, как этот процесс должен протекать в учебнике. Примеры включают:
В рамках процесса Министерства обороны США некоторые исторические примеры проблем с требованиями: