Один из самых главных процессов в деятельности бизнес-аналитика, про который почему-то многие забывают. Разработка и время стоят дорого, и дефекты из-за низкого качества требований приводят к гораздо большим затратам на более поздних этапах разработки.
Качественные требования соответствуют потребностям заинтересованных сторон и содержат достаточно информации для разработки программного продукта, удовлетворяющего ценностям бизнеса.
Типовые ожидания от требований
На этой диаграмме связей (Mind map) я собрал качества, которым обязаны соответствовать созданные требования. Некоторые из них вам должны быть знакомы по главе «Требования», но это тот случай, когда повторение полезно для закрепления материала.
Завершенность/полнота (completeness) – представлена вся необходимая информация для разработки. То есть ничего не пропущено под видом «это и так всем понятно, об этом и так все знают»: может поменяться состав команды, разработчик или даже подрядчик, у которого не будет никаких источников информации кроме ваших требований.
Пример незавершенных требований
«Система позволяет загружать изображения». (Изображения в каком формате? Какого максимального размера? Что подразумевается под изображением?)
«Информация о пользователях должна храниться в зашифрованном виде». (Что такое информация о пользователях, что под ней подразумевается? Какой алгоритм шифрования предполагается? Или если мы не говорим об алгоритме, то каким конкретно требованиям безопасности должна соответствовать информация, чтобы технические специалисты смогли подобрать подходящий способ ее хранения?)
Атомарность/единичность (atomicity) – требование невозможно разбить на части без потери смысла. Каждое требование должно быть декомпозировано до соответствия этому качеству.
Пример ошибки
«В момент, когда пользователь создал и активировал учетную запись». (Здесь описаны два разных случая: 1) когда пользователь зарегистрировался и создал свою учетную запись; 2) когда пользователь активировал свою учетную запись.)
Непротиворечивость / последовательность/согласованность (consistency) – непротиворечивые требования не конфликтуют с другими требованиями, отсутствуют конфликты внутри требований, и они не противоречат требованиям более высокого уровня, например бизнес-правилам.
Пример ошибки
«После успешной авторизации пользователь с ролью „Гость“». (После того как пользователь авторизовался, он уже имеет другую роль, то есть в самом требовании есть противоречие.)
Недвусмысленность /однозначность (unambiguousness/clear/understandable) – лица, которые будут читать требование, смогут истолковать его однозначно. Поскольку требования пишутся на естественном языке, в реальной жизни мы не можем полностью избежать таких ситуаций.
Пример ошибки
«Система обеспечивает быстрое выполнение запроса». (Основная ошибка здесь – это слово «быстрое», т. к. его невозможно измерить. Нарушен принцип проверяемости. В результате ответ на вопрос, реализовано ли требование, становится очень субъективным: для кого-то это будет медленно.)
Абстрактность (abstract/implementation free) – свойство, которое указывает на отсутствие конкретного способа реализации.
Проверяемость (verifiability/testable) – возможность создания объективного тест-кейса (—ов), однозначно показывающего, что требование реализовано верно и поведение приложения в точности соответствует требованию. Если требование не поддается проверке, то его реализация является субъективным мнением, а не объективным показателем.
Выполнимость / осуществимость (feasibility/realistic/possible) – указывает на способность реализовать каждое требование в рамках известных возможностей и ограничений системы и ее окружения.
Пример ошибки
«Искусственный интеллект должен давать юридические консультации по телефону».
Обязательность / необходимость (obligatoriness/necessary) – каждое требование должно документировать что-то действительно нужное клиентам или необходимое для соответствия внешнему требованию, внешнему интерфейсу или стандарту.
Актуальность (up-to-date) – требования должны регулярно верифицироваться на актуальность. Требования имеют свой жизненный цикл, постоянно меняются, развиваются или исключаются. Ваша документация не должна содержать требований, которые потеряли актуальность из-за каких-либо изменений.
Прослеживаемость/трассируемость (traceability) – возможность связать каждое требование к ПО с его источником, таким как требование более высокого уровня, вариант использования или мнение клиента. Также необходимо связать каждое требование к ПО с элементами дизайна, исходным кодом и тестовыми примерами, которые созданы для реализации и проверки требований. У каждого требования есть уникальный идентификатор.
Модифицируемость / способность к модификации (modifiability) – это качество отчасти пересекается с прослеживаемостью. Каждое требование должно иметь уникальный идентификатор для того, чтобы мы могли легко найти его. Требования должны быть организованы так, чтобы связанные требования были сгруппированы вместе при помощи оглавления, указателя и перекрестных ссылок, матриц и т. д.
Проранжированность / назначение приоритетов (ranked/prioritized) – каждое требование должно иметь приоритет по его реализации.
Методы обеспечения качества требований
Трассировка требований
Основная цель создания трассировок – убедиться в том, что команда проекта не делает ничего ненужного бизнесу или заинтересованным лицам, с одной стороны, и в том, что не забыто ничего из того, что действительно нужно бизнесу или заинтересованным лицам, – с другой.
Обычно трассировки строятся от одного типа требований ко второму, далее к третьему, четвертому и т. д. – пока не доходят до «конечных» типов требований. Таким обычно выбирается «вариант использования» или «функциональное требование» и «нефункциональное требование». Вся информация о трассировках, их назначениях и «конечных» типах требований фиксируется в ПУТ.
В результате можно построить «дерево» трассировок, которое позволит проследить, как учтено «исходное» требование в «конечном».
Решение о том, делать или не делать трассировки, а если делать, то какие именно, принимает менеджер проекта совместно с системным аналитиком и тест-менеджером.
Все трассировки условно можно разделить на причинно-следственные (основные) и проверочные (дополнительные). Причинно-следственные трассировки нужны для разработки качественного продукта. Проверочные необходимы в первую очередь менеджеру проекта как ответственному за качество продукта. От выполнения проверочных трассировок зависят успех проекта и удовлетворенность заказчика.
Согласование требований
Для многих, кто работает или планирует работать в продуктовых компаниях, все описанное в этой главе – сухая теория, с которой они никогда не сталкиваются. Это происходит потому, что им приходится согласовывать требования с единым ответственным лицом при помощи акцептирования элементов в JIRA или аналогичной системе. Однако сотрудникам крупных и особенно государственных компаний, занимающихся ERP системами и т. д., знать основы документооборота крайне полезно.
Три золотых правила согласования
1. На согласование должен быть направлен проект документа, полностью подготовленный и оформленный в соответствии с установленными в организации правилами. Инициатор проекта документа подготавливает проект в соответствии с требованиями действующей инструкции по делопроизводству, внутренними стандартами и иными внутренними нормативными документами организации, закрепляющими правила подготовки, составления и оформления конкретных видов документов.
2. За реализацию процесса согласования проекта конкретного документа (контроль за соблюдением процедуры и общих сроков согласования, учет замечаний согласовывающих подразделений и их отражение в тексте проекта) несет ответственность инициатор документа.
3. Подразделение, участвующее в процедуре согласования, оценивает проект документа, делает замечания и вносит предложения в рамках своей предметной области и закрепленных зон ответственности, которые установлены в положении о подразделении. Эти замечания и предложения, а значит, и соответствующие экспертные заключения по проекту, являются обязательными.
Пример
Получена виза службы делопроизводства: «Согласовано с замечаниями. Необходимо правильно оформить заголовочную и оформляющую части проекта договора, а в преамбуле исправить номер доверенности подписанта». Инициатор согласования проекта договора обязан устранить эти замечания по оформлению.
Но подразделения – участники процедуры согласования рассматривают проект документа в целом и имеют право формулировать замечания и предложения, не относящиеся к их прямой или смежным зонам ответственности, закрепленным за ними. Инициатор должен обратить внимание на данные замечания и предложения, поскольку все риски решений, оформленных в проекте документа, ложатся на должностное лицо, которое подписывает документ, но в системе согласования эти замечания будут факультативными, дополнительными.
Зоны ответственности подразделений
Анализ процедуры согласования показывает, что главное в ней – не организационная и структурная иерархия участвующих подразделений, а их функции и роли в системе управления организацией и в системе принятия решений. В связи с этим такие функциональные подразделения, как финансовая служба, служба главного бухгалтера, юридическая служба, служба делопроизводства, служба информационных технологий, служба безопасности, контрольная служба и т. д., могут и должны рассматриваться в статусе подразделений/инстанций обязательного согласования проектов документов, особенно в процедурах внутреннего согласования. Этот статус означает, что практически каждый проект решения или документа в маршруте своего согласования должен пройти анализ в данном функциональном подразделении. Без визы, полученной в инстанции обязательного согласования, никакой проект документа не может быть представлен на подписание или утверждение. Для разработки процедур и маршрутов согласования очень важно выявить и регламентировать зоны ответственности подразделений.