Организация требований для сложных систем · Конспекты по бизнес-анализу

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

Почему одного документа обычно мало#

Леффингуэлл и Уидриг перечисляют типичные причины:

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

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

Иерархия для систем из подсистем#

Для сложных программно-аппаратных систем Леффингуэлл и Уидриг описывают рекурсивную структуру:

Спецификация системного уровня описывает внешнее поведение системы в целом, не касаясь того, как её будут делить на части.
Когда эти требования согласованы, проектировщики разбивают систему на подсистемы, и для каждой подсистемы пишут собственную спецификацию её внешнего поведения.
Разбиение порождает новый класс требований — производные требования (derived requirements), в том числе интерфейсы между подсистемами, которые служат контрактами между ними.
Процесс повторяется уровнем ниже.

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

Требования для семейства продуктов#

Если несколько продуктов используют общие функции и обмениваются данными, авторы предлагают такой набор:

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

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

Будущие требования#

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

Маркетинговые требования и требования к продукту#

Документ маркетинговых требований (marketing requirements document, MRD) фиксирует бизнес-сторону отдельно от спецификации: целевые рынки и сегменты, классы пользователей, конкурентов и отличия продукта от них, среду использования, затраты, ценообразование и каналы сбыта. Он помогает решить, запускать проект или нет, и позволяет заказчикам и разработчикам рано сверить понимание продукта. MRD не входит в спецификацию, но должен появиться раньше неё и служить ей обоснованием.

Как применять#

Опишите, что у вас есть: один продукт или несколько, одна система или система из подсистем, один релиз или много.
Сначала опишите бизнес-взгляд. Для рыночного продукта начните с MRD или документа видения, для семейства — с видения семейства.
Согласуйте требования системного уровня до разбиения. Не давайте командам подсистем писать свои спецификации, пока не определено внешнее поведение целого.
Явно фиксируйте производные требования, особенно интерфейсы между подсистемами, и назначайте каждому интерфейсу ответственного с обеих сторон.
Выберите между ссылками и повтором для семейства продуктов в зависимости от того, есть ли у вас инструмент, умеющий трассировать между документами.
Добавьте раздел будущих требований с собственным статусом, чтобы никто не принял его за согласованные границы.
Трассируйте сверху вниз: каждое требование подсистемы должно ссылаться на системное требование или быть помечено как производное.

Пример#

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

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

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

Подводные камни#

Спецификации подсистем написаны до того, как согласованы системные требования. Каждая команда оптимизирует свой участок, и интерфейсы противоречат друг другу.
Интерфейсы — ничья работа. Производным требованиям к интерфейсам нужен ответственный с каждой стороны.
Будущие идеи смешаны с согласованными границами. Помечайте их, иначе разработчики их реализуют, а тестировщики будут их проверять.
Бизнес-аргументы внутри спецификации. Держите ценообразование и рыночные доводы в MRD или документе видения.

Источники и что почитать#

D. Leffingwell, D. Widrig. Managing Software Requirements: A Unified Approach. Addison-Wesley, 2000. Рус. изд.: Д. Леффингуэлл, Д. Уидриг. Принципы работы с требованиями к программному обеспечению. Унифицированный подход. М.: Вильямс, 2002. Гл. 16.
K. Wiegers, J. Beatty. Software Requirements, 3rd ed. Microsoft Press, 2013. Рус. изд.: К. Вигерс, Дж. Битти. Разработка требований к программному обеспечению, 3-е изд. М.: Русская редакция; СПб.: БХВ-Петербург, 2014. Гл. 10 (сколько спецификаций нужно проекту).