Критерии качества требований

Текстовая расшифровка двенадцатого урока курса Введение в профессию аналитика.

Давайте теперь поговорим о критериях качества требований. Требования мы разрабатываем, но насколько они являются хорошими или плохими? По этим критериям определяется качество работы аналитиков.

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

Этот список я взял из статьи бывшего директора по маркетингу IBM (ссылка на статью здесь приведена).

Что такое хорошее требование? В данном случае речь идёт об отдельном требовании, можно сказать, атомарном.

Требование должно быть корректным. Требование должно быть полным в том смысле, что оно выражает какую-то идею. Должно быть недвусмысленным. Должно согласовываться с другими требованиями, не конфликтовать с ними. Собственно, одна из задач аналитика — это поиск конфликтующих требований и методов разрешения этого конфликта. Требование должно быть проверяемым, то есть если уж мы описали требование, то у нас должен быть способ проверить, что оно реализовано. Требование должно быть трассируемым. В данном случае под этим понимается, что у нас должна быть возможность ссылаться на это требование. Чтобы оно принимало участие в трассировках, у него должен быть какой-то уникальный идентификатор. Требование должно быть выполнимо в рамках запланированных бюджета и сроков. Требование должно быть независимым (в оригинале — модульным), то есть оно может быть изменено без чрезмерных последствий для всего проекта. И должно быть инженерно-независимым, то есть не должно описывать конкретный способ реализации. Если вы помните, когда мы разбирали, что такое SRS (спецификации требований), то говорили, что требования должны формулироваться таким образом, чтобы по этой спецификации их можно было реализовать, например, на разных платформах или с разным пользовательским интерфейсом.

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

Если говорить об SRS. Вот этот стандарт, о котором я говорил: IEEE 830. В нём тоже есть критерии качества, но это критерии для оценки не отдельного требования, а их совокупности, всей спецификации в целом. Они перечислены прямо в этом стандарте, а здесь переведены на русский язык.

В стандарте для каждого из этих пунктов есть отдельные абзацы, где описывается, что имеется в виду. Спецификация должна быть корректной, однозначной (однозначно трактуемой). Спецификация должна быть полной, т. е. должна описывать продукт со всех сторон. Непротиворечивой, то есть требования не должны противоречить друг другу. Упорядоченной по значимости или устойчивости. Спецификация должна быть проверяемой, то есть если мы описали требования в спецификации, то мы должны иметь способ убедиться, что эти требования реализованы. Модифицируемой, то есть она должна быть составлена таким образом, чтобы была возможность её изменять. И отслеживаемой — здесь речь идёт примерно о том, о чём она шла на предыдущем слайде: трассируемой, то есть мы должны уметь отслеживать изменения в спецификации.

Это критерии качества целой совокупности требований.

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

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

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

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

Давайте сначала посмотрим, какие критерии качества применяются к User Story, которая, собственно, является основным методом представления требований в Agile подходах, в Agile практиках. Они здесь перечислены.

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

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

Обсуждаемой. Очень важное свойство, потому что первоначально сформулированная User Story — это только повод для обсуждения. Она не должна сразу пускаться в реализацию, а должна пройти обсуждение всей командой разработки для того, чтобы к ней добавить какие-то уточнения, критерии приёмки, комментарии и т. д. Только после этого обсуждения она будет пригодна для запуска в реализацию. Это свойство говорит о том, что User Story должна быть изначально написана так, что бы она была пригодна для обсуждения.

Полезная. Это вообще очень важный принцип Agile: любая доработка должна принести какую-то пользу пользователю. И, соответственно, пользовательская история должна давать какую-то пользу для развития продукта.

Эстимируемая, или, по-русски, оцениваемая. Пользовательская история должна быть пригодной для оценки трудоёмкости, то есть сколько сил вы на неё потратите для того, чтобы её реализовать. Если она не поддаётся оценке, то, возможно, её нужно разбить на части или дополнительно проанализировать. Для того, чтобы User Story, как требование, предназначенное для реализации, до этой реализации дошло, оно обязательно должно пройти процедуру оценки.

Компактная. То есть небольшая. Не буду здесь вдаваться в подробности.

Тестируемая. Это тоже обязательно. User Story должна быть проверяема. После того, как мы реализовали это требование, мы должны убедиться, что оно действительно реализовано, и реализация соответствует тому, что в этом требовании описано.

По начальным буквам вы видите так называемый принцип INVEST. Специально подбирали слова, что бы появилась такая аббревиатура, легко запоминаемая. И это, собственно, основной набор критериев хороших требований, которые используются в Agile.

А теперь давайте мы их сравним. Я вынес в левую часть свойства хороших требований по тому списку IBM, из которого торчат уши водопадного процесса. А справа описал критерии хорошей пользовательской истории. Посмотрел, какие из них соответствуют друг другу, и нашёл, на самом деле, только два. Тестируемая пользовательская история — это то же самое, что проверяемое требование. А независимая пользовательская история — это то же самое, что модульное требование (я говорил, что здесь тоже должно быть слово «независимое»). А все остальные критерии в чём-то друг друга заменяют, но не полностью, а в чём-то даже противоречат.

Например, полнота требования — этот критерий неприменим к пользовательской истории потому, что она должна быть обсуждаемой. И она станет полной и, может быть, однозначной, только после этого обсуждения. Перед тем как, запустить её в разработку, она обрастёт какими-то уточнениями, комментариями.

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

Оцениваемая. Опять же, другой подход совершенно. Пользовательские истории предназначены сразу и для управления требованиями, т. е. чтобы сразу их пускать в реализацию. Для этого нужна их оценка, чтобы понимать, сколько таких требований мы можем включить в одну итерацию. Мы должны понимать, сколько сил каждая из них у нас отберёт или времени. Слева, отчасти, может быть похож критерий — выполнимая в рамках бюджета и сроков. Но не очень понятно, как это можно оценивать. Для того, чтобы требование было выполнимым, мы всё равно должны его оценить, но явно этот критерий здесь не прописан.

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

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

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

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

Предыдущий урок: Основные форматы представления требований