Software Requirements. Три уровня требований.

Есть на свете очень хорошая книга, которая называется “Software Requirements”. К сожалению, этой книги в переводе на русском еще нет. А тот что есть – относится к изданию десятилетней давности. Поэтому я решил публиковать самые интересные моменты из книги в своем блоге. С одной стороны – это нужно мне, чтобы упорядочить и не растерять полезную информацию из книги. С другой стороны – эти статьи могут оказаться очень полезными для читателей блога.

Пару слов о книге. Она посвящена сбору требований для разработки программного обеспечения. Это издание книги было полностью переработано, добавлены новые примеры и советы. Так же авторы добавили описание сбора требований для agile проектов. Книга ориентирована на разработчиков, менеджеров проектов и в первую очередь на бизнес-аналитиков.

Основная проблема неудачных проектов – несоответствие ожиданий клиента тому, какой продукт выпустила команда разработчиков. В результате появляются доработки и исправления, которые съедают время и деньги. По результатам исследований, ошибки выявленные на стадии разработки, позволяют сократить количество доработок на 40-60% ^[1].

Давайте определимся, с понятием “требование”.

Требование – это описание того, что должно быть реализовано. Оно представляет собой описание того, как система должна себя вести, а так же описание ее свойств, особенностей и ограничений.

Все требования можно условно разделить на 3 уровня: бизнес-требования, пользовательские требования и функциональные требования. И т.к. само слово “требование” – достаточно обширное понятие, то на каждом уровне требований используют уточняющую терминологию.

Уровень бизнес-требований

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

Уровень пользовательских требований

Пользовательские требования – описывают задачи, которые должен решать создаваемый продукт (программа), а так же сценарии использования. Эти требования могут выражаться в виде вариантов использования (use case), пользовательских историй (user story) или сценариев взаимодействия (scenario).
Требования к качеству – не функциональные требования, которые описывают производительность и характеристики продукта.

Уровень функциональных требований

Функциональные требования – описывают поведение системы и действия, которые она должна будет выполнять. Попросту говоря, здесь содержится описание того, что разработчики должны реализовать, чтобы конечные пользователи могли выполнять свои задачи. Обычно они формулируются с использованием слова “должен”: “Система должна отправлять пользователю подтверждение о заказе” и т.п.
Системные требования – набор характеристик и модулей, подразумевающих оптимальную работу продукта.
Требования к интерфейсу – описание процесса взаимодействия пользователя с программой или устройством.
Ограничения – описание ограничений, которые накладываются на разработку программного обеспечения (например: юридические).

Взаимоотношения между всеми требованиями проще понять по следующей схеме:

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

Здесь под “документами” понимается не файл на компьютере (хотя и он может быть), а любые форматы хранения информации: Wiki, базы данных, набор файлов в определенной папке и т.п.

Благодарности.
Спасибо Наталье Юматовой за помощь в подготовке и написании поста.

Ссылки.
^[1] Davis, Alan M. 2005. Just Enough Requirements Management: Where Software Development Meets Marketing. New York: Dorset House Publishing.