Итак, сегодня с нами снова Карл И. Вигерс – бизнес-аналитик гуру и автор ряда знаковых трудов по бизнес-анализу. 27 апреля Карл провел вебинар на тему, озвученную в заголовке статьи. Ниже будет представлен обзор основных тезисов и идей, которые Карл поведал на вебинаре. И сразу небольшое отступление, которое не может не заинтриговать поклонников «библии бизнес-анализа»: Карл готовит к публикации новую книгу “Reconstruction” – это его первая новелла. Автор отмечает, что был сильно увлечен написанием этой книги и очень советует ее к прочтению. К сожалению, ни информации о предполагаемом содержании, ни срока публикации Карл не раскрыл.
На вебинаре Карл с первой минуты дает понять, что речь будет идти о главе 18: “Повторное использование требований” своей книги Software Requirements, 3rd Edition (with Joy Beatty) и для детального погружения в тему советует её почитать (кстати, Карл отметил, что при написании книги эта глава далась ему тяжелее всего). Уверен, многие пропустили данную главу или даже не дочитали до нее, поэтому надеюсь, что краткий конспект вебинара ниже окажется для читателей полезным.
Основные темы вебинара:
- Зачем нужно повторное использование требований?
- Виды повторного использования требований
- Какую информацию стоит рассмотреть на предмет потенциального повторного использования?
- Общепринятые сценарии повторного использования требований
- Как подготовить требования к повторному использованию?
- Факторы, влияющие на успешность либо провал при повторном использовании требований
- С чего начать?
Зачем нужно повторное использование требований?
Пункты ниже Карл, видимо, посчитал самоочевидными (и я с ним отчасти согласен), поэтому привел их без расшифровки и обоснования:
- Увеличение производительности команды разработки.
- Сокращение сроков реализации проекта.
- Уменьшение себестоимости разработки.
- Обеспечение функционального единообразия в рамках семейства продуктов или бизнес-приложений для пользователей: 1) сокращение сроков освоения системы; 2) предотвращение проблем, связанных с неудовлетворенностью пользователя работой системы; 3) повышение удобства использования системы.
- Повторное использование надежных, ранее проверенных требований повышает качество проекта и снижает количество потенциальных ошибок.
- Снижается вероятность переделок в рамках процесса разработки ПО за счет использования ранее верифицированных требований.
Подходы к повторному использованию требований
Карл выделяет три измерения, в рамках которых стоит рассматривать/оценивать/планировать повторное использование информации:
1. Объем повторно используемой информации.
2: Объем изменений.
- Внесение изменений в повторно используемую информацию не потребуется.
- Потребуется внесение изменений в атрибуты требования (приоритет, обоснование, источник и т. п.).
- Потребуется внесение изменений в саму формулировку требования.
- Потребуется внесение изменений в связанную информацию или проектные артефакты (тесты, ограничения дизайна, требования к данным и т. п.).
3. Механизм повторного использования требований.
- Копирование/вставка (максимально простой и понятный вариант):
- из одной спецификации требований в другую;
- из библиотеки повторно используемых требований.
- Ссылка на источник:
- через перекрестные ссылки в текстовом редакторе;
- при помощи обычных гиперссылок
- Использование систем управления требованиями (RMS).
Касательно последнего пункта Карл выделил следующие типовые возможности большинства RMS, связанные с повторным использованием требований:
- Кросс-проектное использование требований из централизованного хранилища данных RMS (без необходимости их копирования, что обусловлено самой архитектурой и парадигмой работы с RMS).
- Хранений истории версий отдельных требований. Эта возможность RMS позволяет повторно использовать какую-либо определенную версию требования или набор связанных требований из истории.
Какую информацию стоит рассмотреть на предмет потенциального повторного использования?
Карл выделяет следующие виды требований как наиболее частые кандидаты на повторное использование:
К тому же, в зависимости от области повторного использования, обратить внимание стоит на следующие виды требований/информации:
В отдельно взятом продукте
- Пользовательские требования
- Функциональные требования
- Требования к производительности
- Требования к удобству использования
В рамках семейства продуктов
- Бизнес-цели
- Модели бизнес-процессов
- Контекстные диаграммы
- Пользовательские требования
- Модели и словари данных
- Требования к удобству использования
- Основные функции
- Требования к соответствию нормативам и законам
- Приемочные тесты
В рамках отрасли
- Модели бизнес-процессов
- Пользовательские требования
- Модели и словари данных
- Требования к соответствию нормативам и законам
- Требования к безопасности
- Приемочные тесты
- Функции продукта
В рамках операционной среды или платформы
- Технические ограничения (размеры и разрешение экрана, жесты для управления на сенсорном экране)
- Интерфейсы ввода данных (сенсорные экраны, считыватели штриховых кодов и пр.)
Также Карл обратил внимание на следующие часто используемые наборы требований, которые обладают бОльшим потенциалом для повторного использования, чем одиночные, изолированные требования:
- Функциональность (включая возможные исключительные поведенческие ситуации) и приемочные тесты;
- Связанные с выполнением нормативов и предписаний бизнес-правила, такие как закон Сарбейнса-Оксли (Sarbanes-Oxley, SOX), отраслевые ограничения, а также ориентированные на выполнение политик в организации директивы;
- «Симметричные» пользовательские функции, такие как, например, отмена и повтор правки (undo/redo). Обычно такие функции логично ожидаемы и идут в связке.
- Объекты данных и соответствующие им атрибуты и проверки в системе;
- Связанные операции, выполняемые с объектами данных, такие как CRUD (создание, чтение, обновление и удаление).
Популярные сценарии повторного использования
В семействах/линейке продуктов (например, программы пакета Microsoft Office):
- Проанализируйте функции набора продуктов на предмет тех, которые являются:
- общими для всех продуктов;
- необязательными – присутствуют не во всех продуктах семейства;
- переменными: в различных продуктах функциональность немного отличается.
- Проанализируйте функции семейства программных продуктов на возможность полного повторного использования (т.е. повторного использования всех результатов работы команды разработки по цепочке, включая компоненты архитектуры, дизайна, код и тесты).
При реинжиниринге и/или замене существующей системы:
- При реинжиниринге и/или замене системы всегда повторно используется часть требований из исходной версии системы, даже если эти “требования” никогда не излагались в письменном виде. Есть мнение что, это не повторное использование требований, а извлечение новых требований (из решения или сопутствующей ему документации), но оставим это на совесть Карла.
- Явно изучите бизнес-правила, учитываемые в текущей системе. Актуальную часть бизнес-правил можно перенести в новую систему.
Как заранее подготовить требования к повторному использованию?
- Фиксируйте все требования. Если требования не записаны, то они не могут быть использованы в другом месте.
- Следите за качеством требований (вспоминаем характеристики качественных требований)
- Подумайте заранее о сферах/границах повторного применения ваших требований.
- Определитесь с достаточным уровнем детализации при составлении требований. Более высокоуровневые требования имеют бОльшую вероятность повторного использования (но это очевидно также может негативно сказаться на успехе текущего проекта).
- Карл рекомендует пользоваться шаблонами, описанными в книге Software Requirement Patterns by Stephen Withall, для составления требований.
Что может помешать или облегчить повторное использование требований?
Препятствия на пути к повторному использованию требований:
- Отсутствующие или некачественно сформулированные требования.
- Синдромы NIH (not invented here) и NAH (not applicable here – проявляется в том, что люди противятся новому процессу или подходу, говоря, что он неприменим к их проекту или организации). У людей часто присутствует субъективное нежелание и сопротивление к использованию чужих решений, несмотря на очевидную выгоду (не изобретайте велосипед, как говорится).
- Частая смена формата документирования требований (как вариант – в силу отсутствия типовых шаблонов документации).
- Непоследовательная организация хранения требований. Например, требования попросту сложно найти, т.к. не существует единого репозитория для их хранения).
- У требований, тесно связанных с определенными средами или платформами реализации, меньший потенциал повторного использования. Для таких требований высока вероятность того, что они вряд ли вам понадобятся когда-либо или же устареют к моменту потенциального использования из-за динамичного развития отрасли.
- Право на интеллектуальную собственность. Задокументированные требования могут принадлежать заказчику как один из разрабатываемых для него артефактов.
Факторы успеха при повторном использовании требований:
- Убедитесь в том, что требования качественны. “Никто не хочет повторно использовать хлам”.
- Организуйте механизм хранения и повторного использования требований. Сложно использовать то, что нельзя найти. Например, можно использовать такие варианты:
- единая сетевая папка, где хранится предыдущая документация требований;
- система управления требованиями, где реализована функция поиска по проектам;
- база данных, хранящая наборы поддающихся повторному использованию требований.
- Поддерживайте связи и зависимости между документами с требованиями.
- Определите и постоянно используйте единую терминологию и словарь данных.
- Культивируйте культуру разработки требований, пригодных для повторного использования, и стимулируйте команды разработки на их использование.
С чего начать?
Карл предлагает следующую последовательность для организации собственной системы для повторного использования требований:
В конце вебинара Карл ответил на ряд вопросов от слушателей. Запись вебинара можно найти здесь.
Автор: Денис Завацкий
