Да простит меня читатель за случившееся отступление от темы статьи: формальная модель для классификации требований. Прорвались наболевшие наработки по родственному, но все-таки другому направлению — "Как гарантированно завалить проект" (конструктивное название должно быть таким "Риски ошибок в руководстве проектом: какими они бывают и как их избежать"). Возможно, это действительно станет названием следующей статьи, пока же приведенные язвительные примеры послужат лишь подтверждением тому, что за видимой сухостью и формальностью предлагаемой диаграммы кроются болезненные вопросы, сплошь и рядом возникающие в реальных, "живых" проектах. А для обсуждения подобных наболевших вопросов ой как нужна хорошая их визуализация!
Но вернемся к нашей диаграмме и выделенной там области… и зададимся вопросом: "А почему, собственно, область поддерживающих требований должна иметь именно такой вид?" Почему не так, как на рис. 9?
Другой интересный вопрос: а какой смысл в двух различных подобластях данной области? Чем, по сути, отличаются требования A и C? Но об этом чуть далее.
Рис. 9. Та же область контекста реализации — но при более глубоком рассмотрении
А по перовому вопросу очевидно, что диаграмма на приведенном рисунке является просто проявлением более глубокого подхода и дает более интересные результаты, обсуждение которых следовало бы вынести за пределы данной ознакомительной статьи. Мы же ограничимся упрощенным вариантом (рис. 7) и пойдем далее.
Итак, имеем две зеркальные — как по расположению на диаграмме, так и по своим проявлениям в процессе разработки,— области: