В системной инженерии и разработке программного обеспечения анализ требований фокусируется на задачах, которые определяют потребности или условия для удовлетворения нового или измененного продукта или проекта, принимая во внимание возможно противоречивые требования различных заинтересованных сторон , анализируя, документируя, проверяя и управляя программным обеспечением или Системные Требования . [2]
Анализ требований имеет решающее значение для успеха или неудачи системного или программного проекта . [3] Требования должны быть документированы, выполнимы, измеримы, тестируемы, [4] отслеживаемы, [4] связаны с выявленными потребностями или возможностями бизнеса и определены на уровне детализации, достаточном для проектирования системы .
Концептуально анализ требований включает в себя три типа деятельности :
Анализ требований может оказаться долгим и утомительным процессом, в ходе которого задействуется множество тонких психологических навыков. Новые системы меняют окружающую среду и отношения между людьми, поэтому важно выявить все заинтересованные стороны, принять во внимание все их потребности и убедиться, что они понимают последствия новых систем. Аналитики могут использовать несколько методов, чтобы выявить требования клиента. Они могут включать в себя разработку сценариев (представленных в виде пользовательских историй в гибких методах ), определение вариантов использования , использование наблюдения на рабочем месте или этнографии , проведение интервью или фокус-групп (в этом контексте более точно называемых семинарами по требованиям или требованиями). обзорные сессии) и создание списков требований. Прототипирование может использоваться для разработки примерной системы, которую можно продемонстрировать заинтересованным сторонам. При необходимости аналитик будет использовать комбинацию этих методов для установления точных требований заинтересованных сторон, чтобы была создана система, отвечающая потребностям бизнеса. [ нужна ссылка ] Качество требований можно улучшить с помощью этих и других методов.
См. «Анализ заинтересованных сторон» , где обсуждаются люди или организации (юридические лица, такие как компании, органы по стандартизации), которые имеют действительный интерес к системе. Они могут быть затронуты этим как прямо, так и косвенно. Важным новым акцентом в 1990-е годы стал акцент на выявлении заинтересованных сторон . Все больше признается, что заинтересованные стороны не ограничиваются организацией, нанимающей аналитика. Другие заинтересованные стороны будут включать в себя:
Требования часто имеют межфункциональные последствия, которые неизвестны отдельным заинтересованным сторонам и часто упускаются из виду или не полностью определяются во время интервью с заинтересованными сторонами. Эти кросс-функциональные последствия могут быть выявлены путем проведения сеансов JRD в контролируемой среде при содействии обученного координатора (бизнес-аналитика), в ходе которого заинтересованные стороны участвуют в обсуждениях, чтобы выявить требования, проанализировать их детали и раскрыть кросс-функциональные последствия. Должен присутствовать специальный секретарь, который документирует дискуссию, освобождая бизнес-аналитику вести дискуссию в направлении, которое генерирует соответствующие требования, соответствующие цели сессии.
Сессии JRD аналогичны совместным сессиям по разработке приложений . В первом случае на занятиях выявляются требования, которые определяют дизайн, тогда как во втором выявляются конкретные особенности дизайна, которые необходимо реализовать для удовлетворения выявленных требований.
Одним из традиционных способов документирования требований были списки требований в стиле контракта. В сложной системе такие списки требований могут занимать сотни страниц.
Подходящей метафорой был бы чрезвычайно длинный список покупок. Такие списки не пользуются популярностью в современном анализе; поскольку они оказались крайне неудачными в достижении своих целей ; но их все еще можно увидеть по сей день.
В качестве альтернативы спискам требований гибкая разработка программного обеспечения использует пользовательские истории , чтобы предлагать требования на повседневном языке.
Лучшие практики рассматривают составленный список требований просто как подсказку и постоянно задают вопрос «почему?» до тех пор, пока не будут обнаружены фактические деловые цели. Заинтересованные стороны и разработчики могут затем разработать тесты для измерения того, какой уровень каждой цели был достигнут на данный момент. Такие цели меняются медленнее, чем длинный список конкретных, но неизмеренных требований. После того, как будет установлен небольшой набор критически важных, измеренных целей, быстрое прототипирование и короткие итеративные этапы разработки могут приступить к созданию реальной ценности для заинтересованных сторон задолго до того, как проект будет завершен наполовину.
Прототип — это компьютерная программа, которая демонстрирует часть свойств другой компьютерной программы, позволяя пользователям визуализировать еще не созданное приложение. Популярной формой прототипа является макет , который помогает будущим пользователям и другим заинтересованным сторонам получить представление о том, как будет выглядеть система. Прототипы облегчают принятие проектных решений, поскольку аспекты приложения можно увидеть и поделиться ими еще до его создания. Значительные улучшения в общении между пользователями и разработчиками часто наблюдались с появлением прототипов. Ранние просмотры приложений привели к меньшему количеству изменений в дальнейшем и, следовательно, значительно снизили общие затраты. [ нужна цитата ]
Прототипы могут представлять собой плоские диаграммы (часто называемые каркасами ) или рабочие приложения, использующие синтезированную функциональность. Каркасы создаются в различных документах графического дизайна и часто удаляют все цвета из дизайна (т. е. используют цветовую палитру в оттенках серого) в тех случаях, когда ожидается, что к окончательному программному обеспечению будет применен графический дизайн . Это помогает избежать путаницы относительно того, представляет ли прототип окончательный внешний вид приложения. [ нужна цитата ]
Вариант использования — это структура для документирования функциональных требований к системе, обычно включающей программное обеспечение, новое или изменяющееся. Каждый вариант использования предоставляет набор сценариев , которые описывают, как система должна взаимодействовать с пользователем-человеком или другой системой для достижения определенной бизнес-цели. В сценариях использования обычно избегают технического жаргона, предпочитая вместо этого язык конечного пользователя или эксперта в предметной области . Варианты использования часто создаются совместно инженерами по требованиям и заинтересованными сторонами.
Варианты использования — это обманчиво простые инструменты для описания поведения программного обеспечения или систем. Вариант использования содержит текстовое описание способов, которыми пользователи собираются работать с программным обеспечением или системой. Варианты использования не должны описывать внутреннюю работу системы и не должны объяснять, как эта система будет реализована. Вместо этого они показывают шаги, необходимые для выполнения задачи, без последовательных предположений.
Спецификация требований — это синтез результатов исследований относительно текущих потребностей бизнеса и оценка этих потребностей для определения и указания того, что требуется для удовлетворения потребностей в рамках рассматриваемого объема решения. Открытие, анализ и спецификация перемещают понимание из текущего состояния «как есть» в будущее состояние «как будет». Спецификация требований может охватывать всю широту и глубину будущего состояния, которое должно быть реализовано, или может быть направлена на заполнение конкретных пробелов, таких как приоритетные ошибки в системе программного обеспечения, которые необходимо исправить, и улучшения, которые необходимо внести. Учитывая, что любой крупный бизнес-процесс почти всегда использует программное обеспечение, системы и технологии обработки данных, спецификация требований часто связана со сборкой программных систем, закупками, стратегиями облачных вычислений, встроенным программным обеспечением в продукты или устройства или другими технологиями. Более широкое определение спецификации требований включает или фокусируется на любой стратегии или компоненте решения, например, обучении, руководствах по документации, персонале, маркетинговых стратегиях, оборудовании, расходных материалах и т. д.
Требования классифицируются по нескольким признакам . Ниже приведены общие категории требований, относящихся к техническому менеджменту: [1]
Заявления о целях бизнес-уровня без ссылки на подробную функциональность. Обычно это высокоуровневые (программные и/или аппаратные) возможности, необходимые для достижения бизнес-результатов.
Констатации фактов и предположений, которые определяют ожидания от системы с точки зрения целей миссии, окружающей среды, ограничений и показателей эффективности и пригодности (MOE/MOS). Клиентами являются те, кто выполняет восемь основных функций системного проектирования, при этом особое внимание уделяется оператору как ключевому потребителю. Эксплуатационные требования будут определять основные потребности и, как минимум, отвечать на вопросы, поставленные в следующем списке: [1]
Архитектурные требования объясняют , что необходимо сделать, определяя необходимую системную архитектуру системы .
Структурные требования объясняют, что необходимо сделать, определяя необходимую структуру системы.
Поведенческие требования объясняют, что необходимо сделать, определяя необходимое поведение системы.
Функциональные требования объясняют, что должно быть сделано, определяя необходимую задачу, действие или деятельность, которые должны быть выполнены. Анализ функциональных требований будет использоваться в качестве функций верхнего уровня функционального анализа. [1]
Нефункциональные требования — это требования, определяющие критерии, по которым можно судить о работе системы, а не конкретное поведение.
Степень, в которой миссия или функция должны быть выполнены; обычно измеряется с точки зрения количества, качества, охвата, своевременности или готовности. В ходе анализа требований требования к производительности (насколько хорошо это должно быть выполнено) будут интерактивно разрабатываться для всех выявленных функций на основе факторов жизненного цикла системы; и характеризуются с точки зрения степени уверенности в их оценке, степени критичности для успеха системы и их связи с другими требованиями. [1]
Требования «создавать», «кодировать» и «покупать» для продуктов, а также требования «как выполнять» для процессов, выраженные в пакетах технических данных и технических руководствах. [1]
Требования, которые подразумеваются или трансформируются из требований более высокого уровня. Например, требования к большой дальности полета или высокой скорости могут привести к необходимости снижения веса. [1]
Требование, которое устанавливается путем разделения или иного распределения требования высокого уровня на несколько требований более низкого уровня. Пример: предмет весом 100 фунтов, состоящий из двух подсистем, может привести к тому, что требования к весу составят 70 фунтов и 30 фунтов для двух предметов более низкого уровня. [1]
К широко известным моделям категоризации требований относятся FURPS и FURPS+, разработанные в Hewlett-Packard .
Стив МакКоннелл в своей книге Rapid Development подробно описывает ряд способов, которыми пользователи могут препятствовать сбору требований:
Это может привести к ситуации, когда требования пользователей продолжают меняться даже после начала разработки системы или продукта.
Возможные проблемы, возникающие у инженеров и разработчиков во время анализа требований:
Одной из попыток решения проблем со связью было найм специалистов по бизнес-анализу или системному анализу.
Техники, представленные в 1990-х годах, такие как прототипирование , унифицированный язык моделирования (UML), варианты использования и гибкая разработка программного обеспечения , также предназначены для решения проблем, возникавших при использовании предыдущих методов.
Кроме того, на рынке появился новый класс инструментов моделирования или определения приложений. Эти инструменты предназначены для устранения разрыва в общении между бизнес-пользователями и ИТ-организацией, а также для того, чтобы позволить приложениям «тестировать рынок» до того, как будет создан какой-либо код. Лучшие из этих инструментов предлагают:
В индустрии программного обеспечения широко признано, что проекты разработки программного обеспечения критически уязвимы, когда эти действия выполняются плохо.
[1]
