С точки зрения многих инженеров-программистов, большая часть их жизни состоит в написании документов. С точки зрения настоящей работы, мы предпочли бы сказать, что их жизнь состоит в выполнении работы по повышению понимания, которое будет донесено до их коллег в соответствии с протоколом, определенным в их процессе. Следовательно, мы подразумеваем, что работа -- это всегда понимание, а процесс говорит, какое понимание нам нужно передать коллегам. Это определяет приемлемый для каждого документа язык. Эти соображения помогут сформировать описание реальной работы, которую требуется выполнить при работе над каждым из создаваемых инженером документов, как то: Требования Пользователя, Требования к Программному Обеспечению, Архитектурный Проект, Детальный Проект и Спецификация Тестирования (User Requirement, Software Requirement, Architectural Design, Detailed Design and Test Specification).
Следует отметить еще два момента. Во-первых, работа не заключается в создании кучи невразумительных бумажек, которые никто даже не будет читать, но которые по виду напоминают "конструкторскую документацию". Те, кто выплескивает технические подробности (все слеши и десятичные точки) в основном тексте, вместо того, чтобы поместить их в приложении, если уж это так нужно, просто издеваются над читателями и дискредитируют наше искусство в целом. Используя простой, нормальный язык (включая где необходимо специальную терминологию, но не злоупотребляя ею) расскажите читателю то, что ему нужно знать.
Второй момент касается формата. На любой стадии процесса программирования люди используют понимание, чтобы находить и предлагать паттерны. Если бы они знали, что они собираются найти, у них не было бы работы, поскольку их мог бы заменить настроенный кем-нибудь коммерческий (COTS) продукт. Раз мы не знаем наверняка, что работнику нужно представить, то как мы можем сказать ему, как он это должен представить? Стандартные форматы в процессах не должны восприниматься как догмы. Все приличные процессы в ISO 9001 содержат стандарты размещения необходимых разделов. Используй их соответственно, и если во время написания возникает структура документа, можно сделать вставку в План Управления Проектом, чтобы описать выбранный формат. Вот и вся суть ISO 9001.
Требования пользователя
Недавно возник большой интерес к "Реинженирингу бизнес-процессов" (`Business Process Re-Engineering' -- BPR). Это практика изучения бизнес-процессов для определения, можно ли их улучшить, и часто это необходимо сделать просто потому, что со временем изменилась природа бизнеса организации. Иногда превозносят точку зрения, что программная инженерия всегда включает значительный компонент BPR, поскольку в противном случае потребитель обнаружит, что компьютерная система автоматизирует бизнес-процесс, не учитывающий появление компонентов, которые руководство реализовало в ответ на потребности бизнеса, и систему ожидает крах. Таким образом, первая обязанность инженера-программиста -- помочь потребителю понять природу их собственных требований. В примере простейшей программы -- это кристаллизация желания из общего ощущения дискомфорта в специфическую потребность в большей освещенности. Инженер-программист руководствуется в этой работе дисциплиной, накладываемой необходимостью писать программу для компьютера. В работающем коде невозможно скрыть неоднозначности, как это можно сделать в текстовом отчете. Полезные ТП, таким образом, составляют настолько ясное понимание потребностей пользователя, насколько это возможно в начале проекта, как это понято пользователем и инженером, на языке пользователя. ТП обязательно потребуют уточнения в дальнейшем, по мере того, как дисциплина программирования выявит неоднозначности, независимо от того, будут ли эти поправки включены в документ или нет.
Причина, которая вызывает большую путаницу -- двоякое назначение ТП. С точки зрения инженера ТП должны быть живым документом, но из соображений коммерческих и правовых он занимает место эталонного документа на все время работы над проектом. Эти две цели совершенно различны. Когда они смешиваются, мы получаем комедию инженеров, не обремененных юридическими знаниями (что на самом деле так), пытающихся написать "Декларацию независимости", в то время как критические моменты бизнес процессов остаются неисследованными.
Иногда единственный способ выйти из этого положения -- написать два документа. Один определяет контрактный минимум и, если придерживаться некоторых методик, может быть с успехом написан полностью пользователем. Другой -- это живой, внутренний документ, который говорит нам, что же "приведет пользователя в восторг". Это то, чем мы стараемся руководствоваться в его интересах. Как удовлетворить пользователя, если единственной подсказкой как это сделать, является нечто, служащее нашим коллегам из коммерческого подразделения на поле закона? Рамки, до которых потребитель видит "настоящие ТП" зависят от коммерческих соображений.
Будьте очень осторожны по отношению к "средствам интегрированного отслеживания свойств", призванных получить ваши ТП и пропустить их положения через проектирование и тестирование, превращая в код. Такие средства часто забывают, что требования можно удовлетворить не делая что-то, что ряд требований может быть реализован в нескольких сегментах кода, без прямого соответствия между требованиями и сегментами, и что очень трудно протестировать важные общие требования отдельными тестовыми инструментами. Это не значит, что такими инструментами не следует пользоваться -- для задач конфигурирования и ввода данных они подходят прекрасно. Некоторые даже могут отследить свойства отдельных групп классов для GUI. Но для обычных требований черного ящика на "уровне пользователя" они искажают то, что могло быть написано в ТП, или навязать стиль разработки, требующий утомительного ручного кодирования отдельных свойств, вместо использования абстракций везде, где это возможно.