Анализ требований

В этой статье есть несколько проблем. Помогите улучшить ее или обсудите эти проблемы на странице обсуждения . ( Узнайте, как и когда удалять эти сообщения ) This article needs additional citations for verification. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. Find sources: "Requirements analysis" – news · newspapers · books · scholar · JSTOR (December 2011) (Learn how and when to remove this message) This article is in list format but may read better as prose. You can help by converting this article, if appropriate. Editing help is available. (July 2022) (Learn how and when to remove this message)

В системной инженерии и программной инженерии анализ требований фокусируется на задачах, которые определяют потребности или условия для удовлетворения нового или измененного продукта или проекта, принимая во внимание возможные противоречивые требования различных заинтересованных сторон , анализируя, документируя, проверяя и управляя требованиями к программному обеспечению или системе . ^[2]

Анализ требований имеет решающее значение для успеха или неудачи системного или программного проекта . ^[3] Требования должны быть документированы, выполнимы, измеримы, проверяемы, ^[4] прослеживаемы, ^[4] связаны с выявленными бизнес-потребностями или возможностями и определены на уровне детализации, достаточном для проектирования системы .

Концептуально анализ требований включает три типа деятельности: ^{[ необходима ссылка ]}

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

Анализ требований может быть длительным и утомительным процессом, в ходе которого задействованы многие тонкие психологические навыки. Новые системы изменяют среду и отношения между людьми, поэтому важно определить всех заинтересованных лиц, учесть все их потребности и убедиться, что они понимают последствия новых систем. Аналитики могут использовать несколько методов для выявления требований у клиента. Они могут включать разработку сценариев (представленных в виде пользовательских историй в гибких методах ), идентификацию вариантов использования , использование наблюдения за рабочим местом или этнографии , проведение интервью или фокус-групп (более точно названных в этом контексте семинарами по требованиям или сессиями обзора требований) и создание списков требований. Прототипирование может использоваться для разработки примера системы, который может быть продемонстрирован заинтересованным лицам. При необходимости аналитик будет использовать комбинацию этих методов для установления точных требований заинтересованных лиц, чтобы была создана система, отвечающая потребностям бизнеса. ^{[5] [6]} Качество требований можно улучшить с помощью этих и других методов:

• Визуализация. Использование инструментов, способствующих лучшему пониманию желаемого конечного продукта, таких как визуализация и моделирование.
• Последовательное использование шаблонов. Создание последовательного набора моделей и шаблонов для документирования требований.
• Документирование зависимостей . Документирование зависимостей и взаимосвязей между требованиями, а также любых предположений и объединений.

This section does not cite any sources. Please help improve this section by adding citations to reliable sources. Unsourced material may be challenged and removed. (October 2009) (Learn how and when to remove this message)

См. Анализ заинтересованных сторон для обсуждения людей или организаций (юридических лиц, таких как компании и органы по стандартизации), которые имеют обоснованный интерес к системе. Они могут быть затронуты ею как напрямую, так и косвенно.

Важным новым акцентом в 1990-х годах стало внимание к выявлению заинтересованных сторон . Все больше осознается, что заинтересованные стороны не ограничиваются организацией, нанимающей аналитика. Другие заинтересованные стороны включают:

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

Требования часто имеют кросс-функциональные последствия, которые неизвестны отдельным заинтересованным сторонам и часто упускаются или не полностью определяются во время интервью с заинтересованными сторонами. Эти кросс-функциональные последствия могут быть выявлены путем проведения сессий JRD в контролируемой среде, проводимых обученным фасилитатором (бизнес-аналитиком), где заинтересованные стороны участвуют в обсуждениях для выявления требований, анализа их деталей и раскрытия кросс-функциональных последствий. Для документирования обсуждения должен присутствовать специальный секретарь, освобождая бизнес-аналитика для ведения обсуждения в направлении, которое генерирует соответствующие требования, отвечающие цели сессии.

Сессии JRD аналогичны сессиям Joint Application Design Sessions. В первом случае сессии выявляют требования, которые направляют проектирование, тогда как во втором выявляют конкретные особенности дизайна, которые должны быть реализованы для удовлетворения выявленных требований.

Одним из традиционных способов документирования требований были списки требований в стиле контракта. В сложной системе такие списки требований могут занимать сотни страниц.

Подходящей метафорой был бы чрезвычайно длинный список покупок. Такие списки очень непопулярны в современном анализе; поскольку они оказались впечатляюще неэффективными в достижении своих целей ^{[ необходима цитата ]} ; но они все еще встречаются по сей день.

• Предоставляет контрольный список требований.
• Предоставьте договор между спонсором(ами) проекта и разработчиками.
• Для большой системы можно предоставить высокоуровневое описание, из которого можно вывести требования более низкого уровня.

• Такие списки могут занимать сотни страниц. Они не предназначены для использования в качестве удобного для чтения описания желаемого приложения.
• Такие списки требований абстрагируют все требования, поэтому контекста мало. Бизнес-аналитик может включить контекст для требований в сопроводительную проектную документацию.
  • Эта абстракция не предназначена для описания того, как требования соотносятся или работают вместе.
  • Список может не отражать взаимосвязи и зависимости между требованиями. Хотя список позволяет легко расставить приоритеты для каждого элемента, удаление одного элемента из контекста может сделать весь вариант использования или бизнес-требование бесполезным.
  • Список не отменяет необходимости тщательного рассмотрения требований с заинтересованными сторонами для получения более четкого понимания последствий для проектирования желаемой системы/приложения.
• Простое создание списка не гарантирует его полноту. Бизнес-аналитик должен приложить добросовестные усилия для обнаружения и сбора в значительной степени всеобъемлющего списка и полагаться на заинтересованные стороны, чтобы указать на недостающие требования.
• Эти списки могут создать ложное ощущение взаимопонимания между заинтересованными сторонами и разработчиками; бизнес-аналитики играют решающую роль в процессе перевода.
• Почти невозможно раскрыть все функциональные требования до начала процесса разработки и тестирования. Если эти списки рассматривать как неизменный контракт, то требования, которые возникают в процессе разработки, могут сгенерировать спорный запрос на изменение.

В качестве альтернативы спискам требований Agile Software Development использует пользовательские истории для формулирования требований на повседневном языке.

Лучшие практики принимают составленный список требований просто как подсказки и постоянно спрашивают «почему?», пока не будут обнаружены фактические бизнес-цели. Затем заинтересованные стороны и разработчики могут разработать тесты для измерения того, какой уровень каждой цели был достигнут на данный момент. Такие цели меняются медленнее, чем длинный список конкретных, но неизмеренных требований. После того, как будет установлен небольшой набор критических, измеряемых целей, быстрое прототипирование и короткие итеративные фазы разработки могут приступить к предоставлению фактической ценности для заинтересованных сторон задолго до того, как проект будет завершен наполовину.

Прототип — это компьютерная программа, которая демонстрирует часть свойств другой компьютерной программы, позволяя пользователям визуализировать приложение, которое еще не было создано. Популярная форма прототипа — это макет , который помогает будущим пользователям и другим заинтересованным лицам получить представление о том, как будет выглядеть система. Прототипы облегчают принятие решений по проектированию, поскольку аспекты приложения можно увидеть и поделиться ими до того, как приложение будет создано. Значительные улучшения в общении между пользователями и разработчиками часто наблюдались с введением прототипов. Ранние представления приложений приводили к меньшему количеству изменений в дальнейшем и, следовательно, значительно сокращали общие затраты. ^{[ необходима цитата ]}

Прототипы могут быть плоскими диаграммами (часто называемыми каркасами ) или рабочими приложениями, использующими синтезированную функциональность. Каркасы создаются в различных графических дизайнерских документах и ​​часто удаляют все цвета из дизайна (т. е. используют палитру оттенков серого) в случаях, когда ожидается, что окончательное программное обеспечение будет иметь графический дизайн , примененный к нему. Это помогает избежать путаницы относительно того, представляет ли прототип окончательный визуальный вид и ощущение приложения. ^{[ необходима цитата ]}

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

Варианты использования — это обманчиво простые инструменты для описания поведения программного обеспечения или систем. Вариант использования содержит текстовое описание того, как пользователи должны работать с программным обеспечением или системой. Варианты использования не должны описывать внутреннюю работу системы и не должны объяснять, как эта система будет реализована. Вместо этого они показывают шаги, необходимые для выполнения задачи без последовательных предположений.

This section needs expansion. You can help by adding to it. (February 2018)

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

Требования классифицируются несколькими способами. Ниже приведены общие классификации требований, которые относятся к техническому управлению: ^[1]

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

Заявления о фактах и ​​предположения, которые определяют ожидания системы с точки зрения целей миссии, среды, ограничений и мер эффективности и пригодности (MOE/MOS). Клиенты — это те, кто выполняет восемь основных функций системной инженерии, с особым акцентом на оператора как ключевого клиента. Эксплуатационные требования будут определять основную потребность и, как минимум, отвечать на вопросы, поставленные в следующем списке: ^[1]

• Оперативное распространение или развертывание : где будет использоваться система?
• Профиль или сценарий миссии : как система выполнит поставленную задачу?
• Производительность и связанные с ней параметры : Каковы критические параметры системы для выполнения миссии?
• Среды использования : как будут использоваться различные компоненты системы?
• Требования к эффективности : Насколько эффективной или действенной должна быть система при выполнении своей миссии?
• Жизненный цикл эксплуатации : как долго система будет использоваться пользователем?
• Окружающая среда : В каких условиях система будет работать эффективно?

Архитектурные требования объясняют , что должно быть сделано, путем определения необходимой системной архитектуры системы .

Поведенческие требования объясняют, что необходимо сделать, определяя необходимое поведение системы.

Функциональные требования объясняют, что должно быть сделано, определяя необходимую задачу, действие или деятельность, которые должны быть выполнены. Анализ функциональных требований будет использоваться в качестве функций верхнего уровня для функционального анализа. ^[1]

Нефункциональные требования — это требования, определяющие критерии, которые можно использовать для оценки работы системы, а не конкретные поведения.

Степень, в которой миссия или функция должны быть выполнены; обычно измеряется с точки зрения количества, качества, охвата, своевременности или готовности. В ходе анализа требований требования к производительности (насколько хорошо это должно быть сделано) будут интерактивно разрабатываться по всем выявленным функциям на основе факторов жизненного цикла системы; и характеризоваться с точки зрения степени определенности в их оценке, степени критичности для успеха системы и их связи с другими требованиями. ^[1]

Требования к продуктам «создать для», «кодировать для» и «купить для», а также требования к процессам «как выполнять» выражены в пакетах технических данных и технических руководствах. ^[1]

Требования, которые подразумеваются или трансформируются из требований более высокого уровня. Например, требование большой дальности или высокой скорости может привести к проектному требованию малого веса. ^[1]

Требование устанавливается путем деления или иного распределения требования высокого уровня на несколько требований более низкого уровня. Пример: 100-фунтовый элемент, состоящий из двух подсистем, может привести к требованиям веса в 70 фунтов и 30 фунтов для двух элементов более низкого уровня. ^[1]

К известным моделям категоризации требований относятся FURPS и FURPS+, разработанные в Hewlett-Packard .

Стив Макконнелл в своей книге «Быстрая разработка » подробно описывает ряд способов, с помощью которых пользователи могут препятствовать сбору требований:

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

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

Возможные проблемы, возникающие по вине инженеров и разработчиков при анализе требований:

• Естественная склонность к написанию кода может привести к началу реализации до завершения анализа требований, что может привести к необходимости внесения изменений в код для соответствия фактическим требованиям, как только они станут известны.
• Технический персонал и конечные пользователи могут иметь разный словарный запас. Следовательно, они могут ошибочно полагать, что находятся в полном согласии, пока не будет поставлен готовый продукт.
• Инженеры и разработчики могут попытаться подогнать требования под существующую систему или модель, а не разрабатывать систему, отвечающую конкретным потребностям клиента.

Одной из попыток решения проблем коммуникации было привлечение специалистов по бизнес- или системному анализу.

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

Кроме того, на рынок вышел новый класс инструментов моделирования или определения приложений. Эти инструменты предназначены для преодоления разрыва в коммуникации между бизнес-пользователями и ИТ-организацией, а также для того, чтобы приложения могли быть «тестированы на рынке» до того, как будет создан какой-либо код. Лучшие из этих инструментов предлагают:

• электронные доски для зарисовок потоков приложений и тестирования альтернатив
• способность фиксировать бизнес-логику и потребности в данных
• возможность создания высокоточных прототипов, максимально точно имитирующих конечное приложение
• интерактивность
• возможность добавлять контекстные требования и другие комментарии
• возможность удаленным и распределенным пользователям запускать и взаимодействовать с симуляцией

^[1]

На Викискладе есть медиафайлы по теме Анализ требований .

• Рецензируемая энциклопедия по проектированию и анализу требований
• Процесс определения требований заинтересованных сторон в Университете оборонных закупок --- Процесс определения требований заинтересованных сторон в Wayback Machine (архивировано 23 декабря 2015 г.)
• Руководство по документу «Системные требования MIL-HDBK 520»