Сводные документы требований

Текстовая расшифровка восьмого урока курса Введение в профессию аналитика.

Когда мы разрабатываем требования, обычно мы их сводим в какие-то совокупности. Сейчас, правда, эти совокупности более размыты из-за применения систем управления требованиями, где они просто фиксируются в базе данных, из-за чего иногда размывается деление по уровням и видам требований. Но, тем не менее, все аналитики сталкиваются со сводными документами требований. Давайте рассмотрим основные понятия, относящиеся к этим документам.

Если вы помните, на картинке с классификацией требований, которую я взял из книги Вигерса, на каждом уровне присутствовали названия документов, в которые эти требования должны собираться. На уровне бизнес-требований это был документ об образе и границах проекта (Vision), на пользовательском уровне — спецификация пользовательских требований (в предыдущих редакциях книги там была спецификация вариантов использования, так как в то время этот метод описания требований был широко распространён), и самом на нижнем уровне — так называемая спецификация требований к программному обеспечению (Software Requirements Specification или SRS).

Это достаточно широко известные названия сводных документов. Не только потому что книга Вигерса широко распространена, но и потому, что он при её написании опирался на уже существующий опыт. Есть такой институт IEEE (Institute of Electrical and Electronics Engineers), он предлагает свой набор документов, которые должны разрабатываться в процессе создания программных продуктов, и там тоже упоминается спецификация требований к ПО (SRS). Для неё есть стандарт IEEE 830, тоже, наверное, известный многим аналитикам, который до сих пор довольно активно используется.

Есть подход ГОСТовский ещё Советского союза, который сейчас распространен в России и в странах, оставшихся от СССР. Эта терминология всем вам известна и, в частности, здесь присутствует техническое задание. Здесь выделяется этап разработки Концепции и есть этап разработки Технического задания. Эти два термина — концепция и техническое задание — наиболее часто употребляются, когда мы говорим о сводных документах требований.

И есть ещё Rational Unified Process (RUP). Очень распространенный метод разработки ПО, по которому ещё лет десять назад проводилось много тренингов. Там тоже использовалась терминология, которую использовал и Вигерс в том числе: здесь мы видим снова слово «Vision», здесь та самая спецификация юзкейсов (вариантов использования), и здесь же присутствует SRS.

То есть, ещё раз повторим, есть такие документы: Концепция или Vision, Спецификация пользовательских требований, Техническое задание и SRS. Это наиболее часто используемые названия сводных документов требований. Но из-за того, что таких стандартов несколько, возникает иногда некоторая путаница в том, что же за этими документами стоит.

Для того чтобы не путаться в терминах, давайте углубимся в их различия в разных подходах.

По Вигерсу, Vision — это документ о границах и образе проекта, содержащий бизнес-требования к продукту. Описание образа позволяет всем заинтересованным лицам в общих чертах понять предназначение продукта. Или, другими словами, в Vision содержится тот образ продукта, который должен разделяться всеми участниками проекта и другими стейкхолдерами. В этом смысле документ Vision важен как такое хранилище бизнес-требований, которые, как мы говорили, особенно важны в интернет-проектах. Документ Vision позволяет собрать их все в одном месте, и эта та самая концепция, которой надо следовать, и которую если мы меняем, то должны это делать осознанно.

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

Если мы следуем нашим стандартам (ГОСТам), то по ГОСТ 34 Концепция — это совсем другой документ. Это фактически результат научно-исследовательской работы. Надо понимать, что ГОСТ разрабатывался в советское время, в эпоху ещё совсем больших машин. Ни о каком интернете тогда речь не шла, а персональные компьютеры представлялись какой-то сказкой. И поэтому, чтобы разработать какую-то новую систему, применялись довольно тяжеловесные и дорогостоящие методы. А Концепция должна была представить несколько вариантов автоматизированной системы, которую мы можем создать. В ней представлены очень высокоуровневые бизнес-требования, которые совершенно не пересекаются с терминологией «Vision» Вигерса. Это надо понимать: если вам приходится работать по ГОСТам, то Концепция ГОСТ и Vision — это совершенно разные документы. То есть Концепция по ГОСТу должна представить разные варианты создания системы для выбора, и в том числе может использоваться для принятия решения о том, что продукт разрабатываться не будет. Это этап, который проводится до начала проекта.

Мы будем понимать под словом «концепция» то, что во всем мире называется Vision. То есть документ об образе и границах проекта, как его определяет Вигерс и большинство других стандартов.

Ещё часто возникают разночтения, насколько техническое задание соответствует спецификации SRS. Здесь я привел то, что должна содержать спецификация требований SRS по стандарту IEEE 830, о котором мы уже говорили. Спецификация должна правильно определять все требования к программному обеспечению, не должна описывать детали разработки или реализации и должна налагать дополнительные ограничения на программное обеспечение. Смысл в том, что спецификация, с одной стороны достаточно детально описывает все требования к продукту, причем его полную модель. А с другой стороны, она должна писаться таким образом, чтобы мы, например, могли такую спецификацию использовать для повторного создания продукта с нуля.

Она пишется на уровне функций, которые должен реализовать продукт. В ней могут описываться конкретные алгоритмы, то есть это достаточно низкоуровневый документ. Но при этом мы можем по одной и той же спецификации, например, разработать одно приложение в консольном варианте, а другое с графическим интерфейсом. И формулировки должны быть такими, чтобы они не влияли на способ создания продукта. Например, нельзя писать в спецификации что-то вроде «пользователь нажимает кнопку», потому что кнопка — это элемент конкретного интерфейса.

Техническое задание. Я опять взял его описание из ГОСТ 34. Вообще, само словосочетание «техническое задание» — это такой русскоязычный термин, который из ГОСТа и появился.

Сначала в нём перечисляются общие сведения, назначение и цели создания системы, характеристика объекта автоматизации. Первые три пункта — это фактически высокоуровневые бизнес-требования, которые входят обычно в Концепцию или Vision. То есть назначение и цели создания системы и общие сведения о создаваемой системе.

Потом идёт раздел «Требования к системе». Он составляет основную часть ТЗ, но, если вчитаться в стандарт, то мы понимаем, что речь идет всё-таки о бизнес-требованиях, тоже достаточно высокоуровневых.

В ТЗ по ГОСТу, кроме собственно требований к системе, ещё включаются элементы проектного управления. То есть состав и содержание работ по созданию системы, порядок контроля и приёмки, состав и содержание работ по подготовке системы к вводу в действие.

И ещё в ТЗ включают требования к документированию и описание источников разработки.

Собственно к требованиям относятся пункты: общие сведения, назначение и цели создания системы, характеристика объекта автоматизации, требования к системе и требования к документированию. А остальные пункты уже описывают не сам продукт (как он должен выглядеть и для чего создаётся), а описывают, как он будет создаваться, то есть какие-то этапы, необходимые для его разработки.

Этим техническое задание и отличается от спецификации требований. Если мы используем термин «техническое задание» в терминологии ГОСТа, то мы должны понимать, что это документ, содержащий бизнес-требования, но, кроме этого, содержащий и некоторые договорные обязательства по разработке продукта. Обычно техническое задание прилагается к договору на разработку продукта.

Вам как аналитикам нужно понимать, что ТЗ и SRS — в это не одно и то же. Хотя очень часто я вижу и понимаю из контекста, что предполагается именно это.

ГОСТ обычно применяется при разработке продуктов по государственному или муниципальному заказу. Стандарт нужен для того, чтобы заказчик мог ожидать каких-то гарантий качества создаваемой системы. Но если вы не связаны строгим следованием стандарту, то очень часто под техническим заданием понимается документ, который содержит только то, что является собственно требованиями. А документация, которая относится к ведению проекта, делается обычно в виде других документов.

На этой картинке я показал, где примерно находятся эти сводные документы требований применительно к тем уровням требований, о которых мы говорили.

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

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

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

SRS. Эта спецификация предназначена для закрытия всех уровней, но обычно она идёт в дополнение к Концепции. То есть концепцию мы разрабатываем в Vision для того, чтобы закрыть бизнес-требования, а всё остальное мы включаем в SRS.

Примерно так обычно распределены по уровням требования, которые включаются в эти сводные документы. И мы в этом курсе будем придерживаться такого деления. Если мы будем говорить о техническом задании, то будем понимать, что мы находимся ближе к бизнес-требованиям. Если мы говорим о SRS, то мы понимаем, что описываем уже достаточно детально и полно создаваемый продукт.

Предыдущий урок: Виды программных и интернет-продуктов

Следующий урок: Процессы разработки и управления требованиями