Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

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

Статья написана в соавторстве с Романом Браковым, Владимиром Медведевым и Катериной Носенко.

Меня зовут Олеся Иванова, я работаю бизнес-аналитиком в компании Astound Commerce, а в свободное время преподаю на курсе SupremeBA от компании ImPM, поскольку работаю в бизнес-анализе и ИТ уже больше 10 лет.

В этой статье я:

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

Наверное, каждый аналитик на определенном этапе своей профессиональной жизни сталкивался с негативным отзывом команды или других участников проекта: «Требования плохие!» или «Требования некачественные!». Что делать? Как правильно реагировать на такие заявления?

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

Сравнительная характеристика критериев качества требований в различных стандартах

Для начала разберемся с критериями качества отдельно взятого требования.

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

  • BABOK 3.0 от IIBA;
  • Стандарт ISO/IEC/IEEE: 29148: Systems and software engineering — Life cycle processes — Requirements engineering (правда, доступный мне стандарт датируется 2011 годом, а новая версия вышла в 2018, но надеюсь, в ней не было принципиальных отличий касательно интересующей нас части);
  • Guide to Business Analysis от PMI;
  • Requirements Engineering Fundamentals от IREB.

Большинство критериев качества, описанных в этих документах, совпадают, однако, есть и уникальные характеристики. Давайте сравним.

Критерии качества отдельного требования — сравнительная таблица

IIBA (BABOK)IEEE ISO/IEC/IEEE: 29148PMI (Business Analysis for Practitioners: A Practice Guide)IREB (Requirements Engineering Fundamentals)
Неделимое (atomic)



Единичное (singular)

Полное (complete)Полное (complete)Полное (complete)
Полное (complete)
Последовательное (consistent)Последовательное (consistent)Последовательное (consistent)Последовательное (consistent)
Краткое (concise)


Осуществимое (feasible)Осуществимое (feasible)Осуществимое (feasible)Осуществимое (feasible)
Однозначное (unambiguous)Однозначное(unambiguous)Однозначное(unambiguous)Однозначное (unambiguous)
Приоритезированное (prioritised)



Необходимое (Necessary) Необходимое (Necessary)
Проверяемое (testable)
Проверяемое (verifiable)Проверяемое (testable)Проверяемое (verifiable)
Понятное (understandable)

Понятное (understandable)

Прослеживаемое (traceable)Прослеживаемое (traceable) Прослеживаемое (traceable)


Измеримое (measurable)


Правильное (correct)

Не содержащее деталей реализации (Implementation-free)




Согласованное (Agreed)


Точное (precise)

Критерии качества набора требований — сравнительная таблица

Также в документах от IEEE и IREB приведены характеристики, которым должен соответствовать набор требований (то есть условный документ, содержащий все требования к продукту).

IEEE ISO/IEC/IEEE: 29148IREB (Requirements Engineering Fundamentals)
Полный (complete)Полный (complete)
Последовательный (consistent)Последовательный (consistent)

Однозначный (unambiguous)
Осуществимый (affordable)
Ограниченный (bounded)

Структурированный (clear structure)

Позволяющий изменение (modifiable) и расширение (extendible)

Прослеживаемый (traceable)

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

Критерии качества отдельного требования

Неделимое (atomic) или Единичное (singular)

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

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

Пример.

Формулировка пользовательской истории «Как посетитель кинотеатра я хочу забронировать или купить билет в кино» указывает на то, что здесь на самом живет два совершенно разных требования, кстати, с совершенно разными value.

Та же ошибка в Acceptance Criteria:

GIVEN: Пользователь находится на экране со списком фильмов.

WHEN: Пользователь выбирает фильм.

THEN: Пользователь видит два варианта покупки: посмотреть разово или купить фильм навсегда.

Полное (complete)

Критерий качества «Полное» (complete) означает, что информации, представленной в требовании, достаточно, чтобы продолжать работу. Причем уровень полноты и детализации может отличаться в зависимости от выбранной методологии и фазы проекта. Так, требование может считаться «полным» в гибких подходах разработки, если описания достаточно для старта разработки.

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

Проверка соответствия требования этому критерию осуществляется в двух направлениях:

  1. По форме:
    • проверить, что требование физически размещено в одном месте документа, а не размазано по нему в виде фрагментов текста выделенных другим цветом;
    • убедиться, что текст требования оформлен и закончен (например, не содержит TBD, либо со стейкхолдерами существует договоренность о том, когда будут получены ответы на открытые вопросы);
    • также для проверки полноты требования можно использовать специальные чек-листы: например, в скраме часто используют артефакт Definition of Ready, это как раз пример такого контрольного списка.
  2. По содержанию:
    • убедиться, что в требовании описаны как очевидные (основные), так и неочевидные (ошибочные, альтернативные) варианты использования системы;
    • рассмотреть возможность дополнить текстовое описание функциональности графическими моделями. На рисунке проще увидеть, что какие-то элементы не стыкуются или отсутствуют;
    • наконец, для того, чтобы убедиться, что требование можно брать в работу, стоит обсудить его с теми, кто будет с ним работать. Например, если это требование к системе, то можно получить подтверждение от команды разработки, что им все понятно.

На рисунке ниже приведен возможный пример чек-листа для Definition Of Ready:

Последовательное (consistent) и Прослеживаемое (traceable)

Критерий «Последовательное» (consistent) присутствует во всех стандартах и указывает на то, что требование не должно конфликтовать с другими требованиями, в том числе с теми, которые находятся на других уровнях иерархии (например, требование уровня решения не должно идти вразрез с требованиями уровня стейкхолдеров).

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

1. Частое изменение требований (например, при итеративной разработке), наверное, самая частая причина конфликтов в требованиях.

Здесь нам очень поможет правильно выстроенный процесс управления изменениями. Ведь такие конфликты чаще всего возникают в системе-долгожителе, у которой команды заказчика и подрядчика сменились уже не по одному разу. Они и знать не знают о тех болях и нуждах, решить которые были призваны первые версии продукта. Если при внесении каждого изменения проводится тщательный impact analysis и трассировка всех зависимостей, то вероятность появления непоследовательных требований существенно уменьшается.

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

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

Пример.

Требование уровня стейкхолдеров:

ТС1: Пароль для входа в систему должен содержать не менее 8 символов.

Функциональное требование:

НеправильноПравильно
ФТ1: Если Пользователь в форме регистрации ввел Пароль длиной менее 8 символов, Система отображает сообщение об ошибке с текстом «Пароль для входа в систему должен содержать не менее 8 символов».ФТ1: Если Пользователь в форме регистрации ввел Пароль, не соответствующий критериям указанным в #ТС1, Система отображает сообщение об ошибке. Сообщение об ошибке должно содержать требования к паролю (См #ТС1)

2. Работа над документом нескольких аналитиков — еще один нередкий источник противоречивых требований.

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

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

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

Пример.

Хорошим примером ситуации, когда стейкхолдеры не могут договориться между собой, является необходимость следовать политике GDPR (General Data Protection Regulation).

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

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

А те, кто не работает с Европой (например, Турция, арабские страны, Казахстан), конечно же, совершенно не заинтересованы в том, чтобы усложнять интерфейсы в угоду правилам, которые к ним не применимы, — там своих ограничений достаточно. Конечно, в данном случае стейкхолдеры никогда не договорятся о совместном решении.

Вывод — делим требования по географическим зонам. Например: если на сайте пользователь выбрал европейскую страну или язык одной из европейский стран, то должен использоваться дополнительный набор требований для поддержки GDPR. А если выбран турецкий язык или страна Турция, то используется свой дополнительный набор требований.

Критерий качества «Прослеживаемое» (traceable), по-моему, работает на достижение все той же, более высокоуровневой цели «Последовательное». Если у нас явно указана связь между требованиями разных уровней и между требованиями и деталями реализации, отследить проявления непоследовательности гораздо проще.

Осуществимое (feasible)

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

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

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

Пример.

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

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

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

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

СложноЛегко


Однозначное (unambiguous), Точное (precise) и Понятное (understandable)

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

Легко сказать — сложно сделать. Одна из вариаций закона Мерфи гласит: если что-либо можно понять двояко, это поймут неправильно.

Основные причины неоднозначности

Использование естественного (человеческого) языка. Человеческий язык неоднозначен по природе. Есть прекрасная карикатура, это иллюстрирующая:

Для того, чтобы увеличить однозначность формулировок, используются специальные шаблоны для записи требований. Такие шаблоны подробно описываются в IREB и IEEE:29148. Конструкции языка Gherkin также были придуманы как раз как средство борьбы с расплывчатыми формулировками.

Пример.

Ниже приведу требования, сформулированные согласно стандартам IEEE:29148 и IREB:

  • Система управления заказами должна предоставлять Продавцу возможность посмотреть заказы выбранного пользователя, отсортированные по дате их создания в порядке убывания (новые вверху).
  • Когда оператор переключает рычаг в положение «Пожарная тревога», Система должна включить звуковое оповещение персонала в течение одной секунды после действия оператора.

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

  • Пишите короткими, простыми предложениями, избегайте сложносочиненных и сложноподчиненных конструкций.
  • Формулируйте требования в активном залоге. «Чтобы войти в систему, пользователь должен ввести логин и пароль», а не «Для входа в систему должны быть введены Логин и Пароль» (кем введены?).
  • Избегайте субъективных оценок, таких как: «юзер-френдли», «легкий в использовании», «лучше, чем» (с чьей точки зрения лучше?).
  • Не используйте неподдающиеся проверке термины, такие как: «почти всегда», «регулярно», «значительно», «минимально», «несколько» — обязательно дайте им расшифровку, выраженную в цифрах.

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

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

Здесь поможет единый глоссарий, на который должна быть отсылка при каждом упоминании термина или сокращения.

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

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

Краткое (concise)

Критерий говорит о том, что требование не должно содержать лишнюю, не нужную информацию.

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

  • краткую характеристику систем, с которыми предстоит интеграция;
  • заметки архитектора о возможных рисках при разработке;
  • примечания дизайнеров и т.д.

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

Пример.

Нефункциональное требование и примечание к нему.

НФ#1 Система должна поддерживать 4000 транзакций в день с увеличением числа транзакций до 10 000 в период с 1 декабря по 1 февраля.

Примечание: Увеличение активности в период с 1 декабря по 1 января обусловлено всплеском продаж в предновогодний период. В период же с 1 января по 1 февраля продажи держатся на высоком уровне за счет скидок, которые предлагает продавец.

Необходимое (necessary) и Приоритезированное (prioritised)

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

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

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

Очевидно, что требования с приоритетом «Пока не нужно», «Уже не нужно» и «Вообще не нужно» лучше вынести в отдельный документ или отдельный раздел, чтобы не мешали работе.

Проверяемое (testable, verifiable) и Измеримое (measurable)

Требование «Проверяемое» — в том случае, если оно содержит всю информацию для того, чтобы проверить, удовлетворяет ли система требование или нет.

В принципе, если требование соответствует всем вышеописанным критериям (т.е. однозначное, полное, последовательное и т.д.), то с большой вероятностью оно будет и проверяемым. Характеристика Измеримое (measurable) поддерживает проверяемость, изначально задавая численные критерии для проверки.

Чтобы убедиться, что требование соответствует этому критерию, полезно использовать чек-лист с вопросами, на которые необходимо ответить при написании требования. Например:

  • описана ли роль, для которой должно выполняться требование;
  • описаны ли доступы;
  • соблюдены ли принципы однозначности при записи требования и т.д.

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

Пример.

Требование «Система должна позволять сотруднику несколько раз в 5 лет проходить курсы повышения квалификации» не соответствует критерию «тестируемое», так как непонятно, что такое несколько раз в год. Да и функцию «позволять» в данном контексте тоже непонятно как тестировать — позволять записаться или физически пропустить в аудиторию?

Можно переписать его так: «Система должна позволять сотруднику записаться на курсы повышения квалификации. Максимальное допустимое количество раз указано в <ссылка на бизнес правило, регламентирующее количество курсов в зависимости от стажа>».

Правильное (correct) и Согласованное (Agreed)

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

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

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

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

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

Критерий «Согласованное» (Agreed) подразумевает, что с требованием и его приоритетом согласны все стейкхолдеры проекта.

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

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

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

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

Полный (complete)

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

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

Последовательный (consistent) и Однозначный (unambiguous)

При описании этого критерия авторы не заморачивались: «Документ с требованиями считается последовательным и однозначным только тогда, когда индивидуальные требования последовательны и однозначны».

Так что все, что хотела, я уже сказала при описании этих критериев качества для отдельного требования.

Добавлю только, что с моей точки зрения, критерий «Последовательный» (consistent) как раз правильнее было бы оставить только для набора требований. Так как для отдельно взятого требования «в вакууме» он нерелевантен: психически здоровому человеку довольно сложно создать требование, которое противоречит само себе.

Но поскольку абсолютно все стандарты описывают этот критерий в разделе «Критерии качества отдельного требования», мне приходится смириться с тем, что, видимо, я чего-то недопонимаю. С удовольствием подискутирую на эту тему.

Осуществимый (affordable) и Ограниченный (bounded)

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

Понятно, что жизнь может внести коррективы даже в самые лучшие планы, но как best practice не стоит вносить в SRS или беклог требования, которые вы изначально не собираетесь реализовывать или планируете реализовывать по принципу «только одно из». Лучше определиться заранее, зафиксировать актуальное решение в документе, а потом изменить его, если будет такая необходимость.

Критерий «Ограниченный» (bounded) говорит примерно о том же: не вписывайте в требования ничего сверх того, что действительно необходимо стейкхолдерам.

Пример из практики.

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

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

Структурированный (Clear Structure)

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

Документ или пакет документов должен быть подготовлен и структурирован таким образом, чтобы, с одной стороны, его было легко читать последовательно, без «прыганья» по разным разделам, а с другой — чтобы представители каждой роли могли безопасно пропустить те разделы, которые к ним не относятся. Возможные способы структуризации:

  • по классам пользователей: этот способ удобен, когда у системы много пользователей с очень разными сценариями использования;
  • по режимам работы системы;
  • организация документа в виде списка функций (feature list или feature map).

Трансформируемый (modifiable) и Расширяемый (extendable)

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

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

  1. Фиксируйте каждое изменение в логе изменений с указанием:
    • даты;
    • автора;
    • идентификатора требования, которое изменяется;
    • причины изменения;
    • ссылки на задачу, имплементирующую изменение.
  2. Избегайте копипаста функциональности. Конечно, документ легче читать, когда не нужно скакать по ссылкам. Но добиться актуальности требований, если нужно править многочисленные дубли, — непосильная задача.
  3. По возможности группируйте новую, добавляемую в документ функциональность в отдельный раздел. Нет ничего хуже задачи на разработку вида: «Внедрить изменения, выделенные в документе красным». Если же изменения и в самом деле «размазаны» по всему документу, лучше сформулировать, что нужно менять непосредственно в теле задачи, а требования обновить уже после реализации.

Прослеживаемый (traceable)

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

Выводы

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

👍ПодобаєтьсяСподобалось14
До обраногоВ обраному16
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Зашел в статью с linkedIn. Мощная статья как для «БА тематики» на доу. Спасибо авторам!!!

Наверное, каждый аналитик на определенном этапе своей профессиональной жизни сталкивался с негативным отзывом команды или других участников проекта: «Требования плохие!» или «Требования некачественные!». Что делать? Как правильно реагировать на такие заявления?

В моей практике такие отзывы большей частью вызваны были только ограничениями времени/ресурсов на БА ((

Прочел — и сразу такая ностальгия по медицинским проектам накатила! Нигде в другом месте я не видел что бы требования писали по стандартам, да и вообще что бы хоть кто-то занимался требованиями.
Везде аждайл, скрам, канбан ... вместо четких требований — карточки с одним предложением. Лепи как знаешь — передвигай по доске — потом клиент на демо скажет что он хотел совсем другое — прилепим новую карточку на следующий спринт. Аджайл — это же про гибкость, вот и требования «гибкие», и результат «гибкий» и вообще весь процесс «куда кривая вывезет».
Кстати — имел опыт работы с бизнес — аналитиками из «долины». Так вот они про такие требования и не слышали! Их «юзер стори» — это исключительно «хотелки» клиентов и исключительно «happy path». И спрашивать их что делать если что-то пошло не идеально — бесполезно!
Например юзер стори: «пользователь вводит имя и фамилию и регистрируется на сайте».
Вопрос: Что делать если имя и фамилия совпали с другим пользователем?
Круглые глаза: а что такое может быть? Ну мы не знаем — придумайте что нибудь!

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

Завжди радий бачити на доу технічну статтю високої якості. А тут подвійне «бінго»: на рівні з якістю ще й хороша подача. Merci

Хороший подход, классная статья!

Исчерпывающий анализ, благодарю!

Добавлю только, что с моей точки зрения, критерий «Последовательный» (consistent) как раз правильнее было бы оставить только для набора требований. Так как для отдельно взятого требования «в вакууме» он нерелевантен: психически здоровому человеку довольно сложно создать требование, которое противоречит само себе.

Возможно, здесь может помочь разрешить недоумение первая часть из определения Consistent, данная в BABOK v3 (7.2.4):

Consistent: aligned with the identified needs of the stakeholders and not conflicting with other requirements

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

Да, возможно. Хотя «aligned with needs of stakeholders» подразумевает наличие, кроме нашего сферического требования в вакууме, хотя бы еще одного требования уровня стейкхолдера или бизнеса.

По юзеркейзам: добавьте одно формальное требование, которое устраняет до 2/3 противоречий, многие из которых вылезут уже на поздних этапах. Каждая хотелка должна начинаться словами Я хочу. Если же вместо этого слова «должно быть» — делать её бесполезно, всё равно получится плохо и не то что требовалось. Почему так? Всё дело в «я». Нужно (в смысле, я хочу) чтобы хотелку писал именно тот человек, которому это нужно. А не бюрократ, которому виднее «как надо», и который будет рассказывать потом что «очевидно», что «имелось в виду», что «вы сами должны понимать».

К сожалению, просто начинать требование с «я хочу» — не универсальная таблетка. В статье приведены примеры того, как набор таких «я хочу» может в какой-то момент оказаться просто набором противоречащих друг другу утверждений.

Универсальных таблеток не существует. А вот «возрастные болезни» организационных алгоритмов — очень даже, и они таки умеют подгадить.

Бюрократия такая бюрократия.
Реальность куда проще: качество → производное от требований. Нельзя чтобы критерии качества ставились сами по себе, потому что «так надо». Когда требование возникло, тогда критерий и добавлять. Нет требования → нет критерия качества. Зато есть бесполезная трата время-денег на ему соответствие, если его добавили бюрократы.

Вы же с людьми работаете. С людьми образованными, допущенными к бизнес-процессам после 20 лет жизни (вы не представляете, насколько это атавизм и бюрократия). К этому времени у людей уже развито шаблонное мышление до того уровня, где уже поздно что-то менять. Вам нужно не строить систему «с нуля», а полагаться на существующие шаблоны. А шаблоны таковы, что ни одна задача не решается в отрыве от всего остального. И это «всё остальное» может на 90+% перекрываться информационной избыточностью (цифра 90% считается критерием зоны комфорта). То есть, делая запрос на изменения, будет в 10 раз дешевле [в идеальном случае] навести связи на живую систему, готовую предоставить данные. Реальный коэффициент экономии немного ниже, какие-то данные проще запросить сразу, заранее зная что это будет нужно. Но именно эти данные и подчиняются правилу Парето — 80% данных обойдётся в 20% затрат на их сбор.

На деле правило Парето про 80/20 не более чем журналистская гипотеза про распределение доходов (сейчас уже примерно 97/3), но в ней есть доля научной истины: распределение Парето (названное так из-за «правила»). И касательно сбора данных будьте готовы к распределению 96/4 для юзер-кейзов и фидбека, и до ∞/0 при бюрократическом вотерфолле.

Попробуйте уйти от

ФТ1: Если Пользователь в форме регистрации ввел Пароль...

к

ФТ1: Когда Пользователь указал Пароль...

А также уйти от «ФТ1», назвав статусы более корректными и понятными именами.

Походу то просто сокращ. для «функциональное требование».

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

Я пишу требования в разных форматах — и согласно iso/ieee, и use case, и user story. Все зависит от проекта, условий договора или даже конкретного требования.
Опыт показал (и Джефф Паттон это в своей книге подтвердил :) ), что даже при идеальной работе по scrum иногда проще и эффективнее записать требование как «пусть система тогда-то сделает то-то и то-то», чем расписывать каноническую US.
Бывало и комиксы рисовала — лишь бы заказчик и команда были на одной волне.

Вообще источник от Ireb рекомендует избегать слова „Когда” для условия, при котором выполняется требование.
Цитата:
„Typically, requirements do not document continuous functionalities, but functionalities that are performed or provided only under certain logical or temporal constraints. In order to easily differentiate between logical and temporal conditions, we choose the temporal conjunction as soon as for temporal conditions and the conditional conjunction if for logical conditions.
The conjunction when makes not clear whether a temporal or a logical condition is described and should therefore be avoided.”

Я не фанат бездумного следования шаблонам, но в данном случае „if” = „если” мне кажется более уместным.

Підписатись на коментарі