Добрый день.

Имеется ли у кого-то из вас пример «Отчета о выполненной работе на стадии «Формирование требований к АС», содержание которого приведено в «Приложении 1» документа «РД 50-34.698-90»?

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

• в разделе "Функции и задачи создаваемой АС" привести перечень UseCase'ов системы (от которых будем отталкиваться при оценке трудоемкости);
• в разделе "Выводы и предложения" указать перечень работ аналитической фазы с указанием их трудоемкости и стоимости (на основе UseCase'ов)

Спасибо.

Я сам не писал РД 50-34.698-90, но можно посмотреть здесь:
* Образцы ТЗ по ГОСТу
* Документ "Массив входных данных" ГОСТ 34
* Классификация требований к ПО и ее представление в стандартах

Спасибо.
Тогда такой вопрос.

Какой документ разрабатывается на выходе предпроектного обследования? Proposal? А если Заказчик - ГосУчреждение (с требованием писать документы по ГОСТу)?

Спасибо.
Тогда такой вопрос.

Какой документ разрабатывается на выходе предпроектного обследования? Proposal? А если Заказчик - ГосУчреждение (с требованием писать документы по ГОСТу)?

Скорее всего, наиболее приемлемым документом для Заказчика будет ТЗ. После того, как Вы его согласуете с Заказчиком, его можно будет включить приложением к договору с Заказчиком (с обязательством Исполнителя реализовать систему в соответствии с ТЗ). Тем самым требования по каждому пункту ТЗ станут юридически значимыми.
Нужно только учесть, что ГОСТ ориентирован на функциональное представление системы. А значительная часть приложений сейчас разрабатывается и реализуется в объектно-ориентированном подходе. И если Вы собираетесь использовать описание ВИ (use cases) для описания требований в ТЗ по ГОСТ, то местами в тексте ТЗ Вам придется достаточно "творчески" отображать объектно-ориентированные представления в функциональные , имея в виду, что ВИ - не тождественен функции.

Скорее всего, наиболее приемлемым документом для Заказчика будет ТЗ.

ТЗ обязательно будем писать , только на дальнейших этапах.

Сейчас же требуется дать оценку, сколько времени потребуется на написание ТЗ (= на проведение аналитической фазы проекта), чтобы понять стоимость этой фазы и сообщить ее Заказчику.
А дальше уже беседовать с Заказчиком по поводу того, нужна ли ему такая система за такие деньги и т.п.

И для меня сейчас стоит открытым вопрос - в каком виде (по ГОСТ) оформить результаты оценки. То есть в каком документе мне написать наше предложение по трудоемкости и стоимости аналитической фазы.

И если Вы собираетесь использовать описание ВИ (use cases) для описания требований в ТЗ по ГОСТ, то местами в тексте ТЗ Вам придется достаточно "творчески" отображать объектно-ориентированные представления в функциональные , имея в виду, что ВИ - не тождественен функции.

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

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

2.6.2. В подразделе “Требование к функциям (задачам)”, выполняемым системой, приводят:

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

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

1. ГОСТ не запрещает описывать ВИ в ТЗ . Но описание требований к функциям в разделе 2.6.2 должно быть. Если заменить описание функций описанием ВИ - Заказчик будет иметь право возражать .
2. Результаты оценки оформляются в виде отчета о выполненной работе (предпроектном обследовании). Есть ГОСТ на НИР, но он регламентирует фактически только форму титульного листа отчета.
3. В каком документе писать сколько денег будет стоить само обследование  вам ГОСТ ничего не скажет. Вообще-то странно, если Заказчик согласится Вам оплатить предпроектное обследование только для того, чтобы Вы заявили ему стоимость Ваших услуг. Особенно если он собирается оплачивать Ваши услуги из государственных средств. ИМХО больше шансов заключать договор сразу на составление ТЗ - и состав работ виден и стоимость видно к чему приложить. Все равно ТЗ будете писать на основании предпроектного обследования. Второй раз те же результаты обследования описывать, только в другом виде...

1. ГОСТ не запрещает описывать ВИ в ТЗ . Но описание требований к функциям в разделе 2.6.2 должно быть. Если заменить описание функций описанием ВИ - Заказчик будет иметь право возражать .

Да, я понимаю, что функции в этом разделе описывать надо обязательно. Вопрос как раз был в том, можно ли в этот же раздел "прикрутить" ВИ. Вы "прикручивали"? Успешно?

2. Результаты оценки оформляются в виде отчета о выполненной работе (предпроектном обследовании). Есть ГОСТ на НИР, но он регламентирует фактически только форму титульного листа отчета.

Собственно, мой изначальный вопрос и состоял в том, можно ли использовать в качестве такого документа «Отчет о выполненной работе на стадии «Формирование требований к АС»

3. ... Вообще-то странно, если Заказчик согласится Вам оплатить предпроектное обследование только для того, чтобы Вы заявили ему стоимость Ваших услуг. ...

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

Да, я понимаю, что функции в этом разделе описывать надо обязательно. Вопрос как раз был в том, можно ли в этот же раздел "прикрутить" ВИ. Вы "прикручивали"? Успешно?

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

... Чем меньше напишете в требования к функциям в ТЗ для договора - тем лучше для Вас, как Исполнителя. Описания ВИ (текстовые - не диаграммы ВИ UML), как правило, весьма подробны. ...

К сожалению, опыта написания ТЗ у меня еще немного. Но я думал, что в документе ТЗ необходимо писать Детальные требования (из иерархии Бизнес-требования -> Требования пользователей -> UseCase'ы -> Детальные требования).

Я что-то не совсем правильно понял?

К сожалению, опыта написания ТЗ у меня еще немного. Но я думал, что в документе ТЗ необходимо писать Детальные требования (из иерархии Бизнес-требования -> Требования пользователей -> UseCase'ы -> Детальные требования).

Я что-то не совсем правильно понял?

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

ИМХО Юра Булуй дал ответы на Ваши вопросы куда какие требования писать.
План и содержание работ можно засунуть в п. 2.1.5. и 2.3.5. ГОСТа 34.602-89 Техническое задание
А стоимость уже в договор засовываете.

Shur, bas, спасибо.