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

эта статья нужны дополнительные цитаты для проверка. Пожалуйста помоги улучшить эту статью от добавление цитат в надежные источники. Материал, не полученный от источника, может быть оспорен и удален. Найдите источники: "Анализ требований"  – Новости  · газеты  · книги  · ученый  · JSTOR (Декабрь 2011 г.) (Узнайте, как и когда удалить этот шаблон сообщения)

А системная инженерия взгляд на анализ требований.^[1]

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

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

Обзор

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Недостатки

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

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

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

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

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

Прототипы

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

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

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

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

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

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

Эта секция нуждается в расширении. Вы можете помочь добавляя к этому. (Февраль 2018 г.)

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

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

Этот раздел может требовать уборка встретиться с Википедией стандарты качества. Нет причина очистки был указан. Пожалуйста помоги улучшить этот раздел если вы можете. (Февраль 2011 г.) (Узнайте, как и когда удалить этот шаблон сообщения)

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

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

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

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

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

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

Конструктивные требования

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

Поведенческие требования

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

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

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

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

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

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

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

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

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

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

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

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

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

Хорошо известные модели категоризации требований включают: Шубы и FURPS +, разработанные в Hewlett Packard.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

использованная литература

Список используемой литературы

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

• Экспертная оценка Энциклопедия по разработке и анализу требований
• Университет обороны Процесс определения требований заинтересованных сторон
• Документ по системным требованиям MIL-HDBK 520 Руководство