Вообщем, по роду своей деятельности столкнулся с разработкой ТЗ на доработку системы "ХYZ". И опять возникли вопросы как оформить сам документ. Стандартное ТЗ предполагает что мы описываем функциональные требования и дополнительную мишуру. Но вот как оформить банальный запрос заказчика: "Удалить реквизит "Х" с формы документа "Y", а поведение реквизита "Z" нужно модифицировать так-то и так-то". Это ведь не функциональное требование, а придумывать из головы разделы не хочется, например, "Модификации форм документов" -> Документ "Y" -> описание то, что необходимо выполнить. Может есть какие-ниюудь "ГОСТированные" разделы?

По ГОСТам, насколько я помню, данный артефакт называется "Техническое задание на развитие системы".

Я как раз часто пишу такие документы -- на модификацию и развитие. Для этого создал свой шаблон, в котором есть цели, задачи доработки, а также компоненты, в которых происходят изменения. Если это изменения в UI — стараюсь по возможности включать в документ макеты — заказчик понимает лучше с макетами UI, чем по сухому тексту.

Следующие вопросы
1. ТЗ на существующую систему есть? Согласовано?
2. Данный вопрос  больше на стороне технических писателей и вашей договоренностей с Заказчиком

Возьмите ГОСТ 34.602, на его основе сделайте свое , выкинув ненужное
В начале нового ТЗ можно привести фразу: «Функциональные возможности и технические характеристики доработанной системы определяются функциональными возможностями и техническими характеристиками исходной системы   за исключением следующих параметров, оговоренных в настоящем ТЗ». И далее писать о том, что исключается и что добавляется
И еще в ТЗ можно сколько угодно дополнительных разделов-подразделов плодить . Например, "Требования к графическому интерфейсу пользователя" (если работаете по ГОСТ 34.602-89, разумнее всего такой подраздел забросить в Требования к информационному обеспечению)

Следующие вопросы
1. ТЗ на существующую систему есть? Согласовано?
2. Данный вопрос  больше на стороне технических писателей и вашей договоренностей с Заказчиком

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

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

А что вам мешает так и называть разделы:
"Требования по реализации нового функционала"
"Требования по доработке существующего функционала"
?

И в каждом по пунктам каждое требование отдельно.

Например, нужно добавить справочник "SomethingRef". Вообщем нужно думать.

Интересно, что нибудь надумали?

Интересно, что нибудь надумали?

Я разделил всё ТЗ на 2 основных части: "Добавляемые компоненты" и "Модифицируемые компоненты".
Справочники, сделал попытку описать, в формате:
1. Структура справочника. Описываю ее в виде таблицы: (Имя поля   | Тип | Отображается на странице списка | Отображается на странице редактирования   | Заполнение обязательно);
2. Функциональные требования
Вот здесь у меня куча сомнений.. Например, можно ли отнести к функциональным требованиям требование вида: "Для пользователя роли "такой-то" на странице справочника должен отображаться фильтр по "такому-то" полю.
3. Макеты страниц. Для справочников я решил что необходимо приводить макеты "страницы списка" и "страница редактирования элемента".

Был бы очень признателен, тому кто приведет конкретный пример требований на справочник. Например каталог книг, в системе учета книжного магазина, в котором есть поиск по наименованию, автору. Структура "Название, Автор, год". Соответственно обладать должен стандартными Add/Edit/Delete. Но каждой книге должен соответствовать список книг похожих на нее(для упрощения - эти книги забивает администратор).

А зачем вообще пытаться нагромоздить требования такой деталистикой?

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

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

Смотрите сами, но стадии и комплектности документов для этого и придуманы.