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

Более широкий охват этой темы см. в разделе «Инженерия требований» .

на Взгляд системной инженерии анализ требований

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

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

Обзор

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

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

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

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

Темы анализа требований

Идентификация

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

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

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

совместной разработке требований (

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

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

в стиле

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

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

Сильные стороны

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

Слабые стороны

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

Альтернатива спискам требований

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

Измеримые цели

Основная статья: Моделирование цели

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

Прототипы

Основная статья: Прототипирование программного обеспечения

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

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

Варианты использования

Основная статья: Вариант использования

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

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

Спецификация требований

Основная статья: Спецификация требований

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

Виды требований

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

Бизнес-требования

Основная статья: Бизнес-требования

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

Требования заказчика

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

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

Архитектурные требования

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

Структурные

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

Поведенческие

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

Функциональные требования

Основная статья: Функциональные требования

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

Нефункциональные требования

Основная статья: Нефункциональные требования

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

Требования к производительности

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

Требования к дизайну

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

Производные требования

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

Распределенные требования

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

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

Проблемы анализа требований

Проблемы

Стив МакКоннелл в своей книге Rapid Development подробно описывает ряд способов, которыми пользователи могут препятствовать сбору требований:

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

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

Проблемы инженера/разработчика

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

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

Попытки решения

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

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

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

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

См. также

• Бизнес-анализ
• Процесс реорганизации бизнеса
• Творческий краткий
• Моделирование данных
• Бриф на дизайн
• Функциональные требования
• Информационные технологии
• Модельно-ориентированное проектирование
• Язык преобразования модели
• Требующий оценки
• Нефункциональные требования
• Архитектура процесса
• Моделирование процессов
• Анализ соответствия продукта
• Выявление требований
• Группа специалистов по разработке требований
• Управление требованиями
• Прослеживаемость требований
• Разработка программного обеспечения на основе поиска
• Прототипирование программного обеспечения
• Требования к программному обеспечению
• Спецификация требований к программному обеспечению
• Системный анализ
• Системные Требования
• Спецификация системных требований
• Ориентированный на пользователя дизайн

Библиография

• Брайан Беренбах; Дэниел Паулиш; Юрген Кацмайер; Арнольд Рудорфер (2009). Разработка требований к программному обеспечению и системам: на практике . Нью-Йорк: McGraw-Hill Professional. ISBN  978-0-07-160547-2 .
• Хэй, Дэвид С. (2003). Анализ требований: от бизнес-представлений к архитектуре (1-е изд.). Река Аппер-Седл, Нью-Джерси: Прентис-Холл. ISBN  0-13-028228-6 .
• Лапланте, Фил (2009). Разработка требований к программному обеспечению и системам (1-е изд.). Редмонд, Вашингтон: CRC Press. ISBN  978-1-4200-6467-4 .
• Институт управления проектами (01.01.2015). Бизнес-анализ для практиков . Институт управления проектами. ISBN  978-1-62825-069-5 .
• МакКоннелл, Стив (1996). Быстрое развитие: графики укрощения дикого программного обеспечения (1-е изд.). Редмонд, Вашингтон: Microsoft Press. ISBN  1-55615-900-5 .
• Нусейбе, Б.; Истербрук, С. (2000). Разработка требований: дорожная карта (PDF) . ММВБ '00. Материалы конференции о будущем программной инженерии . стр. 35–46. CiteSeerX   10.1.1.131.3116 . дои : 10.1145/336512.336523 . ISBN  1-58113-253-0 .
• Эндрю Стеллман и Дженнифер Грин (2005). Управление проектами прикладного программного обеспечения . Кембридж, Массачусетс: O'Reilly Media. ISBN  0-596-00948-8 .
• Карл Вигерс и Джой Битти (2013). Требования к программному обеспечению (3-е изд.). Редмонд, Вашингтон: Microsoft Press. ISBN  978-0-7356-7966-5 .

Внешние ссылки

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