В рамках обучения начинающих системных и бизнес-аналитиков сегодня рассмотрим самые частые ошибки в разработке требований к ПО и их оформлении в виде технического задания (ТЗ) по шаблонам российских ГОСТ’ов или международных стандартов спецификации. А также разберем, чем опасны их последствия и как их можно избежать с помощью рекомендаций BABOK®Guide и не только.
Ошибка №1: упущение стейкхолдеров
Заказчик и конечные пользователи будущего продукта – далеко не единственные стейкхолдеры, интересы и потребности которых должен учесть аналитик при разработке требований. Чаще всего при определении стейкхолдеров начинающие аналитики забывают о внешнем окружении: регулятор, поставщик и клиент как потребитель результатов бизнеса. Например, конечными пользователями CRM-системы являются сотрудники отдела продаж. Однако, если система будет удовлетворять только их потребности в хранении и обработке заявок, не учитывая потребности менеджмента и самих клиентов, реальная ценность этого продукта для бизнеса будет намного меньше потенциально возможной.
К примеру, информируя клиента о статусе его заявке, можно повысить лояльность потребителя, т.к. знание о том, на каком этапе обработки находится обращение, снижает степень неопределенности (беспокойства). Начальник отдела продаж или маркетолог фактически могут не являться пользователями CRM, но им нужны сводные отчеты по сделкам, количеству и источнику заявок. В качестве регулятора обычно выступают государственные и надзорные организации, которые могут предъявлять свои требования к обработке и хранению персональных данных. В частности, некоторая информация должна обязательно иметь бумажные подлинники с подписями всех сторон.
Таким образом, упущение стейкхолдером чревато не только отсутствием важных функций (фичей) в продукте, но и снижением его фактической ценности для бизнеса. Избежать этой ошибки поможет внимательный анализ стейкхолдеров на этапе предварительного обследований, который часто называют разработкой концепции перед собственно техническим заданием (ТЗ). О таких техниках анализа стейкхолдеров, рекомендуемых BABOK®Guide (список, луковичная диаграмма, карта влияния, матрица ответственности и архетипирование), я рассказывала здесь.
Код курса
BAPM
Ближайшая дата курса
по запросу
Продолжительность
ак.часов
Стоимость обучения
0 руб.
Ошибка №2: формулировки на языке интерфейсов
При том, что люди лучше воспринимают наглядные картинки, чем текст, представлять требования в виде макетов графических форм UI и диаграмм бизнес-процессов – это грубая ошибка. Сюда же относится включение элементов пользовательского интерфейса в формулировку требований. Например, «Система отправляет введенные данные после нажатия пользователем кнопки ОТПРАВИТЬ». Кнопки, чек-боксы, радио-кнопки, выпадающие списки, всплывающие окна, цвета и размеры, а также прочие элементы UI/UX – это область ответственности дизайнера/проектировщика интерфейса. При этом аналитик определяет требования к интерфейсам пользователя UX, а также нефункциональные требования, которые относятся к взаимодействию с пользователем, например, удобство практического использования, включая простоту ежедневной работы и обучения.
В частности, требование к удобству пользовательского интерфейса может быть сформулировано как необходимость соответствия предписаниям ГОСТ Р 52872-2019 или возможность добраться до любого конверсионного элемента UI не более чем за 3 клика. Правда, в этом случае, необходимо четко обозначить, что именно понимается под конверсионным элементом и какую конверсию как отношение чего-то к чему-то это позволяет рассчитать.
При этом BABOK®Guide включает прототипирование в список наиболее полезных для бизнес-аналитика техник как метод раннего проектирования продукта для выявления и подтверждения потребностей стейкхолдеров через итеративной процесс создания модели или дизайна требований. Но, в отличие от дизайнов, требования носят универсальный характер, не зависят от особенностей реализации и интерфейсов. Бумажные или цифровые прототипы пригодятся для улучшения впечатления пользователей, оценки вариантов дизайна и как основа конечного решения. Однако, созданные аналитиком прототипы не могут рассматриваться как требования к реализации. В ТЗ или SRS такие макеты UI-форм могут включаться как иллюстративные дополнения (приложения), а не входные данные для команды разработки. Подробнее про технику прототипирования читайте в новой статье.
Основы бизнес-анализа: вход в профессию для начинающих
Код курса
INTRO
Ближайшая дата курса
13 января, 2025
Продолжительность
24 ак.часов
Стоимость обучения
54 000 руб.
Ошибка №3: недостаточная детализация требований в ТЗ
ТЗ или SRS являются входными данными для проектирования продукта – сперва эскизного, а затем технического. Поэтому, чтобы результат полностью удовлетворял потребности бизнеса и стейкхолдеров, функциональные и нефункциональные требования должны быть максимально детальными. В функциональных требованиях чаще всего это сводится к четкой идентификации следующих аспектов:
- роль пользователя;
- данные – объект предметной области и его атрибуты из словаря данных;
- функция из набора CRUD-операций.
Если речь идет, что система рассчитывает какие-то значения на основании введенных пользователем данных, аналитик должен привести в ТЗ все необходимые формулы. Разумеется, в этом случае нужна консультация эксперта предметной области и ссылки на отраслевые стандарты.
Для самостоятельной проверки разработанного ТЗ на достаточность детализации аналитику следует вспомнить, для кого он создает этот документ. Потребителями результатов труда здесь являются Заказчик, Разработчик или ИТ-Архитектор, Тестировщик и Руководитель проекта. Поставив себя на место каждой роли, задайте вопрос: отвечает ли разработанное ТЗ на вопросы этого стейкхолдера:
- для Заказчика нужно, чтобы продукт решал его бизнес-проблемы с пользой, измеримой в деньгах или других точных показателях (время, количество клиентов);
- сможет ли Разработчик/ИТ-Архитектор на основании вашего ТЗ разработать схему базы данных и выбрать наиболее эффективные технологии для реализации требований к надежности, отказоустойчивости, доступности, расширяемости, переносимости и безопасности?
- помогут ли Тестировщику ваши сценарии в виде use case составить тест-кейс для верификации поведения продукта?
- наконец, поймет ли Менеджер проекта объем работы исходя из определенных требований?
Если на все вопросы объективный ответ – да, то скорей всего, ваше ТЗ сделано достаточно качественно и может использоваться командой реализации в следующих процессах SDLC-цикла. Иначе нужно тщательно дорабатывать, верифицировать и валидировать требования, а также дополнять их. В качестве проверки, насколько хорошо вы усвоили материал этой статьи, предлагаю вам самостоятельно выполнить открытый интерактивный тест на знание стандартов разработки ТЗ и спецификации требований к ПО.
Разработка ТЗ на информационную систему по ГОСТ и SRS
Код курса
TTIS
Ближайшая дата курса
2 декабря, 2024
Продолжительность
16 ак.часов
Стоимость обучения
36 000 руб.
А практически усвоить приемы разработки требований и их спецификации в виде ТЗ вы сможете на курсе «Разработка ТЗ на информационную систему» в нашей Школе прикладного бизнес-анализа в лицензированном учебном центре обучения и повышения квалификации системных и бизнес-аналитиков в Москве.
