Проверка требований

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

Двусмысленность требований

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

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

"Золочение" продукта

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

Эта ситуация возникает в случае, когда, во-первых, в коллективе Разработчика присутствуют творческие личности (ведь далеко не всякая команда станет проявлять инициативу и делать сверх того, о чем ее просили), во вторых - существует разрыв в прохождении информации от Заказчика к Разработчику. Инициативный разработчик "золотит" продукт из самых лучших побуждений, но, возможно, он плохо знаком с бизнес-процессом Заказчика и заложенные им "фичи" попросту не будут востребованы.

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

Автору пришлось однажды присутствовать в одном очень показательном диалоге, где он участвовал в качестве Разработчика, сдающего продукт (АИС для склада материалов), еще присутствовали пользователь новой системы и инвестор проекта. Ирина (пользователь): мне неудобно работать в этой программе. Она не учитывает размеры баночек в литрах. Павел (инвестор): без этого спокойно можно обойтись, достаточно того, что есть учет материалов по классификатору и 2 единицы измерения - в литрах и килограммах. Ирина: а мне этого недостаточно, я веду учет в баночках! Павел: а я тут хозяин, здесь все мое и мне твой баночный учет не нужен! Ирина: а я все равно буду работать, как я привыкла! Диалог длился около получаса и последнее слово осталось, конечно, за Павлом, программу переписывать не пришлось.

Минимальная спецификация

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

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

Минимальная спецификация уместна, если имеет место наличие одновременно трех обстоятельств (объединение по "И"):

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

Другой вариант работы по мини-спецификации: Заказчик и Разработчик понимают, что создание развернутой спецификации оттягивает окончание выпуска готового продукта, что главная цель проекта - продукт, а не документация и готовы к плотному сотрудничеству в процессе его создания. Это - путь так называемых agile-методологий разработки ПО, подробнее см. в http://www.agile.org.

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

Пропуск типов пользователей

Корпоративные АИС создаются для того, чтобы быть использованными различными группами пользователей. Может сложиться ситуация, в которой в группу представителей Заказчика, участвующих в формировании требований, попадут наиболее инициативные персоны предприятия, которые, по всей видимости, смогут донести свой голос до представителей Разработчика. Те же категории пользователей, у которых не найдется активных представителей, могут оказаться "за бортом" автоматизации. Именно эта ошибка формирования требований называется "пропуск классов пользователей". Чтобы ее избежать, представитель Разработчика должен объективно оценить организационную структуру предприятия и его бизнес-процессы и вдумчиво подойти к выбору ключевых персон, проведение интервью с которыми поможет сформировать целостную картину требований к создаваемой АИС.