Форум Сообщества Аналитиков

×


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



Re: ТЗ на доработку Ответ #1 : 19 Декабря 2012, 17:37:29
По ГОСТам, насколько я помню, данный артефакт называется "Техническое задание на развитие системы".

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



Re: ТЗ на доработку Ответ #2 : 20 Декабря 2012, 11:56:56
Следующие вопросы
1. ТЗ на существующую систему есть? Согласовано?
2. Данный вопрос  больше на стороне технических писателей и вашей договоренностей с Заказчиком


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



Re: ТЗ на доработку Ответ #3 : 20 Декабря 2012, 15:36:12
Следующие вопросы
1. ТЗ на существующую систему есть? Согласовано?
2. Данный вопрос  больше на стороне технических писателей и вашей договоренностей с Заказчиком

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



Re: ТЗ на доработку Ответ #4 : 21 Декабря 2012, 12:37:08
По нему все сделанно, сейчас начинается 2-й этап работы, в котором есть как доработка/изменение существующего функционала, так и добавление абсолютно новых компонентов. Например, нужно добавить справочник "SomethingRef". Вообщем нужно думать.

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

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



Re: ТЗ на доработку Ответ #5 : 26 Декабря 2012, 13:31:15
Цитировать
Например, нужно добавить справочник "SomethingRef". Вообщем нужно думать.
Интересно, что нибудь надумали?
«Сделай первый шаг, и ты поймешь, что не все так страшно.»
-- L. A. Seneca --



Re: ТЗ на доработку Ответ #6 : 26 Декабря 2012, 15:33:02
Интересно, что нибудь надумали?

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

Был бы очень признателен, тому кто приведет конкретный пример требований на справочник. Например каталог книг, в системе учета книжного магазина, в котором есть поиск по наименованию, автору. Структура "Название, Автор, год". Соответственно обладать должен стандартными Add/Edit/Delete. Но каждой книге должен соответствовать список книг похожих на нее(для упрощения - эти книги забивает администратор).
« Последнее редактирование: 26 Декабря 2012, 16:13:11 от skillu »



Re: ТЗ на доработку Ответ #7 : 27 Декабря 2012, 01:26:43
А зачем вообще пытаться нагромоздить требования такой деталистикой?

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

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

Смотрите сами, но стадии и комплектности документов для этого и придуманы.
« Последнее редактирование: 27 Декабря 2012, 01:29:41 от artvish »




 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19