Причина, которая вызывает большую путаницу -- двоякое назначение ТП. С точки зрения инженера ТП должны быть живым документом, но из соображений коммерческих и правовых он занимает место эталонного документа на все время работы над проектом. Эти две цели совершенно различны. Когда они смешиваются, мы получаем комедию инженеров, не обремененных юридическими знаниями (что на самом деле так), пытающихся написать "Декларацию независимости", в то время как критические моменты бизнес процессов остаются неисследованными.
Иногда единственный способ выйти из этого положения -- написать два документа. Один определяет контрактный минимум и, если придерживаться некоторых методик, может быть с успехом написан полностью пользователем. Другой -- это живой, внутренний документ, который говорит нам, что же "приведет пользователя в восторг". Это то, чем мы стараемся руководствоваться в его интересах. Как удовлетворить пользователя, если единственной подсказкой как это сделать, является нечто, служащее нашим коллегам из коммерческого подразделения на поле закона? Рамки, до которых потребитель видит "настоящие ТП" зависят от коммерческих соображений.
Будьте очень осторожны по отношению к "средствам интегрированного отслеживания свойств", призванных получить ваши ТП и пропустить их положения через проектирование и тестирование, превращая в код. Такие средства часто забывают, что требования можно удовлетворить не делая что-то, что ряд требований может быть реализован в нескольких сегментах кода, без прямого соответствия между требованиями и сегментами, и что очень трудно протестировать важные общие требования отдельными тестовыми инструментами. Это не значит, что такими инструментами не следует пользоваться -- для задач конфигурирования и ввода данных они подходят прекрасно. Некоторые даже могут отследить свойства отдельных групп классов для GUI. Но для обычных требований черного ящика на "уровне пользователя" они искажают то, что могло быть написано в ТП, или навязать стиль разработки, требующий утомительного ручного кодирования отдельных свойств, вместо использования абстракций везде, где это возможно.
Требования к программному обеспечению
Если ТП описывают требуемую систему на языке пользователя, то ТПО описывают ее на языке инженера. Поэтому в этом документе сначала могут оказаться расчеты размера системы. Что особенно характерно для современных объектных методологий, потребность в ТПО уменьшилась, поскольку архитектура будет состоять из прикладных классов, у которых ясные взаимосвязи с языком ТП. В этой ситуации, ТПО и АП могут быть объединены.
Говорят, скульптор думает о своей законченной работе, как о заключенной внутри глыбы камня или куска дерева, и которую нужно оттуда извлечь, отсекая лишнее. Это помогает. Точно так же, мы можем представить себя глядящими глазами пользователя на наше творение в один из дней в будущем. Если мы смотрим на него используя свойства (черты) системы, мы можем спросить себя: "Как это должно быть реализовано?" Тогда очень легко получить описание потребностей пользователя на языке инженера-программиста.
Архитектурный проект
Если уже приходится делать работу, заключенную в АП, то может показаться, что самая тяжелая работа по проектированию к этому моменту завершена. Есть также большой соблазн вообще уклониться от написания Архитектурного Проекта. В то время как мы умышленно опускаем детали проекта в АП, иногда чтобы удовлетворить требованиям независимости от платформы (portability), иногда просто чтобы развеять туман вокруг большой картины, мы по-прежнему должны быть уверены в том, что наш проект действительно реализуем. Инженер должен знать по крайней мере один приемлемый способ реализации каждого свойства до того, как искать его, и должен подумать о концептуальной целостности кода, требуемого для реализации этих свойств.
Утверждение, что архитектурный проект не должен касаться детального проекта, мы считаем ошибочным. Если мы не можем рассматривать реализацию, мы не можем быть хорошими инженерами, поскольку любой идиот может спроектировать нереализуемое. Только учитывая реализацию мы обнаруживаем ограничения наших проектов и находим разницу между хорошим и плохим. Мы способны увидеть альтернативы, сравнивать их и выбирать лучшее. Если мы не можем учитывать реалии реализации, то один дизайн так же хорош, как и другой, и эта критическая стадия познания становится упражнением в письме, кто быстрее может "написать документ", нимало не задумываясь над написанным!
АП -- это дидактический документ. Он учит читателя тому, как посмотреть на проблему и решение так же, как смотрел автор.
Детальный проект
ДП -- это записка в бутылке. Он говорит читателю о том, как автор планировал реализацию, поэтому код можно понять. Детальность изложения должна прояснить те места, которые остались за кадром в АП, и привести читателя в точку, где уже должен быть сам код. Иногда, это объяснение может быть выражено псевдокодом, но не обязательно. Следует допускать возможность исправления ДП. Во время реализации будут возникать такие детали проекта, как организация кода в модули. Если такие детали не передать с помощью ДП нашим коллегам, то как еще это сделать? Это простое упущение вызывает в дальнейшем слишком много ненужных проблем, поскольку инженеры посчитают составляющие системы хорошо документированными, только в случае, если они знали, с чего начать! Окончательный вариант ДП должен говорить последователям, что они должны знать, чтобы понять систему и изменить ее.
План тестирования
План Тестирования -- наиболее чувствительный к контексту тип документа, но очень полезно руководствоваться следующими наблюдениями в рамках требований ситуации. Стратегическая цель тестирования -- напрячь систему. Не будет никакой пользы, если делать тестирование хаотично, поэтому необходимо найти одну или несколько моделей системы, которые могут дать нам индикатор для типичных и стрессовых ситуаций. Таким образом, полезная структура -- описать модель, выяснить стрессовые условия и затем перечислить их.
