Форматы документирования

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

Произвольный текст - требование сформулировано на языке пользователя (пожелания, заявки, запросы на изменения).

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

Бизнес-требования

Файлы, полученные из внешних источников (регламенты, законы, переписка и т.п.)

Иерархически структурированные требования (документы) с вербальным описанием бизнес-процессов, бизнес-правил и бизнес-ограничений.

Требования, записанные в форме бизнес-моделей, например, с использованием нотации BPMN.

Системные требования

Техническое задание - документ, содержащий требования разного типа и текст общего характера.

Спецификация - документ, содержащий требования одного типа, касающиеся одной подсистемы.

Use Cases (или варианты использования) - требование записано определенным образом, описывающим взаимодействия с системой.

UML-модели - требования к информационным, структурным и поведенческим аспектам системы, записанные на общеизвестном языке моделирования.

Макеты UI - требования к пользовательскому интерфейсу.

Возможности WYSIWYG-редактора позволяют документировать:

  • Математические формулы
  • UML-модели, при помощи языка PlantUML или инструмента для построения моделей draw.io
  • BPMN-модели, IE-модели и другие виды диаграмм, при помощи инструмента для построения моделей draw.io

Схемы работы с требованиями

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

Пользовательские истории

При реализации простых и четких требований, не обязательно создавать детальные спецификации или документировать бизнес-процессы. Работа с документацией отнимает время, особенно, когда требования непрерывно меняются. Для одноразовых продуктов, прототипов и MVP, предварительное проектирование менее ценно, нежели скорость получения обратной связи от пользователей.

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

Пользовательские истории - один из удобных и распространенных способов записи пользовательских требований. Если кратко, то для записи пользовательской истории используется следующий формат:

Краткость это хорошо, но успех проекта будет зависеть от качества требований. Писать качественные истории нужно научиться. Используйте принципы INVEST, как чек-лист провеки качества разработанных историй.

Не следует путать описание функциональных требования в формате Use Cases и пользовательских требований в формате User Story - это два сильно разных взгляда на требования к ПО. В одной пользовательской истории могут содержаться несколько Use Cases. Пользовательские истории не являются способом структурирования требований к ПО.

Поддерживающие требования

Риски разработки ПО на основе пользовательских требований заключаются в том, что:

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

Снизить эти риски поможет практика разработки поддерживающих требований.

Перед реализацией пользовательской истории, в процессе ее реализации или сразу после этого, документируйте важные технические решения: макеты UI, алгоритмы, модели данных и др. С одной стороны эти системные требования будут связаны с историей и позволят качественно ее реализовать. С другой стороны - со временем вы накопите структурированные системные требования по всему продукту, что избавит от описанных ранее рисков.

Почему плохо записывать системные требования непосредственно в самой истории? История пользователя по определению должна быть небольшой. Критерии завершенности и критерии приемки увеличивают ее описание. Системные требования в виде макетов (и детальных требований к ним), алгоритмов и раличных моделей, сделают историю очень громоздкой и не удобной в работе. Более того, найти нужные системные требования затем станет просто невозможно, не говоря уже о внесении изменений в них.

Разработка на основе требований

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

Понятие "конуса неопределенности" говорит нам о том, что чем менее детальные требования, тем больше ошибка в оценке их сложности или трудоемкости. Более точная оценка бюджета проекта, либо бюджета на изменения уже реализованных требований, возможны только при предварительной проработке требований и анализе влияния изменений на них.

Разработка основанная на требованиях (Requirements driven development, RDD) предполагает явное выделение цикла проектирования, на котором:

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

После цикла проектирования, на основе созданных задач на разработку (доработок) организуется цикл разработки:

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

В некоторых случаях проект может завершаться уже после проектировочного цикла, если целью проекта была разработка требований к ПО.

Иногда разработку по требованиям путают с каскадной разработкой (или разработкой по ГОСТ-ам). Объем проектируемых требований (размер инкремента) можно регулировать в соответствии с условиями проекта.

Проектные конфигурации

Требования могут быть распределены по разным проектам и связаны между собой:

  • Общие бизнес- или функциональные требования могут разрабатываться на уровне программы, а детальные системные требования к компонентам - на уровне продпроектов, управляющих работой разных команд;
  • Общие требования могут храниться в программе, а в подпроектах можно вести разработку функциональных и системных требований к настольным, мобильным и другим вариантам использования продукта;
  • Требования к интегрируемым системам могут располагаться в разных проектах и быть связаны с целью отслеживания влияния изменений требований одной системы на требования другой.

Разработка требований

Документы и реестр

С требованиями удобно работать как в форме документа, так и в форме произвольного набора атомарных требований (при помощи реестра или списка требований). Например, в виде документа может быть оформлено ТЗ или ЧТЗ. Однако, такие документы получаются большими и целиком их не реализуют. Реестр позволяет работать только с нужным подмножеством атомарных требований - оценивать, планировать, контролировать реализацию.

У документарного и спискового представления реестра есть свои плюсы и минусы:

Плюсы Минусы
Документ требований

На одном экране видны связанные друг с другом разделы документа.

Цельное описание задачи.

Можно выставлять/контролировать требования к полноте, непротиворечивости.

Удобно согласовывать.

Можно версионировать и создавать бейзлайны.

Сложные системы состоят из тысяч требований, работать с которыми при помощи документа становится невозможным.

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

Реестр (список) требований

Нет избытка информации (текста требований) при работе с атрибутами или связями требований.

Можно быстро выполнять массовые операции: оценка, реализация.

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

На произвольном наборе требований невозможно проверить полноту непротиворечивость и целостность документации и продукта.

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

Для выполнения различных задач по документированию и управлению, выбирайте наиболее подходящее представление работы с документами, Devprom ALM поддерживает их все.

Импорт/экспорт и печать

Загрузите ваши документы с требованиями в формате MSWord, OpenDocument или Excel. Приложение автоматически разберет их на разделы в соответствии со структурой, заданной в документе. Для разделения документа на требования используется разметка заголовочными стилями (Заголовок 1, Заголовок 2 и т.п.).

Пользовательская разметка документов

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

Например, для преобразования текста, содержащего фразу "Системное требование" в системные требования и сохранении ссылки на эти требования в разделе документа, вы можете разработать такой скрипт:

В результате импорта документа система создаст системные требования, а ссылки на них разместит в документе требований:

Экспорт во внешние форматы

Вы можете выгружать произвольный набор требований, документ или несколько документов во внешние форматы. При выгрузке в MSWord вы можете указать шаблон (заготовку) документа, стили которого будут использованы при выгрузке. В этом шаблоне могут присутствовать титульные листы, то есть выгрузка может осуществляться в любое место в шаблоне. При помощи макросов WYSIWYG-редактора вы можете выгружать атрибуты документа и конкретных требований, например, выгрузить название документа в определенное место в шаблоне.

Перечень ранее использованных шаблонов для экспорта можно найти в настройках проекта, в модуле "Шаблоны выгрузки". В процессе "Разработка по требованиям" содержится пример выгрузки документов в шаблон по требованиям ГОСТ. Вы можете самостоятельно задавать формат формирования маркированных и нумерованных списков, для чего предназначены соответствующие поля в Шаблоне выгрузке на вкладке Дополнительно.

Для повторного импорта документов, измененных заинтересованными лицами вне системы, используйте опцию выгрузки "Экспортировать исходный код UML-моделей и формул". Таким образом, после импорта эти объекты вновь станут редактируемыми, так как при экспорте они преобразуются в изображения.

Для импорта откройте документ и в меню Действия выберите соответствующий пункт меню.

Если необходимо распечатать несколько разделов или целый документ, можно воспользоваться встроенными возможностями печати из браузера:

Виды связей

Требования могут быть связаны с другими требованиями или другими проектными артефактами.

Вид связи Назначение
Структурная, родитель-ребенок

Сложные требования удобно декомпозировать на более мелкие кусочки. Для варианта использования дочерними требованиями могут являться: макеты UI, точки расширения (альтернативные сценарии или расширяющие сценарии), системные требования. Требования могут образовывать иерархию, формируя тем самым документ, спецификацию или ТЗ.

Для быстрой декомпозиции требования на составные части создавайте дочерние требования на основе выделенного фрагмента текста:

Причинно-следственная

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

Зависимости

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

Покрытие Такой тип связи устанавливается между требованиями и другими проектными артефактами: тестовой документацией и технической документацией (руководствами пользователей).

Создание связей осуществляется прозрачно для пользователя, при создании проектных артефактов на основе первичных, бизнес- или системных требований (например, при помощи зеленых кнопок или пунктов меню). Связи можно редактировать на вкладке "Трассировки".

Связи можно визуализировать на сетевой диаграмме (на вкладке Связи):

Отслеживаемость между требованиями (причинно-следственные связи) и между требованиями и другими проектными артефактами (покрытия) используется в Devprom ALM как инструмент поддержания целостности проектной документации. Когда исходное требование изменяет текст, то система помечает все производные требования и покрытия признаком "Устарело". Устаревшие требования и другие артефакты можно легко найти и обновить, чтобы восстановить целостность связи.

Шаблоны

Шаблоны требований - это типовые заготовки, которые можно использовать при документировании требований. Шаблоны вставляются при указании символа # (решетка). Если шаблон определен как шаблон по умолчанию, то при создании требования будет сразу подствлен этот шаблон. Для разных типов требований можно использовать разные шаблоны по умолчанию. Мы уже включили в типовые процессы несколько распространенных шаблонов, но вы их можете удалить и использовать собственные наработки.

Помимо шаблонов страниц, вы можете формировать шаблоны документов. Например, это может быть типовой документ для создания ТЗ или спецификации по тому образцу, который принят в вашей организации. Для создания шаблона импортируйте вашу заготовку в Devprom ALM или наберите структуру средствами приложения. В меню "Действия" в режиме работы с документом выберите "Создать шаблон". Для создания документа по шаблону используйте кнопки с их названиями:

Переиспользование

Повторное использование требований возможно реализовать несколькими способами.

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

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

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

Если текст какого-то требования должен повторяться в тексте других требований, используйте возможность редактора WYSIWYG вставлять в текст требования текст другого проектного артефакта. Данная возможность доступна при помощи кнопки на панели инструментов или через контекстное меню в редакторе WYSIWYG.

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

Проектирование ГИП (UI)

Для проектирования и документирования макетов графического интерфейса пользователя (ГИП или UI) используйте встроенную возможность создания draw.io диаграмм, с использованием библиотеки "Макеты".

Вставьте новую диаграмму:

В перечне библиотек подключите "Макеты" и создавайте проект пользовательских интерфейсов:

Логический дизайн

Для моделирования технического устройства (дизайна) проектируемой системы используются UML-модели и другие нотации (IE, IDEFx и т.п.). Такие модели могут уточнять функциональные/нефункциональные требования, однако, при значительном количестве элементов, работа с ними становится крайне неудобной. Более того, элементы дизайна могут обладать массой специфических характеристик, которые необходимо записывать, использовать и анализировать.

Для хранения и учета элементов дизайна проектируемой системы используйте модуль "Компоненты". Это иерархическое представление элементов дизайна, таких как логические или технические подсистемы, модули, сущности, объекты и т.п. Справочник "Тип компонента" позволяет сформировать необходимую номенклатуру используемых элементов дизайна. При помощи модуля Настройки - Атрибуты вы можете задать дополнительные пользовательские атрибуты специфичные для отдельных типов компонентов или общие для всех типов компонентов.

Дочерние компоненты могут быть созданы в других проектах, таким образом, развесистую иерархию вашего дизайна можно распределить на сколько проектов (проектных команд).

Трассировка на требования

Связь с исходными требованиями позволяет задокументировать важные требования, предъявляемые к элементам дизайна. Между компонентами и требованиями связь "многие-ко-многим".

Связь доработок (историй пользователя) с компонентами позволяет задокументировать влияние реализации этих требований на конкретные компоненты (элементы дизайна) системы.

Стоимость

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

Стоимость компонентов, содержащих вложенные (дочерние) компоненты, включает их стоимость.

Управление требованиями

Ответственная и качественная разработка требований к ПО требует собственного процесса управления.

Идентификация требований

Уникальный идентификатор требования используется для ссылки на требование, при создании зависимостей или при экспорте и печати документов. По умолчанию Devprom ALM самостоятельно присваивает требованиям идентификаторы вида R-NNN, где NNN - число. Данная идентификация сквозная для всей документации, заведенной в систему. Это гарантирует уникальность идентификатора и позволяет однозначно ссылаться на требование по нему.

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

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

В качестве формулы для вычисления идентификатора требования необходимо записать выражение по примеру из описания. Вот несколько вариантов пользовательской идентификации требований:

  • {Тип требования.Краткое название,R}.{ИД} - в начале ИД требования будет указано краткое название его типа, например, СТ.123
  • {Тип требования.Краткое название,R}-{ИД в проекте} - позволяет сделать ИД уникальным в рамках только одного проекта. Значение поля "ИД в проекте" заполняется счетчиком типа требования. Счетчик типа требования увеличивается системой автоматически. Таким образом, вы можете получить такие идентификаторы: БТ-1, СТ-1 и т.п.

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

Типы требований

Разные по назначению требования удобно помечать разными типами. В приложении используйте фильтры или группировки для работы над разными типами требований. Каждому типу требований можно сопоставить шаблон по умолчанию. При создании требования он будет использован как заготовка, которую нужно будет заполнить.

Опция Назначение
Требования реализуются Используется в схеме "Разработка по требованиям". На основе бизнес-требований не создают задачи на разработку (доработки). Доработки создают на основе функциональных или системных требований. Чтобы не вводить пользователей в заблуждение, для разных типов требований необходимо корректно выставить значения этой опции.
Требования тестируются По аналогии с реализацией требований - не все виды требований участвуют в процессе тестирования. Установите эту опцию для тех требований, по которым нужно рассчитывать процент покрытия тестами.
Может быть производным Между требованиями можно устанавливать причинно-следственные связи. Установите эту опцию, чтобы отличать какие типы требований могут быть исходными (например, бизнес-требования), а какие - производными (например, функциональные требования).
Идентификация требований не используется Некоторые разделы документов требований не являются требованиями по сути, однако, формируют важный контекст, необходимый для понимания остальных требований. Такие разделы могут быть обязательными с точки зрения требований к подготовке документации. Во встроенных процессах для таких требований предназначен тип "Общая информация". Идентификация таких требований не нужна. Например, при выгрузке во внешние форматы у разделов документа не будет добавляться ИД требования.
Является заголовком документа

Данная настройка позволяет управлять визуализацией названия требования в составе документа, а также при выгрузке во внешние форматы. Требования данного типа не будут нумероваться и выделяться заголовочными стилями. Фактически образуется список требований.

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

Жизненный цикл

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

В разных проектах или для разных типов требований жизненный цикл может отличаться. Проектная команда настраивает ЖЦ требований для своего проекта самостоятельно. В процессе "Разработка по требованиям" мы уже настроили несколько полезных правил, например:

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

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

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

Трассировки

Трассировки между требованиями образуются причинно-следственными связями и покрытиями. Трассировки образуются в процесс работы над проектными артефактами. Трассировки можно создавать и редактировать вручную на вкладке "Трассировки".

Трассировки используются для следующих задач:

Контроль полноты

Табличное представление зависимостей между различными типами требований, например, бизнес- и системными требованиями, называется матрицей трассируемости. Этот инструмент позволяет:

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

Матрица трассируемости позволяет мгновенно получить ответы на вопросы:

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

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

Управление бюджетом

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

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

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

При использовании модуля "Управление финансами и бюджетом проекта" вы сможете увидеть эту информацию в разрезе стоимости расходов на время, запланированное или затраченное участником проекта. Используйте для этого модуль "Расходы по требованиям".

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

Термины

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

При помощи вставки модуля в текст документации можно быстро сформировать таблицу терминов:

Лучшие практики документирования

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

Мы собираем и делимся с вами лучшими практикам по созданию проектной документации и документированию требований в частности.

Условно, всех подходы можно разделить на две большие группы:

  • все в одном документе;
  • разные документы для разных целей;

Все требования в одном документе

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

Проблема однако в том, что не существует одного формата создания ТЗ (или ЧТЗ). Для разных классов программных продуктов или программно-аппаратных систем сообществом разработано несколько вариантов. На уровне государственного регулирования также существует несколько стандартов документирования технических заданий. При разработке больших систем функциональности становится так много, что работать с одним только ТЗ становится крайне неудобно.

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

ГОСТ 34

Шаблон ТЗ по ГОСТ 34 вы можете найти внутри проекта, созданного по шаблону "Водопад".

IEEE 830-1998

Этот стандарт предполагает 6 вариантов (или перспектив) документирования требований: относительно событий, стимулов, относительно ролей или функций. Для конкретной задачи и потребителей выбирайте наиболее удобную перспективу.

ТЗ на веб-сайт

Типизированные документы требований

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

В этом случае различные роли будут работать со своими пакетами документов, предназначенных именно для них. Но поскольку одни типы требований связаны с другими, то необходимо формировать и управлять связями между разными типами требований. В этом как раз и помогает система управления требованиями (СУТ).

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

Бизнес-требования

Для описания бизнес-требований вербально (текстом) наилучшим образом подходят такие документы как Business Requirements Document (BRD) или Бизнес-кейс. Как правило, в таких документах содержится описание бизнес-процессов, их временных характеристик, передачу или преобразование рабочих продуктов, задействованные роли и описание причинно-следственных связей.

Альтернативным вариантом описания таких требований является использование языков моделирования, например BPMN, IDEF и т.п.

Хорошей практикой является трассировка бизнес-требований (или системных требований) к целям, для достижения которых и необходимо реализовывать эти требования. Информация о целях может содержаться в документах, в одном из разделов. Однако, в Devprom ALM для этого лучше использовать дерево функций, где не верхнем уровне располагаются бизнес-цели, а на нижних - крупные функции системы, бизнес-функции или фичи продукта.

Системные требования

Фреймворк Rational Unified Process предлагает форму для записи системных требований (функциональных и нефункциональных) в виде спецификации, так называемый SRS:

Храните варианты использовать по каждой подсистеме в отдельном документе. Если варианты использования (Use Cases) сложны и объемны, декомпозируйте их на составные части (слайсы, расширения, альтернативные сценарии).

Низкоуровневые требования (системную архитектуру, дизайн) удобно записываться в формате "4+1" предложенной Филиппом Кратченом, либо аналогично в формате SAD (Software Architecture Document, RUP).

Смешанный подход

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

Например, в одном документе мы можем собрать функциональные требования (в формате Варианта использования), а также требования к дизайну, то есть системные требования (в формате UML-модели):

Программные контракты

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

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

И, конечно же, такие требования могут быть размещены в разных проектах.