Практические критерии некачественных системных требований

Не устаю обращаться к различного рода классификационным и методологическим трудам по разработке требований и проектированию ИТ-систем и решений. То новый стандарт по классификации требований (правда, довольно сырой, но для системного представления в голове нефункциональных требований, с большинством из которых в общем-то имел дело довольно мало - достаточно), то руководство по сертификации IREB CPRE. И пока курс доллара бил годовые рекорды, помогая зеленому пупырчатому земноводному в нелегком деле оттягивания сертификации, было время еще раз ознакомиться с некоторыми интересными данными и даже поделиться полученными знаниями.
Очень часто в моей практике я сталкиваюсь с разработкой документов, описывающих требования, на довольно высоком (в плане абстракции, а не качества) уровне. Впрочем, если следовать концепции Сергея Нужненко, то например, Техническое задание - это не документ, описывающий системные требования, а верхнеуровневых базовый контракт между Заказчиком и Исполнителем. Однако, в моей практике были примеры, когда более детальных документов с требованиями уже не было, и работы, а затем тестирование и приемка выполнялись именно по тем требованиям, которые были указаны в соответствующих разделах ТЗ. Поэтому важно при формировании системных требований в источнике любого уровня абстракции избежать базовых ошибок, которые могут привести к невозможности использовать эти требования в дальнейшей разработке. Итак, источник, который я изучал, выделяет следующие ошибки.
Номинализация. За этим хитрым словом, являющимся точной калькой англоязычного термина (я бы перевел как "осуществление", но в русском языке это слово уже имеет другой смысл), скрывается превращения процесса в событие в тексте. Таким образом весь длительный контекст процесса теряется, остается только одно существительное, описывающее процесс недостаточно полно и, что гораздо опаснее для качества требования, недостаточно однозначно.
Пример номинализации: В случае отказа системы необходимо произвести перезапуск. Под событийным существительным "отказ системы" скрывается большой процесс, имеющий определенный перечень критериев, процедур и характеристик, без знания которых ни разработчик, реализующий это требование, ни тестировщик, проверяющий его выполнение, ни тем более представитель заказчика, пытающийся понять, получил ли он то, что ожидал, не смогут понять "что имел ввиду автор" из-за разности восприятия.
Хорошим способом избегать номинализации является более подробное раскрытие всех событийных существительных и важных терминов с указанием их характеристик и критериев.
Использование обобщенных существительных (или существительных без конкретики). Уже вторая ошибка про существительные, можно подумать, что существительные в требованиях - враги номер один. Однако, реальность такова, что стараясь формализовать требования, разработчики (которыми в общем-то не всегда являются системные аналитики и архитекторы) делают их слишком "рафинированными", осторожными и неконкретными. Надеясь, что все поймут, о чем шла речь. Поймут, только каждый по своему. Итак. Данная ошибка проявляется в виде следующих формулировок: Данные, обрабатываемые системой, должны выводиться на устройство пользователя. Какие именно данные? Все, обрабатываемые системой? А какого именно пользователя? Любого? А на какое именно устройство? Если у пользователя их пять - на все сразу?  Очевидно, что если довести данное требование до абсурда, можно требовать от Исполнителя невозможного, однако это невозможное будет полностью соответствовать требованию, которое написано неконкретно и неоднозначно.
Чтобы избегать подобных ситуаций, рекомендуется максимально использовать уточняющие определения и причастные обороты к существительным, употребляемым в тексте требования.
Использование универсальных определений. Эта ошибка, как правило, вызвана попыткой избежать предыдущей, однако больше подходит под поговорку "вместе с водой выплеснули ребенка". Примером такой ошибки может быть следующее требование: Все действия в системе должны быть доступны пользователю посредством применения манипулятора "мышь". На самом деле под "всеми" действиями тут имеются ввиду только действия, связанные с управлением графическим интерфейсом - но откуда это следует? Из здравого смысла? Забудьте. Применение универсальных определений можно распознать по категоричным "все", "всё", "всегда", "никогда" и иные слова из лексикона эмоционально-неустойчивой девочки-подростка с юношеским максимализмом.
Неполные условные конструкции. Эта ошибка является уже более специфической, чем просто использование некорректных лексических конструкций, так как находится в рамках математической логики. Она возникает тогда, когда требование описывает какое-либо алгоритм с несколькими ответвлениями в зависимости от условия, и игнорирует какие-либо ветви дерева вариантов. Пример: Система электронного меню ресторана должна предоставлять пользователям старше 21 года возможность заказа любого крепкого алкогольного напитка. А что делать пользователям моложе 21? Что система должна демонстрировать им, какие напитки они могут заказать? А также что делать с безалкогольными напитками, их достигший 21 года пользователь имеет право заказывать? Более корректно данное требование должно быть сформировано следующим образом: Система электронного меню ресторана должна предоставлять пользователям старше 21 года возможность заказа любого напитка, а пользователям, не достигшим 21 год возможность заказа любого безалкогольного напитка.
Неполные процессные глаголы. Эта ошибка также является более специфической, и  выявить ее обычно сложнее. Она возникает в ситуациях, когда в требовании указывается какой-либо глагол, описывающий процесс, но не указываются требуемые параметры данного процесса. Например, глагол "передавать" описывает процесс, имеющий как минимум три параметра: что, от кого и кому. Пример данной ошибки: Для аутентификации вводятся имя пользователя и пароль. Из данного требования абсолютно непонятно, для аутентификации где вводятся имя пользователя и пароль, а также куда именно они вводятся. Тут следует отметить, что данная ошибка в языке оригинала (руководство на английском языке) звучит более правдоподобно, так как сформулирована в пассивном залоге (To log a user in, login must be entered), и в качестве решения рекомендуется в том числе избегать употребления пассивного залога. Тут я бы переформулировал эту рекомендацию так, чтобы она была применима в русском языке. Например, требование, звучащее следующим образом: Для аутентификации необходимо ввести имя пользователя и пароль - будет также некорректно, как и предыдущее. Для исключения этой проблемы я бы предложил в общем случае  указать параметры процесса Для аутентификации пользователя в системе пользователю необходимо ввести имя своей учетной записи и пароль в окне аутентификации системы. При этом можно не перестраивать предложение так, как это предлагает оригинальное руководство, но...

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

Объект автоматизации из воздуха

В очередной раз столкнувшись с критикой ГОСТ 34-ой серии, описывающей требования к проектированию автоматизированных систем, вспомнил об одной интересной коллизии, с которой сталкивался постоянно по ходу применения ГОСТ 34.602-89 (стандарт на ТЗ, если кто забыл). Это характеристика объекта автоматизации.
Кажется, уже все давно решили - и решили небезосновательно, -  что объектом автоматизации АС является деятельность (читай, процессы). Справедливости ради замечу, что в самом ГОСТ я конкретного указания на это не нашел - ГОСТ определяет содержимое раздела "Характеристики объекта автоматизации" следующим образом:
"2.5. В разделе «Характеристики объекта автоматизации» приводят:

• 1) краткие сведения об объекте автоматизации или ссылки на документы, содержащие такую информацию;
• 2) сведения об условиях эксплуатации объекта автоматизации и характеристиках окружающей среды.".

Но и каких-либо противоречий с формальной логикой тут нет - автоматизация необходима в первую очередь для деятельности (бизнес-процессов), а не для организаций, филиалов и подразделений.
Однако, если с тем фактом, что под объектом автоматизации понимаются процессы заказчика, большинство согласно, то с тем, откуда появляются эти процессы, возникают проблемы. Согласно, например, COBIT, бизнес-процессы определяют цели и требования к ИТ-процессам, которые в свою очередь определяют цели для ИТ-систем. И хорошо, если разработка АС осуществляется в рамках комплексных мероприятий по ИТ-консалтингу, где этапу технического проектирования предшествовали бизнес- и концептуальное проектирование системы, с анализом бизнес-процессов, "дорожной картой" развития систем автоматизации этих бизнес-процессов и даже какими-нибудь концептуальными моделями архитектуры разного уровня и степени детализации. В этом случае наличие бизнес-процесса идентифицируется и подтверждается отсылкой к диаграммам в какой-нибудь Business Studio с резолюцией "учи матчасть". Но что делать, когда разработка АС - это независимое (как сейчас модно говорить, суверенное) мероприятие, направленное на достижение различных целей, в диапазоне от "нужно внедрить это самое.." и "начальство постановило" до "у нас тут есть одна идея" и "глядите, какую классную штуку видел у конкурентов"?
Многие менеджеры или аналитики с техническим бэкграундом (к коим в какой-то мере отношусь и я) могут сказать, что соответствующая автоматизируемая деятельность появляется только с применением АС - а значит бизнес-процесс в исходном состоянии отсутствовал. В какой-то степени это может быть правдой, например, в случаях, когда АС создается, например, в целях исполнения федерального законодательства (например, взаимодействие с СМЭВ). Однако такая ситуация со стороны сильно напоминает анекдот про то, что совместная жизнь позволяет людям решать вместе множество проблем, которые бы не возникли, если бы они жили по отдельности.
В реальности ИТ-система не может и не должна создавать бизнес-процесс, так как создание системы не может выполняться ради самого создания системы. И даже если деятельность, автоматизируемая создаваемой системой, фактически появляется одновременно с АС, на мой взгляд крайне нежелательно об этом сообщать.
В этом случае я рекомендую опираться на зрелость автоматизируемого процесса. В том же COBIT описана крайне адекватная модель зрелости процессов, которая, в отличие от оригинальной модели CMMI, на мой взгляд, может быть применена к любым процессам. Согласно этой модели, первые три уровня зрелости определяются как:

• 0. Не существует. Полное отсутствие каких-либо процессов управления ИТ. Организация не признает существования проблем в ИТ, которые нужно решать, и, таким образом, нет никаких сведений о проблемах.
• 1. Начало (Анархия). Организация признает существование проблем управления ИТ и необходимость их решения. При этом не существует никаких стандартизованных решений. Существуют случайные одномоментные решения, принимаемые кем-то персонально или от случая к случаю. Подход руководства к решению ИТ-проблем хаотичен, признание существования проблем случайно и непоследовательно.
• 2. Повторение (Фольклор). Существует всеобщее осознание проблем управления ИТ. Показатели деятельности и ИТ-процессов находятся в развитии, охватывая процессы планирования, функционирования и мониторинга ИТ. Деятельность по управлению информационными технологиями описана и интегрирована в процесс управления организацией. Выбраны для улучшения и/или контроля те ИТ-процессы, которые влияют на основные бизнес-процессы предприятия. Эффективно выполняется планирование и управление инвестициями. Руководство организации регламентировало меры по управлению ИТ, а также методы управления и оценки, но процесс не был принят в организации. Не существует формализованного обучения, набора взаимосвязанных стандартных процедур управления, ответственность возложена на сотрудников. Сотрудники контролируют процессы управления с помощью проектов и ИТ-процессов. Ограниченные инструменты управления выбираются и внедряются для сбора метрик управления, но не используются в полном объеме из-за недостатков в оценке их функциональности. 

Логично предположить, что если возникла необходимость автоматизации какой-либо деятельности, значит эта деятельность так или иначе выполняется, пусть и крайне плохо, нерегулярно и наверняка незаметно для ее участников. Поэтому уровень зрелости "0.Не существует" следует исключить. Остальное на ваш выбор. В зависимости от степени реализации автоматизируемой деятельности у Заказчика, раздел "Характеристики объекта автоматизации" ТЗ по ГОСТ 34.602-89 можно наполнить переработанным описанием соответствующего уровня зрелости процесса, таким образом дав понять, что разрабатываемая система не только автоматизирует бизнес-процесс, но и повысит его зрелость (иногда - довольно существенно, так как даже самые типовые автоматизированные системы того или иного класса содержат довольно большое количество контролей автоматизируемых процессов).
В общем, я, как всегда, за вдумчивый и обоснованный подход к разработке любых проектных историй для бизнеса, так как это позволяет не только аргументировать и обосновать те или иные проектные решения, но и связать воедино и затем отследить все потребности и выгоды бизнеса в реализуемых ИТ-решениях.