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

Разработка программного обеспечения

Процесс разработки ПО
Шаги процесса
Анализ • Проектирование • Программирование • Документирование • Тестирование
Модели
Итеративная • Спиральная • Каскадная • V-Model • Dual Vee Model
Методологии
Agile (XP, Lean, Scrum, FDD и др.) • Cleanroom • OpenUP • RAD • RUP • MSF • DSDM • TDD
Сопутствующие дисциплины
Конфигурационное управление • Управление проектами • Управление требованиями

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

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

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

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

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

Фазы

^[Что?]Включает следующие фазы:^[1]

• Разработки требований
  • Выявление^[чего?]
  • Анализ
  • Спецификация
  • Проверка
• Управления требованиями

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

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

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

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

Опрос заинтересованных лиц

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

Сеансы совместного развития требований (СРТ)

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

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

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

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

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

Преимущества

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

Недостатки

• Такие списки могут занимать сотни страниц. Фактически невозможно прочитать такие документы в целом и получить чёткое понимание системы.
• Такие списки требований перечисляют отдельные требования абстрактно, оторванно друг от друга и от контекста использования
  • Эта абстракция лишает возможности видеть, как требования связываются между собой или работают вместе.
  • Эта абстракция мешает верно расположить требования по приоритетам; в то время как список, действительно облегчает приоретизацию отдельных пунктов, удаление одного пункта из контекста может сделать весь сценарий использования или деловое требование бесполезным.
  • Эта абстракция увеличивает вероятность неверного трактования требований; поскольку чем больше число людей будет их читать, тем большее будет число (различных) интерпретаций системы.
  • Эта абстракция означает, что чрезвычайно трудно убедиться, что у вас есть все необходимые требования.
• Эти списки создают ложное чувство взаимопонимания между заинтересованными лицами и разработчиками.
• Эти списки дают заинтересованным лицам ложное чувство защищённости, что разработчики должны достигнуть определённых вещей. Однако, из-за природы этих списков, они неизбежно упускают важные требования, которые будут выявлены позже в процессе. Разработчики могут использовать новые требования для пересмотра сроков и условий в их пользу.

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

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

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

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

Прототипы (опытные образцы)

В середине 1980-х прототипирование (англ. prototyping) рассматривалось как решение проблемы анализа требований. Прототипы — макеты системы. Макеты дают возможность пользователям представить систему, которая ещё не построена. Опытные образцы помогают пользователям представить на что будет похожа система, и облегчают пользователям принятие проектных решений, не дожидаясь окончания постройки системы. Наибольшие улучшения во взаимопонимании между пользователями и разработчиками часто замечались с введением опытных образцов. Ранние обзоры системы приводят к меньшему количеству изменений на поздних стадиях разработки и следовательно значительно уменьшают затраты.

Однако, за следующее десятилетие, прототипирование хоть и было признано эффективной техникой, однако не решило проблему анализа требований:

• Менеджерам, как только они видят опытный образец, сложно понять, что окончательный проект не будет разработан ещё некоторое время.
• Проектировщики часто чувствуют себя вынужденными использовать опытный образец в реальной системе, потому что они боятся «напрасно тратить время», начиная всё сначала.
• Опытные образцы преимущественно помогают с проектными решениями и дизайном пользовательского интерфейса. Однако, они не могут сказать Вам, какими были первоначальные требования.
• Проектировщики и конечные пользователи могут слишком сильно сосредоточиться на дизайне пользовательского интерфейса и слишком мало на производстве системы, которая служит бизнес-процессу.
• Прототипы отлично подходят для пользовательских интерфейсов, но мало полезны для сложной обработки данных или асинхронных процессов, которые могут вовлечь сложные обновления базы данных и/или вычисления.

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

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

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

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

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

Спецификация требований программного обеспечения (англ. Software Requirements Specification, SRS) является полным описанием поведения системы, которая будет создана. Она включает ряд сценариев использования, которые описывают все виды взаимодействия пользователей с программным обеспечением. Сценарии использования также известны как функциональные требования. В дополнении к сценариям использования, спецификация программного обеспечения также содержат нефункциональные (или дополнительные) требования. Нефункциональные требования — требования, которые налагают дополнительные ограничения на систему (такие как требования эффективности работы, стандарты качества, или проектные ограничения).

Рекомендуемые подходы для спецификации требований программного обеспечения описаны стандартом IEEE 830—1998. Этот стандарт описывает возможные структуры, желательное содержание, и качества спецификации требований программного обеспечения.

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

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

Требования клиентов

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

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

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

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

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

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

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

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

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

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

Известные модели классификации требований включают FURPS и FURPS+, разработанные в Hewlett-Packard.

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

Проблемы заинтересованных лиц

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

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

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

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

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

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

Решения проблем

Одно из решений проблемы общения состояло в том, чтобы нанять специалистов в деловом или системном анализе.

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

См. также

• Бизнес-анализ
• Требования к программному обеспечению

Примечания

1. ↑ Карл И. Вигерс. Разработка требований к программному обеспечению. — Русская редакция, 2004. — ISBN 5-7502-0240-2
2. ↑ Steve McConnell. Rapid Development

Литература

• Кобёрн А. Современные методы описания функциональных требований к системам. — М.: Лори, 2002. — ISBN 0-201-70225-8, ISBN 5-85582-152-8
• Леффингуелл Д., Уидриг Д. Принципы работы с требованиями к программному обеспечению. — М.: Вильямс, 2002. — ISBN ISBN 5-8459-0275-4
• Alan Mark Davis Just Enough Requirements Management: Where Software Development Meets Marketing. — Dorset House, 2005. — ISBN 978-0932633644

Ссылки

• Основы программной инженерии (по SWEBOK). Требования (рус.) (перевод SWEBOK с замечаниями и комментариями от Сергея Орлика и Юрия Булуя)
• Business Analysis Body Of Knowledge (англ.) (Документ построен главным образом вокруг требований)
• Системный анализ и требования (рус.) форум
• Статья о разработке и управление требованиями с точки зрения Agile (рус.)
• Шаблоны и хорошие практики в бизнес-анализе и в системном анализе

Для улучшения этой статьи желательно?: Викифицировать статью. Проставив сноски, внести более точные указания на источники. Добавить иллюстрации.