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

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

Что производит аналитик в процессе работы

Системный аналитик разрабатывает требования к программному обеспечению, и эти требования представляют из себя не что иное, как текст. Существует много попыток фиксировать требования исключительно в виде диаграмм, но ни одна из них не стала на 100% успешной. Аналитик всегда производит именно тексты. Это могут быть длинные документы, карточки user story или подписи на диаграммах, но всё это тексты.

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

Схематично этот поток текстов может выглядеть так:

Обобщённый процесс проектирования и производства ПО

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

Обратите внимание, что на каждом из этих шагов происходит 2 процесса: валидация (мы сделали то, что нужно было) и верификация (мы сделали то, что было запрошено, зафиксировано в документах предыдущего этапа, и соответствует внутренним правилам и критериям качества).

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

Что мы знаем про написание текстов?

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

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

Например, российские стандарты регламентируют только оформление документов: шрифт, разделение на абзацы, межстрочные расстояния и т. п. Всё это описано в ГОСТ Р 7.0.97−2016, ГОСТ Р 2.105−2019. В комплексе ГОСТов 34-й серии был руководящий документ РД 50−34.698−90, ныне недействующий, но и он регламентировал только содержание документов, оставляя за рамками рассмотрение формулировок и особенностей языка, которым должно быть изложено это содержание.

Единственный стандарт, в котором есть некоторые рекомендации по текстам требований — это международный ISO 29148:2018, однако он не переведён на русский язык и не принят в РФ, а значит ссылаться на него нельзя.

У совета по системной инженерии INCOSE есть «Руководство по написанию требований» INCOSE-TP-2010−006−02.1. Руководство переведено на русский и включает в себя порядка 100 страниц, тогда как в международном ISO 29148:2018 о тексте и требованиях приведён довольно скромный список рекомендаций. Пожалуй, именно это Руководство является на текущий момент лучшим документом по текстам требований.

Ниже представлен полный перечень рекомендаций из ISO 29148:2018, переведённый на русский язык и его оригинальная версия.

Также в стандарте ISO 29148:2018 представлено два шаблона формулировки требований, на которые стоит обратить внимание.

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

Системный анализ и Разработка требований в ИТ-проектах

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

Посмотреть программу курса

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

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

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

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

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

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

Типовые проблемы в текстах требований

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

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

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

Страдательный залог

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

Рассмотрим пример (здесь и далее приведены примеры формулировки требований из реальных проектов).
Требования со страдательным залогом:

1. Идентификатор учётной записи социальной сети, при помощи которой пользователь впервые вошёл на Портал, присоединяется к профилю пользователя.

2. Актуальная программа курса должна быть размещена на Портале.

Как можно обратить внимание, эти требования не соответствуют характеристике «Завершённости». Требование 1 не полностью определено, ведь мы не знаем, как именно идентификатор присоединяется к профилю? Что это вообще значит? Кто это делает? В какой момент? Те же вопросы можно задать и в отношении требования 2.

Как требования должны звучать (представим, что мы получили ответы на свои вопросы):

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

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

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

СТОП-СЛОВА
Страдательный залог

Следует явно указать актора — того, кто выполняет действие, и не путать его с объектом, над которым выполняется действие

Глаголы с окончаниями -тся и -ться

Расписание размещается
Сертификат должен создаваться

Страдательные причастия в прошедшем времени

Выбор пользователя учтен
Расписание размещено

Причастия вместо глагола или вместе с глаголом «должен быть»

Система обогащена данными
Билет должен быть проверен

Безличные предложения

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

Рассмотрим пример
Требование с безличным предложением:

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

Такое требование, также как и в предыдущем примере, не соответствует характеристике «Завершённость». В требовании недостаёт данных, отсутствие которых приведёт к неполноценности решения. Кто должен иметь возможность просмотреть? Также нарушается характеристика «Проверяемость», так как в требовании не указано, для каких ролей нужно проверять возможность просмотра сертификата.

Как требование должно звучать:

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

Разумеется, понятие «сертификат» должно быть определено в глоссарии.

СТОП-СЛОВА
Безличные предложения

требование должно содержать подлежащее, и это должен быть элемент системы (или роль — для уровня операций)

Косвенный падеж существительных
(не именительный)

Иметь возможность просмотреть…

Отсутствие подлежащего
(предложение начинается сразу с глагола)

Создавать заявки нужно…

Глаголы с окончаниями -тся и -ться

Заявки должны создаваться…

Существительные

возможность
функция
пользователь

Отглагольные существительные

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

Рассмотрим пример
Требование с отглагольными существительными:

Система должна обеспечивать возможность хранения информации о местоположении вагонов.

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

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

Как требование должно звучать:

Система должна сохранять местоположение вагона.

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

СТОП-СЛОВА
Отглагольные существительные

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

Слова с окончанием:
— ость
— ция
— овка
— вие
— ние

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

Слова «возможность» и «информация»

Пример: «Система должна обеспечивать возможность хранения информации о местоположении вагонов»
Правильно: «Система должна сохранять местоположение вагона»

Общее слово вместо конкретного

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

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

Существуют следующие уровни требований:

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

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

Чтобы проверить, является ли конкретное слово общим, можно подставить местоимение «какой-то» и посмотреть, что из этого получится. Если требование с местоимением благозвучно, то перед вами общее слово, если что-то не вяжется, то всё в порядке.

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

1. Система должна обрабатывать информацию о заказах клиентов.

2. Администратору должен предоставляться отчет о действиях пользователя.

Как вы могли заметить, такие требования не соответствуют характеристике «Адекватность уровню». В требованиях отсутствует конкретика.

Чтобы проверить требования на общие слова добавляем местоимение «какой-то», получаем следующие требования:

1. Система должна обрабатывать информацию о каких-то заказах клиентов.

2. Администратору должен предоставляться отчёт о каких-то действиях пользователя.

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

1. Система должна обрабатывать информацию о текущих заказах клиентов.

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

Мы добавили по одному уточняющему слову к каждому требованию. Теперь попробуем подставить местоимение «какой-то» для проверки:

1. Система должна обрабатывать информацию о каких-то текущих заказах клиентов.

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

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

СТОП-СЛОВА
Общее слово вместо конкретного

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

Глаголы

контролировать
согласовывать
осуществлять
поддерживать
обрабатывать
отслеживать
защищать
исполнять
проверять
управлять

Существительные

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

Существительные
во множественном числе

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

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

Указание способа реализации

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

Рассмотрим пример
Указание в требовании способа реализации:

1. Для отправки сообщения пользователь должен нажать на кнопку, ~~расположенную в правом нижнем углу экрана~~.

2. Система должна формировать рекомендации курсов для пользователя ~~с использованием средств машинного обучения~~.

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

“

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

СТОП-СЛОВА
Указание способа реализации

необходимо понимать и соблюдать границу между требованиями и способами их реализации. Для проверки можно использовать вопрос «Это всё еще требование или уже реализация?»

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

Слова «посредством технологии», «с использованием», «применяя»

Названия элементов интерфейса

выпадающий список
модальное окно
радиокнопка
чек-бокс
слайдер
таблица
кнопка
меню
окно

Субъективный, относительный язык

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

Рассмотрим пример
Требование с использованием субъективного языка:

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

Обращаем ваше внимание, что данное требование не соответствует характеристике «Недвусмысленность». Актуальные — это какие?

Как требование должно звучать:

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

СТОП-СЛОВА
Субъективный, относительный язык

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

Непонятно какой

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

Непонятно сколько

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

Штампы

общепринятый
эффективный
оптимальный
приемлемый
эффектный
понятный
разумный

Снятие ответственности

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

Это происходит потому, что никто не любит лишней работы. Аналитик пишет требования «насколько это возможно», потому что он не знает, насколько на самом деле возможно. Он не провел работу, разъясняющую детали и передаёт требования дальше — пусть разработчик сам решает.

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

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

Рассмотрим пример
Снятие ответственности:

Интерфейс системы должен соответствовать рекомендациям WCAG 2.1 ~~как минимум~~ на уровне A, ~~по возможности~~ — на уровне AA.

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

СТОП-СЛОВА
Снятие ответственности

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

Указатели на то,
что требование не полно

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

Не понятно, как именно

в рамках целесообразного
как можно меньше
как можно больше
почти всегда

Места для включения чего угодно

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

Упоминание неизвестных условий

при наличии технологической возможности
если это осуществимо
по мере надобности

Непонятно, обязательно ли это требование

почти всегда
допустимо

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

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

Рассмотрим пример
Несколько требований в одном:

Система управления задвижками должна закрывать входной клапан при температуре выше 80 градусов по Цельсию, когда температура падает, она должна вновь открывать его.

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

Как требования должны выглядеть:

1. Система управления задвижками должна закрывать входной клапан при температуре выше 80 градусов по Цельсию.

2. Система управления задвижками должна открывать входной клапан при температуре ниже 80 градусов по Цельсию.

СТОП-СЛОВА
Несколько требований
в одном

следует соблюдать правило:
одно требование = одна функция системы

Словосочетания

в противном случае
с другой стороны
после чего
при этом

Составные предложения

Наречия

однако
затем
когда
пока

Союзы

также
либо
если
или
но
и

Неоднозначная логика высказывания

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

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

Рассмотрим пример
Неоднозначная логика высказывания:

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

2. Допускается отправка индивидуальных сообщений, рассылка на группу пользователей, рассылка всем пользователям проекта / площадки / платформы.

Требования выше противоречат характеристике «Недвусмысленность», поскольку содержат символы и нечеткие формулировки, которые можно интерпретировать по разному. Косая черта в данном случае — это «И» или «ИЛИ»? Отправка рассылки осуществляется по всем пользователям и проекта и площадки? Или быть может автор имел в виду, что рассылка осуществляется только пользователям проекта или только пользователям площадки? А как интерпретировать во времени одно И другое условие в первом требовании?

Как требование должно выглядеть:

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

СТОП-СЛОВА
Неоднозначная логика высказывания

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

Перечисление через косую черту «/»

Союзы

и/или
не
и

Обобщающие слова

некоторые
кто-либо
любой
такой
все
оба

Порядок

по возрастанию
по приоритету
по срочности
по убыванию
по дате

Неоднозначность указания времени

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

Рассмотрим пример
Примеры неоднозначного времени:

1. Система должна оповещать пользователя об окончании времени выполнения теста заблаговременно.

2. Система должна перекрыть вентиль одновременно с получением сигнала датчика о переполнении резервуара.

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

Как требования должны выглядеть:

1. Система должна оповещать пользователя об окончании времени выполнения теста за 5 мин до истечения отведённого времени.

2. Система должна перекрыть вентиль за 5 секунд от момента получения сигнала датчика о переполнении резервуара.

СТОП-СЛОВА
Неоднозначность указания времени

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

В прошлом

заблаговременно
предварительно
заранее
прежде
раньше
как
до

В процессе

одновременно
в течение
во время
один раз

Итог

последний
наконец
в итоге
после
когда

Другое

самый ранний
мгновенный
такой

Необязательная информация в требовании

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

Рассмотрим пример
Требование с лишним обоснованием:

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

Требование с лишним дополнением:

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

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

Пример общих верхнеуровневых требований к пользовательскому интерфейсу:

1. Требуется обеспечить возможность работы с пользовательским интерфейсом системы без использования указателей и прикосновений.

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

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

СТОП-СЛОВА
Необязательная информация в требованиях

требование не должно содержать обоснования, уточнения и объяснения; можно дать ссылку на описание модели, если это требуется

Исключение:
при использовании user-story или job-story (JTBD)

Слова

обычно
так как
чтобы
из-за
т.к.

Выражения

в результате чего
для обеспечения

Использование скобок

Гигиенические процедуры

Сам текст должен быть хорошо отформатирован, поскольку это упрощает восприятие требований. Нам хотелось бы обратить ваше внимание ещё на несколько рекомендаций:

Структурированные тексты
Отсутствие опечаток, пропущенных слов
Правильная орфография (не путаем -тся и -ться!)
Правильная пунктуация
Используем термины и аббревиатуру из контролируемого глоссария
Указываем единицы измерения величин и шкал
Только полные перечисления (никаких «и т.д.», «и т.п.»)
Не используем сокращения
Не используем указательные местоимения: оно, это, то, он, она, они, им, его

Проверь себя

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

Чем заменить стоп-слова?

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

Информация, данные, параметры, настройки, статистика — приводим конкретные данные и параметры (напр., «личная информация» -> «ФИО и реквизиты паспорта», «данные о продажах» -> «объём продаж за выбранный период в рублях» и т. п.)
Управление — означает, что с объектом производятся какие-то действия, раскрываем — какие. Обычно это CRUD: создание, просмотр, изменение, удаление.
Обработка — указываем конкретные действия, скорее всего это проверка условий, сохранение, преобразование и передача.
Проверка — указываем конкретный список условий, требующих проверки; ещё лучше — «система убеждается, что <условие 1 соблюдено> и <условие 2 соблюдено> и т. д.»
Согласование — указываем конкретные действия, которые осуществляют акторы.
Союзы, скобки и составные предложения — разделяем на несколько требований.
Элементы решения — задаем вопрос «Зачем?»
Субъективные высказывания — приводим к измеримым значениям.

Выводы

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

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

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

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

Посмотреть программу курса

Автор

Юрий Куприянов

Системный аналитик, архитектор программных систем, менеджер продукта

24 года в ИТ
Был разработчиком, тим-лидом, системным аналитиком, архитектором, CTO и директором по продуктам.
Запустил более 40 проектов в различных областях: автомобили, недвижимость, путешествия, медицина, HR, банки, краудсорсинг и управление знаниями, НКО, EdTech.
Ведущий тренинга «Разработка ТЗ на ПО»

Телеграмм канал