Анализ требований как основа будущего проекта

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

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

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

Без проработки требований — и достаточно глубокой — можно ошибиться в порядке стоимости проекта, потому что первые версии технического задания часто скрывают подводную часть айсберга. Изначально проект может казаться простым, но стоит начать его делать, как выясняется, что для того, чтобы ПО действительно решало задачу, ради которой было задумано, придется делать значительно больше, чем планировалось.

Существует и обратный риск: переоценить проект, заложив ненужные требования, от которых можно отказаться после анализа приоритетов. Проработка требований позволяет существенно повысить точность оценки.

Неопределённость в оценке проекта
объём работы, затраты, функциональность
Анализ требований как основа будущего проекта Анализ требований как основа будущего проекта
  • Исходная концепция
  • Согласованное определение продукта
  • Завершение требований
  • Завершение проектирования пользовательского интерфейса
  • Завершение детального проектирования
  • Готовый программный продукт
Снизить общую стоимость проекта

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

Стоимость рисков, которую закладывает подрядчик, существенно выше, чем дополнительные затраты на аналитику на начальном этапе.

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

Разница в стоимости проекта до и после анализа требований
Анализ требований как основа будущего проекта
Стоимость одного модуля
  • Первичная оценка с учетом рисков
  • Стоимость после анализа требований
Общая стоимость проекта
  • Первичная оценка с учетом рисков
  • Стоимость после анализа требований
Сохранять накопленные знания

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

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

Анализ требований как основа будущего проекта Анализ требований как основа будущего проекта
Предусмотреть развитие продукта

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

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

Экспоненциальный рост стоимости внесения изменений
Кривая Боэма
Анализ требований как основа будущего проекта Анализ требований как основа будущего проекта
  • Спецификация требований и проектирование продукта
  • Разработка кода продукта
  • Тестирование продукта
Контролировать ход работ и итоговый результат

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

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

Анализ требований как основа будущего проекта Анализ требований как основа будущего проекта
  • Что нужно клиенту
  • Что создал разработчик
  • Точка контакта с клиентом
  • Разрыв ожиданий при участии клиента
  • Разрыв ожиданий при невмешательстве клиента
Какая документация нужна вашему проекту

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

Базис требований

Документы, необходимые для любого проекта. Без проработки этих пунктов шансы на успех проекта резко снижаются.

Базис требований
Концепция проекта

Верхнеуровневое описание проекта (цели, задачи, границы, заинтересованные стороны, роли пользователей, ключевые процессы и т.п.)

Контекстная диаграмма

Визуализация системы и окружения, в котором она будет работать, а также потоков данных между ними

Функциональная карта

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

Анализ технических рисков и ограничений

Описание ключевых технических рисков, влияющих на возможность реализации системы, и предложения по их устранению

Нефункциональные требования

Описание требований к производительности, отказоустойчивости, безопасности, масштабируемости и другим параметрам системы

Большое число компонентов системы

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

Большое число компонентов системы
Архитектура системы

Верхнеуровневое описание компонентов системы и схем взаимодействия между ними

Спецификация протокола взаимодействия

Описание протоколов взаимодействия (REST, gRPC и т.п.) между компонентами системы и между системой и внешней средой

Диаграмма развертывания для корпоративных систем

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

Сложность процессов или высокие требования к регламентированию

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

Сложность процессов или высокие требования к регламентированию
Пользовательские истории

Описание решаемых задач и критерии приемки для всех функций проектируемой системы.

Сценарии использования

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

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

Инструкции пользователя корпоративных систем

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

Широкая аудитория пользователей

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

Широкая аудитория пользователей
Blockflow

Визуальное представление основных шагов пользователей в системе

Wireflow / Карта переходов

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

Интерактивный прототип

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

Несколько лиц влияющих на решения

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

Сложные процессы согласования внутри компании
Концепция дизайна пользовательских интерфейсов

Стиль основных элементов (кнопки, таблицы, выпадающие меню и т.п.) пользовательских интерфейсов проекта

Полный дизайн пользовательских интерфейсов

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

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

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

2
Контроль соответствия исходным целям

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

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

3
Сравнение оценок, выбор или смена исполнителя

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

4
Полноценное владение системой после внедрения

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

2003
2020
70% клиентов возвращаются к нам с новыми проектами
17 лет
на рынке разработки программного обеспечения на заказ
100+
разработчиков с многолетним опытом и отраслевыми специализациями
460+
успешно завершенных проектов для клиентов по всему миру
Мы найдем лучшее решение вашей задачи