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

Если не отнестись к этой задача ответственно, то последствия могут быть разные: от небольшой доработки функции до полной переработки системы. Страшный сон аналитика – когда заказчик заметил, что функции, которая описана в ТЗ, нет в системе.

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

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

Еще есть архитектурные, но на практике я с ними не встречался – они описывают то, из каких частей состоит система. Обычно это либо явно прописано в ТЗ от заказчика, либо этим занимаются архитектор или разработчики.

Под типами требований я имею в виду функциональные и нефункциональные. Функциональные отвечают на вопрос «Что?» и описывают действие с системой, а нефункциональные – то, как она должна выглядеть, как должна работать. Эта тема заслуживает отдельного материала со множеством примеров, но я пробежался по ней кратко, поскольку материал посвящен другому вопросу.

Знакомы с термином стейкхолдеры? Это лица и/или организации, заинтересованные в создании системы, и у них мы будем собирать требования. Стейкхолдером может быть начальник, менеджер проектов, директор и даже министр Здравоохранения – этим лицам нужно готовое решение, поэтому их требования и пожелания мы будем собирать и использовать для разработки.

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

Одно из правил Agile – наличие представителя заказчика в компании исполнителя. Это как ускоренное интервью – человек находится рядом, в рабочее время к нему можно обратиться с вопросами, причем не один раз.

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

Прекрасно, если для компании ваш проект – не первый. Тогда можно переиспользовать различную документацию (частное техническое задание, пояснительную записку) и взять ее за шаблон. Это существенно сократит время на сбор и анализ требований, поскольку часть из них может подойти и для текущего проекта. Например, ТЗ для интернет-магазинов очень похожи друг на друга.

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

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

Я, как системный аналитик, получал скупую информацию от лидера проекта после совещаний, доводил ее до ума и ставил задачи на разработку. На этой работе использовал методики «интервью» и «изучение набросков по черновикам», очень редко случались «мозговые штурмы», но пользы они не приносили – заказчику все равно что-то не нравилось.

Понравилось изучать наброски – повезло, что человек умеет выражать свои мысли. В спокойной обстановке изучаешь черновики, рисуешь макеты, при необходимости – уточняешь мелкие детали. Зарисовки быстро превратились в функциональные и нефункциональные требования и были отправлены в разработку. Отмечу, что документации на проекте (как и ТЗ) не было, разработка велась хаотично по «хотелкам» заказчика.

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

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

Очень помогло переиспользование документации. Большая часть документов (ЧТЗ, пояснительная записка) были переписаны с другого проекта, что существенно ускорило разработку и избавило заказчика от повторяющихся шаблонных вопросов.

Прежде, чем обращаться к стейкхолдеру, я отвечаю на три вопроса:

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

Хорошо, требования собраны, что дальше? Теперь их нужно проработать, и тут нам пригодятся те самые схемы UML (для системных требований) и BPMN (для бизнес-требований). На практике они существенно облегчают понимание требования, позволяют полно описать его и выявить мелкие, но важные детали. Можно составить схемы только для личного пользования – визуализация лучше всего помогает понять задачу.

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

Проработка требований – процесс ответственный, но несложный и даже увлекательный. Рекомендую немного потренироваться в этом деле, а потом обратиться к книге «Разработка требований к программному обеспечению» Карла Вигерса и Джой Битти, которая станет исчерпывающим руководством как для начинающих, так и для опытных аналитиков.