Повторное использование требований

Главные идеи#

Что даёт повторное использование#

Вигерс и Битти перечисляют выгоды повторного использования (reuse): работа с требованиями идёт быстрее и дешевле; растёт согласованность внутри приложения и между родственными продуктами (например, одинаковое форматирование текста во всём семействе продуктов сокращает обучение); меньше дефектов и переделок; ревью проходят быстрее, потому что текст уже проверяли; оценки точнее, потому что известно, во что требование обошлось в прошлый раз. И всё же повторное использование встречается реже, чем можно было бы ожидать. По опросу, на который ссылаются авторы (Черняк, Chernak), требования повторно используют лишь около половины организаций, а главным препятствием оказалось низкое качество существующих требований.

Три измерения#

1. Объём: от отдельного утверждения — к утверждению с атрибутами, к утверждению с контекстом (тесты, ограничения, бизнес-правила), к набору связанных требований, к набору с дизайном и вплоть до полного пакета из требований, дизайна, кода и тестов, например компонента обработки ошибок или журналирования.
2. Степень изменения: используется как есть; меняются только атрибуты (приоритет, обоснование); меняется формулировка; меняются и связанные элементы, например тесты.
3. Механизм:

Авторы предпочитают подход с версиями: проект Б может оставаться на версии 1 требования, пока проект А переходит на версию 2.

Что стоит использовать повторно#

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

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

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

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

Барьеры#

• Отсутствующие или плохие требования — самый частый барьер.
• «Изобретено не здесь» (not invented here, NIH): нежелание брать материалы другой команды; иногда оно разумно, если материалы плохо задокументированы.
• «У нас это неприменимо» (not applicable here, NAH): «у нас всё по-другому» — часто это замаскированное сопротивление.
• Разные стили написания и уровни детализации, из-за которых трудно распознать совпадение.
• Встроенные проектные ограничения, которые привязывают требование к одной платформе.
• Разная организация требований в проектах (по процессам, по подсистемам, по подразделениям).
• Права собственности: требования, написанные для заказчика, юридически могут принадлежать этому заказчику.

Что помогает повторному использованию#

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