Приветствую всех.
Возникла необходимость написать ТЗ в соответствии с ГОСТ 34. Нужны ваши советы и рекомендации.
При написании возник следующий вопрос.

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

В интернете нашел несколько рабочих примеров (довольно известных it компаний), в которых пишут эти требования вот
таким образом (к одной из подсистем):
- Внесение кредитной оценки УП
- Создание дисциплин
- Фиксация окончания формирования УП

то есть никакой конкретики - кем внесение? зачем? какие предусоловия? и тд.

Не очень понимаю, в чем смысл такого описания этого пункта в ТЗ? Если мы, допустим, имеем список подробно описанных ФТ, где каждое требование пронумеровано, то там понятно как потом проверить, как сослаться на это требование. А что делать с таким описанием и как оно вообще может нам помочь?

По сути краткое описание подсистем мы уже сделали в том же ТЗ немного выше, пункт 4.1.1 "Требования к структуре и функционированию системы".

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

Разъясните, пожалуйста, ситуацию с этим пунктом ТЗ, кто знает.
Заранее спасибо.

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

Так и есть, а что Вас удивляет?

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

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

А как же тогда быть с ТП? там вроде был такой документ - "Описание автоматизируемых функций".

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

Ничего не могу ответить на это. Кроме догадок у меня ничего нет.

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

Техническое задание должно содержать достаточное количество фактической информации для решения поставленной задачи.

А как же тогда быть с ТП? там вроде был такой документ - "Описание автоматизируемых функций".

В ТП должно быть описано проектное решение по автоматизируемым функциям. Не самый лучший пример, но (http://rugost.com/index.php?option=com_content&view=article&id=135:q-q13&catid=26&Itemid=63)

Несколько гипотез:
* http://blog.shumoos.com/archives/288
* У Влада Балина (http://gaperton.livejournal.com/) была интересная статья о работе по ГОСТ
* Кроме ТЗ можно писать кучу Частных ТЗ. Каждое на сотни страниц.

В интернете нашел несколько рабочих примеров (довольно известных it компаний), в которых пишут эти требования вот
таким образом (к одной из подсистем):
- Внесение кредитной оценки УП
- Создание дисциплин
- Фиксация окончания формирования УП

то есть никакой конкретики - кем внесение? зачем? какие предусоловия? и тд.

Не очень понимаю, в чем смысл такого описания этого пункта в ТЗ?

Это нормально. Заказчик хочет "создание дисциплин". Кем, зачем и предусловия вы проработаете в техническом проекте. И согласуете с заказчиком - все ли правильно понято и спроектировано. А потом, к сдаче, сформулируете конкретные кейсы испытаний, которые заказчик утвердит, как полностью и достоверно демонстрирующие, что требование "создание дисциплин" реализовано именно так, как он хотел.

Если мы, допустим, имеем список подробно описанных ФТ, где каждое требование пронумеровано, то там понятно как потом проверить, как сослаться на это требование. А что делать с таким описанием и как оно вообще может нам помочь?

Цель ТЗ - обозначить, что делаем. Как делаем - предмет эскизного (если у вас он предусмотрен) и технического проектов.

А что делать с таким описанием...?

Пронумеровать?

По сути краткое описание подсистем мы уже сделали в том же ТЗ немного выше, пункт 4.1.1 "Требования к структуре и функционированию системы".

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

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

Да. Чем требование "Система должна позволять ... создание дисциплин" Нечеткое и неконкретное?
Уровень абстракции выбирается исходя из сложившихся реалий и преследуемых целей.

В таком случае только один этот пункт ТЗ может потянуть на 100 с лишним страниц (это нормально?).

Да.

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

Ну вот что значит "полное"? Например, "Перечень входных сигналов и данных" или "Перечень выходных сигналов (документов)" по ГОСТ 34 - это документы технического проекта (даже не эскизного).
Вообще, для лучшего понимания - что, где и как предусмотрено в ГОСТе, было бы полезно прочитать 34.201, 34.601 и РД 50-34.698-90.

ГОСТ 34 - цельная система. ТЗ, как одна из ее частей, очень сильно связана со всем остальным. Понять, почему ТЗ именно такое, без понимания его места и роли в общей картине (т.е. глядя на мир только "изнутри" ТЗ) достаточно проблематично.

А как же тогда быть с ТП? там вроде был такой документ - "Описание автоматизируемых функций".

Описывать там то, что вы наавтоматизировали.

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

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

Нашел: http://gaperton.livejournal.com/49867.html
Работать по ГОСТ-у сложно. Очень мало кто способен составить план работы. Под планом понимается "декомпозия конечной цели на промежуточные результавы в терминах критериев завершенности." Не может содержать активностей, исполнителей, трудоемкости и прочего.

Нашел: http://gaperton.livejournal.com/49867.html

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

Масса спорных утверждений. Некоторые положения на практике с серьезным заказчиком нереализуемы. Например: "Единственная "задача" - это ТЗ. Правильный ответ - выделять частные, более мелкие ТЗ, на более мелкие работы. И так - до самого мелкого уровня.". Проблема в том, что ТЗ - один из основных документов во взаимоотношениях заказчика и исполнителя. И если писать ЧТЗ на каждый чих, первые лица и исполнителя, и заказчика (особенно заказчика) быстро утомятся утверждать все чихи мелочь. И деликатно выскажут свое отношение плодовитому писателю.

Ну, либо автор пишет о чем-то своем, а не применении ГОСТ в разработке для заказчика.

Работать по ГОСТ-у сложно.

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

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

Не совсем понял, какое отношение этот текст имеет, скажем, к 34 ГОСТ?
Ну и "план работы" без исполнителей, трудоемкости и активностей - тот еще план.

Спасибо всем за ответы.
Возник новый вопрос - кто может поделиться информацией как правильно отформатировать документ ТЗ по ГОСТ 34?
Название шрифта, размер, поля, интервал и т.д.
В ГОСТ 2 такую информацию не нашел

Добрый день!

В рамках выполнения работ по ГК мы, как правило, по согласованию с проектным офисом и тех.политикой (правда, не всегда такие организационные единицы есть ) готовили, согласовывали, утверждали и тиражировали на все проектные команды документ типа "Правила оформления отчетной документации".
Структуру данного документа, думаю, приводить не обязательно. Но в качестве использованных источников для нас всегда было следующее:
1.   ГОСТ 2.105-95. Межгосударственный стандарт. Единая система конструкторской документации. Общие требования к текстовым документам
2.   ГОСТ 7.1 – 2003. Система стандартов по информации, библиотечному и издательскому делу. Библиографическая запись. Библиографическое описание. Общие требования и правила составления
3.   ГОСТ 7.21-2001. Система стандартов по информации, библиотечному и издательскому делу. Отчет о научно-исследовательской работе. Структура и правила оформления
4.   ГОСТ 19.105-78. Единая система программной документации. Общие требования к программным документам
5.   И некоторые другие типа ОК 005 и прочие ГОСТ, например, по видам и комплектности документов.

Само оформление складывалось из четкого соответствия требованиям к:
1. Лист утверждения
2. Титульный лист
3. Список исполнителей
4. Аннотация
5. Содержание
...
8. Основная часть
8.1. Оформление раздела
8.2. Оформление подраздела
...
8.6. Оформление рисунков
8.7. Оформление таблиц
И т.д.

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

"Абзацы должны быть оформлены следующим образом:
-   шрифт: Times New Roman, 12 пт.;
-   первая строка: отступ 1,27 см;
-   междустрочный интервал: 1,5 строки;
-   выравнивание: по ширине;
-   без переноса в словах."

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

Конечно, здесь можно много спорить относительно использования различных государственных стандартов смежных по отношению к 34-ой серии. Однако в нашем случае практика показала, что отказ в передаче отчетного документа Исполнителя на тех.политику Заказчика по формальным признакам ГОСТ после предварительного рецензирования методологами побуждает проектные команды использовать положения выше указанных Правил для сдачи этапа / проекта в целом.

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

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

"Абзацы должны быть оформлены следующим образом:
-   шрифт: Times New Roman, 12 пт.;

Надо же, до чего дошёл прогресс - до пропорциональных шрифтов. Мы, помнится, первые официальные документы на компьютере набирали строго курьером 13пт, чтобы на печатную машинку было похоже.

Приветствую всех еще раз!
Чтобы не плодить схожие темы на форуме, продолжу эту тему (тем более что вопрос все про тот же ГОСТ 34).

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

К примеру - вот такое требование:
Система должна позволять расширять возможности информационного обмена путем  интеграции новых внешних систем.
Как его проверять? Проделать интеграцию с новой внешней системой? Но на такой тест может понадобиться отдельный релиз системы и отдельное ТЗ.

Или вот такое требование:
Структура данных и способ организации должны позволять наращивать объем накопленных данных в системе, а также вносить изменения в систему вслучае изменения законодательства...
Как проверить - начать вносить изменения прямо в момент сдачи системы на глазах у заказчика? Но это тоже может оказаться трудоемким процессом.

В поиске полезных примеров документации  случайно наткнулся на вот такой ресурс - Информационное общество Минэкономразвития. http://aisup.economy.gov.ru/pubportal/ Оказывается, там на суд общественности выкладывают документацию к различным продуктам, сделанным по заказу министерства.

Вот несколько занимательных примеров, из ПМИ в одном из документов оттуда:

Действия пользователя (Д): Нажать кнопку «Регистрация».
Ожидаемый результат (Р): Пользователь пытается зарегистрироваться.

(Д) Нажать «Войти».
(Р) Пользователю отображается следующие элементы экрана: поля ввода учетной записи (адрес электронной почты e-mail и пароль); кнопка «Вход»; форма для восстановления пароля.

А вот так предлагают тестировать быстродействие:
(Д) Последовательно зайти на все информационные страницы
(Р) Загрузка любой страницы, занимает не более 5 секунд.

Может ли кто-нибудь поделиться примером про тестирование требований к видам обеспечения, дать ссылку на книгу или еще какой-нибудь источник? Облазил весь интерент, грамотных примеров так и не нашел

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

К примеру - вот такое требование:
Система должна позволять расширять возможности информационного обмена путем  интеграции новых внешних систем.
Как его проверять? Проделать интеграцию с новой внешней системой? Но на такой тест может понадобиться отдельный релиз системы и отдельное ТЗ.

Или вот такое требование:
Структура данных и способ организации должны позволять наращивать объем накопленных данных в системе, а также вносить изменения в систему в случае изменения законодательства...
Как проверить - начать вносить изменения прямо в момент сдачи системы на глазах у заказчика? Но это тоже может оказаться трудоемким процессом.

Над этими требованиями ещё работать и работать. В таком виде их проверить, конечно, невозможно.