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

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


В Devprom ALM мы выделяем три основных уровня требований:

Уровень заказчика, пользователя или их представителей

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

Часто такие требования сформулированы вольным текстом или записаны в формате пользовательских историй.

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

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

Системные требования могут подразделяться на варианты использования, НФТ, UML-модели, макеты пользовательского интерфейса и т.п.

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


Важно также отличать тип требования от формата, в котором оно задокументировано. Например, ТЗ (техническое задание) в себе содержит множество требований разных типов и общую информацию. Варианты использования (Use Cases) могут быть записаны в формате, предложенном А. Коберном или предложенном в процессе OpenUP (Rational Unified Process) и еще несколькими популярными вариантами. Вам необходимо самостоятельно определиться, каким именно образом эффективно документировать требования на ваших проектах.


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


Ниже приводятся современные способы выявления и сбора первичных требования.

Практика Impact Mapping

Гойко Аджич усовершенствовал и развил практику сбора первичных требований под названием Impact Mapping. Ее суть заключается в выстраивании причинно-следственных связей (трассировки) от бизнес-целей к конкретным элементам автоматизации (функций продукта). Разработчик совместно с заказчиком должны ответить на следующие вопросы:

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

Визуализировать эти связи можно при помощи маркера и техники "ментальных карт", либо при помощи липких листочков.


Когда карта будет завершена и заказчик с разработчиком договорятся о целях и объеме работ, результаты можно зафиксировать в модуле "Цели и функции", например, следующим образом:

Практика Story Mapping

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


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


Пример того, как это может выглядеть: