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

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

Функциональная спецификация. В функциональной спецификации описывается сценарий использования продукта с точки зрения потребителя. Функциональная спецификация – это первый документ, вырабатываемый в процессе проектирования. В нем описывается функциональность создаваемого продукта через призму пользовательского интерфейса (если его создание предусматривается) и приводится детальный порядок функционирования компонентов с самой нетехнологической точки зрения. В нем должно быть также описано, как изменится характер работы пользователя, когда работа над проектом будет завершена. Туда же должен быть включен простой список работ, необходимых для осуществления общего замысла. Отличие этого документа от технических требований состоит в том, что в нем определяются соответствующие требованиям конструктивные особенности, включая пользовательский интерфейс или другие не столь очевидные элементы проекта. При качественном выполнении хорошая функциональная спецификация может быть простой серией копий экрана, снабженных подробными пояснениями.

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

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

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

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

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

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

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