Введение

Необходимый этап для любого проекта, но если в малых ещё можно что-то делать через постоянное обращение к клиенту: "делаем так?", то в случае большого или высоконагруженного проекта без проведения этого этапа в полном объёме реализовать проект невозможно.

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

В случае сложной предметной области, возможно, заказчик сам не может толком собрать такие требования. Часто клиент приходит к исполнителю с "кашей" в голове. Этап сбора и анализа требований в этом случае - это упорядочивание и формальная регистрация этой "каши". И согласование полученного с клиентом.

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

  Требования

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

Функциональные требования - это пользовательские сценарии, которые должны быть реализованы в системе. Если они работают так как нужно клиенту, то эти требования выполнены.

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

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

Сбор и анализ требований может быть (в случае больших и сложных проектов - должен быть) итерационным, пошаговым. В противном случае можно потерять очень много времени на данном этапе, для сложных систем (типа Softkey) - до года. В этом случае возникают свои риски: не учесть всего и встать перед необходимостью переделки.

Надо организовать с клиентом серию встреч в доверительной атмосфере. Клиент должен увидеть что вы не "отжимаете" деньги, а пытаетесь вместе с ним понять что ему нужно, решить его задачу эффективно, дёшево, быстро и максимально просто. Заказчик должен быть уверен, что он в любой момент может прийти, увидеть доступные документы по работе над его проектом. Это называется выстроить атмосферу Agile манифеста. В этом случае клиент будет максимально открыт, сообщать всё что он знает о проблеме.

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

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

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

  Методы и инструменты

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

Есть несколько инструментов:

• Общий словарь терминов проекта. Например: "Ценовое предложение - это ...", "Цена - это ...", "Валюта - это..." и так далее. В этом случае, заказчик и исполнитель начинают говорить друг с другом на понятном языке. В больших проектах такой словарь может быть в несколько сотен терминов. В дальнейшем описание всех остальных документов ведется терминами словаря.
• Модель сущностей (классов) (Class\Object Diagram) определяем сущности системы:

  

  Это статическая модель. На неё переносятся термины из словаря и устанавливаются связи и отношения между сущностями. Здесь потребуется серьёзная логическая работа со стороны Клиента. Он должен показать и обосновать почему эта связь есть, откуда она берётся. На больших проектах таких диаграмм может быть несколько (встречается до 10) и каждая охватывает какую-то часть системы.

• Сценарии, Use Case или User story - динамическая модель системы. Описание поведения пользователей с определёнными ролями в системе.

  Пример отображения динамической схемы

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

• Story map - Упорядоченная карта выявленных требований. Расстановка приоритетов в выявленных требованиях: более срочные, главные и понятные пишутся наверху, менее важные, менее приоритетные, менее понятные - пишутся внизу.

Если требуется более глубокая проработка требований (это может потребоваться когда в проекте появляются какие-то алгоритмы вычисления, шифровки, работы банкоматов, корзины), то используются:

• Диаграмма деятельности (Activity Diagram) для "окольцовки" блок схем логики.
• Диаграмма состояний (State machine diagram) для описания состояний конечных автоматов, когда система может ходить между статусами. (Например, заказ в интернет-магазине.)
• Диаграмма последовательности (Sequence diagram) для упорядочивания по времени взаимодействия объектов (редко используемая диаграмма).
• Технические спецификации обмена данных – структура файлов импорта-экспорта и тому подобное.

Возможно вам ещё понадобится "картинка" того, как вы будете размещать всё на серверах: Диаграмма развёртывания Deployment Diagram.

Пример диаграммы развёртывания

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

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

  Риски

Основные риски при сборе и анализе требований:

• Риск непонимания задачи, приводящий к переусложению системы. Нужно стремиться к простоте, использовать только нужное.
• Риск "невовлечённости" Клиента. Непонимание клиентом необходимости сбора и анализа требований приводит к провалу проекта. Клиенту может быть выгодно не иметь формализованного и согласованного списка требований. В этом случае он может "давить" на исполнителя, требуя выполнения работ, ранее не предусмотренных.

  Иногда проблема возникает при недобросовестности, либо некомпетентности менеджера клиента, ведущего проект. Решение: требовать от клиента адекватного и добросовестного сотрудника.

• Риск формализации, когда слишком много времени и сил уходит на полную формализацию требований.

  Критерии завершённости этапа

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

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