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

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

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

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

Обзор

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

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

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

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

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

Идентификация заинтересованных сторон

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

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

Совместные сессии разработки требований (JRD)

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

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

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

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

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

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

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

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

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

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

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

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

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

Прототипы

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

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

Сценарии использования

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

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

Технические требования

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

Типы требований

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

Требования заказчика
Заявления о фактах и ​​предположениях, которые определяют ожидания системы с точки зрения целей миссии, среды, ограничений и мер эффективности и пригодности (MOE / MOS). Клиенты - это те, кто выполняет восемь основных функций системного проектирования, уделяя особое внимание оператору как ключевому заказчику. Операционные требования будут определять основную потребность и, как минимум, отвечать на вопросы, поставленные в следующем списке:
  • Оперативное распространение или развертывание : где будет использоваться система?
  • Профиль или сценарий миссии : как система выполнит свою миссию?
  • Производительность и связанные параметры : каковы критические параметры системы для выполнения миссии?
  • Среда использования : как будут использоваться различные компоненты системы?
  • Требования к эффективности : насколько эффективной должна быть система при выполнении своей миссии?
  • Жизненный цикл эксплуатации : как долго система будет использоваться пользователем?
  • Окружающая среда : в каких средах ожидается, что система будет работать эффективно?
Архитектурные требования
Архитектурные требования объяснить , что должно быть сделано путем определения необходимых архитектуры системы в виде системы .
Конструктивные требования
Структурные требования объясняют, что должно быть сделано, путем определения необходимой структуры системы.
Поведенческие требования
Поведенческие требования объясняют, что должно быть сделано, путем определения необходимого поведения системы.
Функциональные требования
Функциональные требования объясняют, что должно быть сделано, путем определения необходимой задачи, действия или деятельности, которые должны быть выполнены. Функциональный анализ требований будет использоваться в качестве функций верхнего уровня для функционального анализа.
Нефункциональные требования
Нефункциональные требования - это требования, которые определяют критерии, которые могут использоваться для оценки работы системы, а не конкретное поведение.
Требования к производительности
Степень, в которой миссия или функция должны быть выполнены; обычно измеряется с точки зрения количества, качества, охвата, своевременности или готовности. Во время анализа требований требования к производительности (насколько хорошо это должно быть выполнено) будут разработаны в интерактивном режиме для всех идентифицированных функций на основе факторов жизненного цикла системы; и охарактеризованы с точки зрения степени уверенности в их оценке, степени важности для успеха системы и их отношения к другим требованиям.
Требования к дизайну
Требования к продуктам «до сборки», «код для» и «покупка для» и требования «как выполнять» для процессов, выраженные в пакетах технических данных и технических руководствах.
Производные требования
Требования, которые подразумеваются или преобразовываются из требований более высокого уровня. Например, требование большой дальности или высокой скорости может привести к конструктивному требованию небольшого веса.
Выделенные требования
Требование, которое устанавливается путем разделения или иного распределения требования высокого уровня на несколько требований более низкого уровня. Пример: 100-фунтовый предмет, состоящий из двух подсистем, может привести к требованию веса 70 фунтов и 30 фунтов для двух предметов нижнего уровня.

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

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

Вопросы заинтересованных сторон

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

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

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

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

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

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

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

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

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

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

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

Смотрите также

Рекомендации

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

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