Виды требований
Разработка программного обеспечения основывается на требованиях - ожиданиях пользователей к будущей функциональности. Требования бывают очень разные по сути, составу, форме и качеству. Поэтому очень важно правильно называть и использовать требования разного сорта.
В Devprom ALM мы выделяем три основных уровня требований:
| Уровень заказчика, пользователя или их представителей |
Первичные требования - пожелания, заявки, запросы на изменения, хотелки. Это неструктурированные, неполные и даже противоречивые требования, которые поступают команде из различных источников. Часто такие требования сформулированы вольным текстом или записаны в формате пользовательских историй. Принципиальное отличие первичных требований от остальных - в них содержатся как требования к функциональности, так и изменения к функциональности. Другими словами, по набору первичных требований крайне сложно получить целостное описание функциональности всей системы. |
| Уровень анализа, проектирования и моделирования |
Бизнес-требования и системные требования (функциональные и нефункциональные, НФТ), которые целостно и непротиворечиво описывают бизнес-процессы и требования к разработке программной системы. Эти требования самого высокого качества, поскольку готовятся специально обученными людьми. Системные требования могут подразделяться на варианты использования, НФТ, UML-модели, макеты пользовательского интерфейса и т.п. В качестве форматов документирования обычно применяют: BRD (документ бизнес-требований), бизнес-кейс, SRS (спецификация системных требований), ТЗ (техническое задание) и т.п. |
| Уровень разработчиков, тестировщиков и технических писателей | Задачи по реализации требований (целиком, частями или целыми документами) называются доработками. В доработке записано что необходимо реализовать или какие выполнить изменения в ранее реализованном требовании, когда и кому это сделать и т.д. Тестировщики также используют доработки для проверки реализации требований. |
Важно также отличать тип требования от формата, в котором оно задокументировано. Например, ТЗ (техническое задание) в себе содержит множество требований разных типов и общую информацию. Варианты использования (Use Cases) могут быть записаны в формате, предложенном А. Коберном или предложенном в процессе OpenUP (Rational Unified Process) и еще несколькими популярными вариантами. Вам необходимо самостоятельно определиться, каким именно образом эффективно документировать требования на ваших проектах.
В зависимости от сложности предметной области, сложности системы и квалификации исполнителя, описанные уровни требований могут пересекаться. Например, команда разработки может эффективно работать и с первичными требованиями.
Ниже приводятся современные способы выявления и сбора первичных требования.
Практика Impact Mapping
Гойко Аджич усовершенствовал и развил практику сбора первичных требований под названием Impact Mapping. Ее суть заключается в выстраивании причинно-следственных связей (трассировки) от бизнес-целей к конкретным элементам автоматизации (функций продукта). Разработчик совместно с заказчиком должны ответить на следующие вопросы:
- Зачем нам нужна та или иная функциональность и какой измеримой цели мы хотим достичь? Это наши будущие бизнес-цели.
- Кто участвует в достижении этой цели? Это действующие лица: сотрудники, люди, отделы или подразделения.
- Каким образом этот человек или сотрудник достигает цели, какую работу он выполняет? Это влияние, которое действующее лицо оказывает на достижение цели.
- Что нужно этому человеку от программной системы для выполнения своей работы? Это конкретные фичи или функции продукта (большие истории), которые действующее лицо использует для влияния на цель.
Визуализировать эти связи можно при помощи маркера и техники "ментальных карт", либо при помощи липких листочков.
Когда карта будет завершена и заказчик с разработчиком договорятся о целях и объеме работ, результаты можно зафиксировать в модуле "Цели и функции", например, следующим образом:
Практика Story Mapping
Джефф Паттон предложил коммуникационную практику, которая позволяет выявлять и структурировать пользовательские требования, трассировать их на бизнес-цели и конкретных людей, выполняющих какую-то деятельность для достижения этих целей (метод Персон). Для стори-мэппинга вам потребуется горизонтальная (столы) или вертикальная (стена) поверхность, на которой можно клеить липкие разноцветные листочки.
Совместно с бизнес-пользователем или представителем заказчика выявляются персоны, которым необходима автоматизация. Для каждой персоны записываются цели, ради которых планируется разработка/доработка программной системы. Цели записываются на желтых листочках. Бизнес-активности, которые выполняются персонами, для достижения целей, записываются на голубых листочках, которые размещаются под соответствющими целями. Под каждой активностью на желтых листочках записываются конкретные действия пользователя в системе (обычно такие действия записываются в формате пользовательской истории).
Пример того, как это может выглядеть:
Это важный артефакт, который используется заказчиком и исполнителем для контроля за ходом реализации. Оставлять его в таком виде на стене или на столе нельзя, поскольку листочки просто осыпятся или кто-то их случайно снимет и выбросит. Необходимо оцифровать эту карту, для чего отлично подойдет модуль Функции (или Эпики).
Предварительно необходимо настроить справочник уровней функции и добавить туда значения: Персона, Цель, Активность. После этого можно зафиксировать карту историй следующим образом:
Источники требований
Первичные требования фиксируются аналитиками в списке пожеланий или пользовательских историй. Вы можете предоставить заказчику доступ к проекту, таким образом, он сможет самостоятельно регистрировать требования со своей стороны. Это не повлияет на стоимость, поскольку такие пользователи являются бесплатными. Если вам необходимо изолировать часть информации по проекту от заказчика, просто настройте для него специальную роль и выдайте ей права доступа, которые позволят записывать требования, но не позволят видеть или изменять другие чувствительные для проекта данные.
Если представителей заказчика много и они не искушены работой в современных трекерах и ALM-системах, можно предложить им использовать функциональность портала тех. поддержки. Это отдельный сайт, с упрощенным интерфейсом, на котором можно разместить полезную информацию, а также оставлять требования, общаться по ним с аналитиками, отслеживать их статус и степень готовности.
Можно собирать требования, отправляемые по электронной почте. Сообщите пользователям электронный адрес, на который они будут писать свои запросы. Письма автоматически будут преобразованы в заявки и помещены в список пожеланий.
Используйте импорт списка первичных требований (пожеланий) из документов Word, OpenDocument, Excel. Бизнес- и системные требования можно импортировать в виде документов из файлов формата DOCX, ODT и других, используемых при работе с текстовыми редакторами.
При импорте требований из Excel вы можете сформировать иерархию требований. Для этого необходимо добавить столбец с названием "Номер раздела" (название вводится в первой строке). Укажите номер раздела для каждого требования из импортируемого списка, например, 1, 1.1, 1.1.2 и т.п.
Всю неструктурированную информацию по требованиям, такую как письма, файлы, сканы документов, электронные таблицы и т.п., можно сохранять на страницах базы знаний проекта. Данные можно импортировать (преобразуя во внутренний формат Devprom ALM), либо прикреплять как файлы к разделам базы знаний.