Ohrangos.ru

Юридический журнал

Тз требования к функциям

ООО «Техническая документация»

разработка техдокументации

. к функциям (задачам), выполняемым системой

Требования к функциям (задачам), выполняемым системой — подраздел технического задания на автоматизированную систему, разрабатываемого согласно ГОСТ 34.602. Как элемент иерархической структуры техзадания может быть представлен так: Требования к системе (разд. 4) ⇨ . к функциям (задачам), выполняемым системой (подр. 4.2). В документах подраздел выделяется и нумеруется, как правило, заголовком 2-го уровня. Каково должно быть содержимое данного подраздела? Редакция от 20.06.2018.

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

АСУ в необходимых объемах должна автоматизированно выполнять:

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

[из п. 1.2.1 ГОСТ 24.104-85].

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

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

[из п. 2.6.2 ГОСТ 34.602-89].

Потребуется создать соответствующие пункты технического задания.

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

4.2.2 Перечень функциональных подсистем, отдельных функций или задач, вводимых в действие в 1-й и последующих очередях

4.2.3 Временной регламент реализации каждой функции, задачи (или комплекса задач)

Функция АС — это Совокупность действий АС, направленная на достижение определенной цели [из п. 1.3 ГОСТ 34.003-90], задача — Функция или часть функции АС, представляющая собой формализованную совокупность автоматических действий, выполнение которых приводит к результату заданного вида [из п. 1.4 ГОСТ 34.003-90].

Из определений следует, что функции, выполняемые автоматизированной системой, как бы инкапсулируют задачи АС, что несколько противоречит «школьному» восприятию данной ситуации, а также логике и здравому смыслу. Все мы решаем насущные жизненные задачи (problems), а не просто (зачем-то) выполняем какие-то функции. Взять тот же мировой финансовый кризис — это проблема для всего человечества, а не его функция, и чтобы справиться с ним, человечеству придется решать задачи, а не выполнять функции.

Важно понимать, что функции всегда выполняются В РАМКАХ решения каких-либо задач, а не бессмысленно и сами по себе. Волнует кого-нибудь, к примеру, квадратичная функция? Маловероятно. А задачи, решаемые в целях повышения собственного благосостояния? Делаем выводы

Тз требования к функциям

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

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

Основное в функциональных требованиях. Когда пишем функциональные требования в виде сценариев вариантов использования?

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

Абонент совершил платеж. Система начисления бонусов прислала уведомление, что если он совершит еще платёж на 700 рублей, то ему автоматом начистится бонус в 700, причем акция действительна до конца месяца. А был уже поздний вечер 31 октября. Абонент побежал к терминалу и совершил платеж на 700 рублей. Успел, на часах было 22:00. Но ВПС, через которую оплатил абонент, некорректно проставляла часовые пояса. После приведения времени ВПС к московскому, оказалось, что время платежа 01:00 следующего месяца, и акция уже не действует. Абонент, соответственно, обратился с жалобой в клиентскую службу оператора.

Групповые операции

Есть сообщение о платеже и его обработка в ПЦ и есть сообщение, в котором указано несколько платежей — пакет платежей.

Есть сообщение на отмену платежа и есть пакет платежей на отмену.

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

Как должен обрабатываться пакет? Обработано все или ничего или допускаем частичную обработку элементов?

Какие дополнительные статусы у пакета по сравнению со статусами элемента пакета? Появляется статус частично обработан?

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

Когда формировать ответ: при обработке заголовка или при обработке всего сообщения (включая тело)? Когда отпускать Клиента?

Требования к структуре и функциям сзи

Для обеспечения требований к безопасности структура СЗИ должна включать:

средства защиты информации от НСД;

средства антивирусной защиты.

Средства защиты информации от НСДдолжны включать следующие функциональные элементы:

средства управления доступом и идентификации;

средства контроля, управления и идентификации при удаленном доступе к Системе;

средства экранирования Системы.

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

Антивирусную защиту рабочих станций (АРМов);

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

Требования к средствам защиты информации от нсд

Средства защиты информации от НСД должны предусматривать:

защиту ресурсов Системы от НСД со стороны внешних телекоммуникационных сетей — сети Интернет;

регистрацию системных событий и попыток НСД к защищаемым ресурсам штатными и дополнительными средствами.

Средства защиты информации от НСД должны интегрировать:

штатные средства защиты от НСД сетевых операционных систем;

штатные средства защиты от НСД систем управления базами данных;

штатные средства защиты от НСД используемых приложений;

штатные аппаратно-программные комплексы защиты от НСД АРМов авторизуемых пользователей (администраторов);

средства защиты от НСД серверов;

средства защиты от НСД межсетевых экранов, маршрутизаторов и другого коммуникационного оборудования.

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

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

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

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

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

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

Требования к программному и аппаратному обеспечению сзи

Общие требования к типам операционных систем, типам серверов и компьютеров, а также технических средств защиты, которые должны быть задействованы в СЗИ, не должны противоречить требованиям проводимой технической политики Заказчика.

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

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

Всё компьютерное оборудование для использования в СЗИ должно поставляться с развитыми средствами интеллектуального мониторинга, настройки и диагностики.

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

Разработка СЗИ должна производиться на аппаратных средствах Исполнителя. В ходе передачи системы в эксплуатацию Исполнителем должен производиться перенос разработанного программного обеспечения СЗИ на аппаратные средства Заказчика (сервер на платформе SUN, операционная система Solaris, СУБД Oracle).

Тз требования к функциям

Приветствую всех. Имеется следующий вопрос.

1) Допустим разработка требований к системе осуществляется по Вигерсу:
Бизнес-требования — > требования пользователей (в виде сценариев использования) -> функциональные требования

2) Также допустим, имеются требования заказчика по оформлению требований к системе в виде технического задания по ГОСТ 34.

На какие пункты ТЗ должны ложиться те или иные виды требований?

С бизнес-требованиями (а точнее с образом и границами проекта) вроде бы всё просто. Это разделы 1 «Основные сведения» в части очередности создания системы и 2 «Назначение и цели создания системы».
Как лучше организовать раздел 4.2 «Требования к функциям»?
Что туда лучше поместить: функциональные требования, сценарии использования в полном виде или сокращённую форму сценариев использования?

Здравствуйте, newbie_analyst, Вы писали:

_>2) Также допустим, имеются требования заказчика по оформлению требований к системе в виде технического задания по ГОСТ 34.

_>На какие пункты ТЗ должны ложиться те или иные виды требований?

_>С бизнес-требованиями (а точнее с образом и границами проекта) вроде бы всё просто. Это разделы 1 «Основные сведения» в части очередности создания системы и 2 «Назначение и цели создания системы».
_>Как лучше организовать раздел 4.2 «Требования к функциям»?
_>Что туда лучше поместить: функциональные требования, сценарии использования в полном виде или сокращённую форму сценариев использования?

Здравствуйте, byur, Вы писали:

Сервер не найден?

Здравствуйте, Курилка, Вы писали:

К>Здравствуйте, byur, Вы писали:

К>Сервер не найден?

Спасибо, byur,
Очень познавательно.

Мы, кстати, у себя пришли точно к таким же выводам:
use cases помещаем в документ «Описание постановки задачи».
Получается, что можно относительно малой кровью быстро подготовить и согласовать ТЗ . А затем уже на этапе разработки итерировать ОПЗ.
Становится возможной итерационная модель разработки системы — требования продолжают собираться и изменяться когда уже полным ходом идёт кодирование.

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

Здравствуйте, newbie_analyst, Вы писали:

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

ТРП = ?

Здравствуйте, Курилка, Вы писали:
К>ТРП = ?

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

Здравствуйте, newbie_analyst, Вы писали:

_>Приветствую всех. Имеется следующий вопрос.

_>Как лучше организовать раздел 4.2 «Требования к функциям»?
_>Что туда лучше поместить: функциональные требования, сценарии использования в полном виде или сокращённую форму сценариев использования?

Мы помещаем сокращенную форму сценариев использования в прикладных терминах (понятных неспециалисту) плюс функциональные требования (в технических терминах, с другой, «системной» группировкой). Делается так для того, чтобы
1) проследить корректность перехода от прикладных сценариев к функциональным требованиям, т.е. выполнить трассировку требований простым анализом документа.
2) сценарии прямым образом задают объем тестирования, что влияет на сроки разработки и приемку, их обязательно надо включать. Кроме того, сценарии простым и понятным образом ограничивают функциональность системы — короче, это защищает как вас так и клиента.

Здравствуйте, Gaperton, Вы писали:

G>Здравствуйте, newbie_analyst, Вы писали:

_>>Приветствую всех. Имеется следующий вопрос.

_>>Как лучше организовать раздел 4.2 «Требования к функциям»?
_>>Что туда лучше поместить: функциональные требования, сценарии использования в полном виде или сокращённую форму сценариев использования?

G>Мы помещаем сокращенную форму сценариев использования в прикладных терминах (понятных неспециалисту) плюс функциональные требования (в технических терминах, с другой, «системной» группировкой).
В прикладных терминах сокращённая форма, а в технически тоже?

Здравствуйте, newbie_analyst, Вы писали:

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

И это правильно. Так и должно быть в случае ОКР — нечего превращать разработку в балаган. Если непонятно как делать ТЗ, то практика ГОСТ предписывает открыть сначала отдельный НИР, результатом которого и будет ТЗ. Или, действительно, делать это первым этапом. Типа, тогда получится НИОКР.

Здравствуйте, Курилка, Вы писали:

К>Здравствуйте, Gaperton, Вы писали:

G>>Здравствуйте, newbie_analyst, Вы писали:

_>>>Приветствую всех. Имеется следующий вопрос.

Другие публикации  Страховка для въезда в финляндию

_>>>Как лучше организовать раздел 4.2 «Требования к функциям»?
_>>>Что туда лучше поместить: функциональные требования, сценарии использования в полном виде или сокращённую форму сценариев использования?

G>>Мы помещаем сокращенную форму сценариев использования в прикладных терминах (понятных неспециалисту) плюс функциональные требования (в технических терминах, с другой, «системной» группировкой).
К>В прикладных терминах сокращённая форма, а в технически тоже?

Она должна быть как можно короче, при этом — достаточно полна (исчерпывающе описывать scope работ), чтоб вам не впилили потом лишней работы, и обязательно непротиворечива — допускать однозначное толкование. Это очень важно, потому, что неполнота и неясности трактуется в пользу заказчика. Мне рассказывали про случаи, когда на это люди налетали — очень неприятно. Это относится ко всему ТЗ.

Здравствуйте, Gaperton, Вы писали:
G>И это правильно. Так и должно быть в случае ОКР — нечего превращать разработку в балаган. Если непонятно как делать ТЗ, то практика ГОСТ предписывает открыть сначала отдельный НИР, результатом которого и будет ТЗ. Или, действительно, делать это первым этапом. Типа, тогда получится НИОКР.

И что, в ваших НИОКРах получается организовать проект так, что ТЗ разрабатывается полностью в срок и утверждается, а потом не меняется по ходу разработки?

И ещё вопрос, в НИОКРах, на стадии формирования ТЗ, вы пишете код, создаёте прототипы?
Какое процентное соотношение длительности этапов получается (ТЗ vs ТРП)?

Здравствуйте, newbie_analyst, Вы писали:

_>Здравствуйте, Gaperton, Вы писали:
G>>И это правильно. Так и должно быть в случае ОКР — нечего превращать разработку в балаган. Если непонятно как делать ТЗ, то практика ГОСТ предписывает открыть сначала отдельный НИР, результатом которого и будет ТЗ. Или, действительно, делать это первым этапом. Типа, тогда получится НИОКР.

_>И что, в ваших НИОКРах получается организовать проект так, что ТЗ разрабатывается полностью в срок и утверждается, а потом не меняется по ходу разработки?

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

_>И ещё вопрос, в НИОКРах, на стадии формирования ТЗ, вы пишете код, создаёте прототипы?
Это не запрещено. На стадии формирования ТЗ делается все необходимое, что помогает создать хорошее ТЗ. Если для этого необходимо написать код, сделать прототипы или макеты — это делается. Короче, никто не ограничивает вас в активностях на исследовательской фазе ТЗ, однако надо понимать, что цель этой фазы — это само ТЗ, а не код, из чего следует определенная схема расстановки приоритетов задачам. Цель кодописания на данном этапе — получение информации, необходимой для ТЗ, а не написание фрагментов конечной системы промышленного качества. Понимание этой цели позволяет радикально уменьшить объем кодописания на ней и, главное — ускорить создание ТЗ.

_>Какое процентное соотношение длительности этапов получается (ТЗ vs ТРП)?
В зависимости от работы, от степени ее неопределенности и рискованности. Я пока статистику не подводил.

Здравствуйте, Gaperton, Вы писали:

_>>Как лучше организовать раздел 4.2 «Требования к функциям»?
_>>Что туда лучше поместить: функциональные требования, сценарии использования в полном виде или сокращённую форму сценариев использования?

G>Мы помещаем сокращенную форму сценариев использования в прикладных терминах (понятных неспециалисту) плюс функциональные требования (в технических терминах, с другой, «системной» группировкой). Делается так для того, чтобы

Тут конечно возникает вопрос про то, являются ли юзкейсы (если сценарии использования = use cases) функциями . или вы эту тему в принципе не рассматриваете?

Здравствуйте, byur, Вы писали:

B>Здравствуйте, Gaperton, Вы писали:

_>>>Как лучше организовать раздел 4.2 «Требования к функциям»?
_>>>Что туда лучше поместить: функциональные требования, сценарии использования в полном виде или сокращённую форму сценариев использования?

G>>Мы помещаем сокращенную форму сценариев использования в прикладных терминах (понятных неспециалисту) плюс функциональные требования (в технических терминах, с другой, «системной» группировкой). Делается так для того, чтобы

B>Тут конечно возникает вопрос про то, являются ли юзкейсы (если сценарии использования = use cases) функциями . или вы эту тему в принципе не рассматриваете?

Да нет, разумеется, не возникает такого вопроса. Функции — это описание возможностей, ответ на вопрос «что», сценарии — описание их конкретных способов их применения, ответы на вопросы «зачем» и «как». Это не одно и то же, даже в том редком случае, когда сценарии и функции соответствуют друг другу один к одному. Пример, наглядно демонстрирующий разницу между ними: фрагмент ТЗ на видеоконтроллер для, скажем, продвинутого DVD плеера.

1.Воспроизведение видео формата SD (PAL/SECAM 576х720 и NTSC 480х720) при выходном разрешении SD
a.Без коррекции.
b.С равномерным увеличением и обрезанием границ (увеличение не более чем в 2 раза).
2.Воспроизведение видео с разрешениями меньше SD (но не менее CIF) при выходном разрешении SD.
a.Без коррекции.
b.С масштабированием в SD с независимыми коэффициентами по X и Y, и преобразованием к 4:3 (обрезанием границ).
3.Воспроизведение HD видео формата 16:9 как есть, без коррекции.
4.Воспроизведение HD видео с уменьшением до SD и преобразованием к 4:3 (обрезанием границ). Преобразование развертки входного изображения не производится, т.е. тип и частота развертки входного и выходного изображений должны совпадать.

Эти сценарии легко проверить на полноту и непротиворечивость. Их них легко вывести тестплан. Из них легко посчитать количество целевых применений видеоконтроллера — объем рынка. Им даже приоритеты легко выставить, и укоцать их в случае чего — легко.

Из этих сценариев следует требование наличия блока масштабирования изображения, вот такого:

i.Независимое масштабирование разрешения изображения по горизонтали и вертикали осуществляется с программируемыми коэффициентами. Коэффициенты меняются в диапазонах:
1. Увеличение не более чем в 2 раза с обеспечением приемлемого качества изображения. Предельный случай — увеличение из CIF (288х352) в PAL/SECAM (576×720).
2. Уменьшение не более чем в 3 раза с обеспечением приемлемого качества изображения. Предельный случай — уменьшение из 1080х1920 в NTSC (480х720).

А также вот такой функции clipping-а:

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

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

Возможно, погрязший в формализме последователь RUP назовет и то и другое use cases, и проставит между ними связь. Я предпочитаю их явно разделять терминологически. Потому, что:
1) Практика показывает, что термины «сценарий использования» и «функциональные требования» понятны всем, в том числе людям, не знакомым с RUP, а таких большинство.
2) «Сценарии» используются совсем не так, как функции. Они, на самом деле, играют важнейшую роль при управлении разработкой продукта. Именно из сценариев испольщования следует тест-план и функциональные требования. Именно к сценариям привязаны бизнес=приоритеты, именно через сценарии можно перейти от функциональных требований к бизнес-необходимости и обратно, рассчитав, скажем, объем рынка для будущего продукта, и убедившись, что технические требования соответствуют маркетинговым. Именно сценарии лишены понятны и маркетингу и техническим парням, и при этом лишены шелухи.
3)В результате, если называть и то и другое use cases, это не приводит ни к чему, кроме путаницы. Вот, например, вопросы возникают, уж не одно ли это и то же. Нет, не одно.

Здравствуйте, Gaperton, Вы писали:

G>Да нет, разумеется, не возникает такого вопроса. Функции — это описание возможностей, ответ на вопрос «что», сценарии — описание их конкретных способов их применения, ответы на вопросы «зачем» и «как». Это не одно и то же, даже в том редком случае, когда сценарии и функции соответствуют друг другу один к одному. Пример, наглядно демонстрирующий разницу между ними: фрагмент ТЗ на видеоконтроллер для, скажем, продвинутого DVD плеера.

Одно из формальных определений функции — «нечто что делает система, предположительно на основании требований к ней», по-моему это определение из книги Ian F. Alexander. Следуя тому же «формализму», требования к функциям — это таки требования . Сценарии, или юзкейсы — по большому счету функциональные требования (или функции ?) в контексте их использования. Кстати, я все-таки не понял, если у вас сценарии использования = use cases, то кто интересно будет эктором у приведенных ниже вами сценариях? Если такого отождествления нет, тогда вопрос отпадает .
Кстати, по Вигерсу, пользовательские требования описываются в частности юзкейсами.

G>1.Воспроизведение видео формата SD (PAL/SECAM 576х720 и NTSC 480х720) при выходном разрешении SD
G> a.Без коррекции.
G> b.С равномерным увеличением и обрезанием границ (увеличение не более чем в 2 раза).
G>2.Воспроизведение видео с разрешениями меньше SD (но не менее CIF) при выходном разрешении SD.
G> a.Без коррекции.
G> b.С масштабированием в SD с независимыми коэффициентами по X и Y, и преобразованием к 4:3 (обрезанием границ).
G>3.Воспроизведение HD видео формата 16:9 как есть, без коррекции.
G>4.Воспроизведение HD видео с уменьшением до SD и преобразованием к 4:3 (обрезанием границ). Преобразование развертки входного изображения не производится, т.е. тип и частота развертки входного и выходного изображений должны совпадать.

G>Эти сценарии легко проверить на полноту и непротиворечивость. Их них легко вывести тестплан. Из них легко посчитать количество целевых применений видеоконтроллера — объем рынка. Им даже приоритеты легко выставить, и укоцать их в случае чего — легко.
G>Из этих сценариев следует требование наличия блока масштабирования изображения, вот такого:

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

G>Возможно, погрязший в формализме последователь RUP назовет и то и другое use cases, и проставит между ними связь. Я предпочитаю их явно разделять терминологически. Потому, что:
G>1) Практика показывает, что термины «сценарий использования» и «функциональные требования» понятны всем, в том числе людям, не знакомым с RUP, а таких большинство.

Формальный RUP скорее всего не назовет это юзкейсами вообще. Но правда то, что он объединяет это в группу software requirements в которой конечно же выделит юзкейсы и suuplementary req., понимая под ними (suuplementary req)как дополнительные функциональные требования, не охваченные юзкейсами, так и нефункциональные требования.

G>2) «Сценарии» используются совсем не так, как функции. Они, на самом деле, играют важнейшую роль при управлении разработкой продукта. Именно из сценариев испольщования следует тест-план и функциональные требования. Именно к сценариям привязаны бизнес=приоритеты, именно через сценарии можно перейти от функциональных требований к бизнес-необходимости и обратно, рассчитав, скажем, объем рынка для будущего продукта, и убедившись, что технические требования соответствуют маркетинговым. Именно сценарии лишены понятны и маркетингу и техническим парням, и при этом лишены шелухи.

Классический Вигерс .

G>3)В результате, если называть и то и другое use cases, это не приводит ни к чему, кроме путаницы. Вот, например, вопросы возникают, уж не одно ли это и то же. Нет, не одно.

Вопрос на самом деле не в этом состоял, да и никто не отождествляет юзкейсы и функциональные требования . есть в конце концов классическая статья «Why use cases are not functions», и c другой стороны есть тенденция интерпретировать ГОСТ 34.602, который говорит именно про требования к функциям (или функциональные требования), коими юзкейсы не являются. Посему и странно видеть юзкейсы в этом разделе ТЗ.

Здравствуйте, Gaperton, Вы писали:

Получается, что у вас требования относящиеся к одной и той же функциональности (юзкейсы и вытекающие из них функциональные требования) совмещены в одном разделе ТЗ. А как проходит приёмка? Ведь, формально, проверка _каждого_ требования ТЗ должна быть отражена в «Программе и методике испытаний».
У Вас проверки в ПМИ пишутся для юзкейсов или для функциональных требований?

Здравствуйте, newbie_analyst, Вы писали:

_>Получается, что у вас требования относящиеся к одной и той же функциональности (юзкейсы и вытекающие из них функциональные требования) совмещены в одном разделе ТЗ. А как проходит приёмка? Ведь, формально, проверка _каждого_ требования ТЗ должна быть отражена в «Программе и методике испытаний».

Хм. Это интересный момент. Как то не ждал я в этом месте подставы совсем. В принципе, идея состоит в том, что программа испытаний покрывающая все сценарии должна полностью закрыть и функциональные требования — они ведь в известном смысле дублируют друг друга. Надеюсь, что никакой подставы с такой практикой мы не словим — мы как раз затем явно сценарии и прописываем, чтобы в последствии не раздулась программа испытаний . Дело в том, что глядя только на функциональные требования теоретически можно вдуть совершенно нереальную по объему программу испытаний, включая экзотические режимы, а этого хочется избежать. И главное — ничего потом не докажешь — нужен этот режим или нет. Со сценариями такой фокус не пройдет.

Другие публикации  Расписка продажа гаража образец

Хотя, вероятно, докопаться к нам при таком подходе все-таки можно. Чтобы было докопаться нельзя, можно попробовать из внешнего ТЗ, которое вы показываете заказчику, максимально сократить или убрать «функциональные требования», сделав акцент на сценариях и нефункциональных требования. Прокатит — хорошо.

_>У Вас проверки в ПМИ пишутся для юзкейсов или для функциональных требований?

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

Вообще — мне надо было сразу заметить, что мы работаем не по «программным» ГОСТ, а по микроэлектронным. Изделия у нас — микроэлектронные. ГОСТЫ другие, отсюда может быть некоторая разница в деталях, хотя принципы должны быть общие. Кроме того, есть военные ГОСТ, а есть гражданские. Там тоже есть некоторая разница в правилах. Мои парни предпочитают военные версии, так как с их слов там понятнее написано.

Поэтому, я на самом деле не знаю, до какой степени можно полагаться на то, что я говорю, в случае разработки ПО по специфическим ГОСТ. No warranty, as is. Хотя, мне как программисту военные микроэлектронные ГОСТ очень нравятся — все очень разумно.

Из нюансов. Например, разработка блока-фрагмента микросхемы (которой является видеоконтроллер из приведенного мной примера) формально не является ОКР, он является НИР. Потому, что изделия никакого на выходе не получается, а также потому, что заказчик захотел, чтобы это был НИР. А порядок выполнения и приемки НИР вроде как попроще, чем ОКР.

____________________
Кстати, в порядке иллюстрации — по поводу порядка выполнения НИР и составления ТЗ. Берем ГОСТ В 28110-91 — он реально старый (92 год), зато под рукой. Новый должен быть еще лучше . Просто для информации — как делается ТЗ. Он рекомендует 4 этапа:
1) Разработка ТЗ на НИР. ТЗ помимо целей НИР и прочего устанавливает также состав дальнейших этапов и сроки их завершения. То есть это фаза планирования и целеполагания. Целью НИР может быть разработка ТЗ на ОКР, или же НИР может быть хардкорной высокорискованной поисково-исследовательской работой, или вообще чем угодно на самом деле.
2) Выбор направления исследований.
3) Теоретические и экспериментальные исследования.
4) Приемка НИР. Программа испытаний утверждается в начале данного этапа — в рамках НИР помимо отчетов вполне могут быть разработаны какие-нибудь макеты и экспериментальные образцы, это допускается.

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

Порядок выполнения ОКР: Допускается разделение этапов, уточнение их содержания, а также устранение этапа «разработка эскизного проекта», в случае, если работа тупая и низкорискованная, или если данному ОКР предшествовал НИР. Данный порядок ориентирован на разработку изделий для серийного производства,
1) Разработка ТЗ. ТЗ помимо прочего устанавливает состав дальнейших этапов и сроки их завершения. Это фаза планирования совмещенная с фазой работы над требованиями. Достаточно разумно. Выход из фазы — мы знаем, что мы хотим сделать.
2) Разработка эскизного проекта. Здесь выбирают направление работы и вырабатывают решения по обеспечению требований ТЗ. Короче, это архитектурный этап. В составе которого, в частности, предписано делать, цитирую:
— изготовление и испытание макетов наиболее сложных и ответственных частей изделия (или изделия в целом), в объеме, необходимом для оценки правильности намеченных решений в соответствии с требованиями ТЗ. Бинго. Древний ГОСТ 92 года рекомендует прототипирование. Вот так-то. Критерий выхода из этапа — мы знаем, как мы это будем делать. Вторая фаза RUP.
3) Разработка технического проекта (разработка конструкции и технологии). Здесь делается основная разработка. Предписано также делать «макеты», но с другой целью: для проверки основных конструктивных решений изделия и его характеристик. Также, здесь думают, как заряжать серийное производство. Типа — альфа версию сделали.
4) Разработка рабочей КД и ТД, изготовление опытного образца, проведение предварительных испытаний.
Довели продукт до серийного качества, подготовили производство, запустили пробную серию, испытали. Получили release candidate.
5) Приемка ОКР. Это государственная приемка.

Принципы организации довольно гибки, и напоминают принципы устройства цикла разработки RUP. Вот так. Мне — нравится. По моему — все очень разумно. Вот, гляжу я на это, и не понимаю, о каком-таком злом ватерфоле идет речь, если еще наши деды вели разработку вот так? Это ж самый настоящий RUP. .

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

ООО «Техническая документация»

разработка техдокументации

Техническое задание на создание автоматизированной системы по ГОСТ 34.602-89

Техническое задание на создание автоматизированной системы по ГОСТ 34.602-89

Создан 21.11.2005 14:35:02

Общие положения

ТЗ на АС является основным документом, определяющим требования и порядок создания (развития или модернизации — далее создания) автоматизированной системы, в соответствии с которым проводится разработка АС и ее приемка при вводе в действие [из п. 1.1 ГОСТ 34.602-89]

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

Дополнительно могут быть разработаны ТЗ на части АС: на подсистемы АС, комплексы задач АС и т.п. в соответствии с требованиями настоящего стандарта; на комплектующие средства технического обеспечения и программно-технические комплексы в соответствии со стандартами ЕСКД и СРПП; на программные средства в соответствии со стандартами ЕСПД; на информационные изделия в соответствии с ГОСТ 19.201 и НТД, действующей в ведомстве заказчика АС.

Примечание — В ТЗ на АСУ для группы взаимосвязанных объектов следует включать только общие для группы объектов требования. Специфические требования отдельного объекта управления следует отражать в ТЗ на АСУ этого объекта [из п. 1.2 ГОСТ 34.602-89]

Требования к АС в объеме, установленном настоящим стандартом, могут быть включены в задание на проектирование вновь создаваемого объекта автоматизации. В этом случае ТЗ на АС не разрабатывают [из п. 1.3 ГОСТ 34.602-89]

Включаемые в ТЗ на АС требования должны соответствовать современному уровню развития науки и техники и не уступать аналогичным требованиям, предъявляемым к лучшим современным отечественным и зарубежным аналогам. Задаваемые в ТЗ на АС требования не должны ограничивать разработчика системы в поиске и реализации наиболее эффективных технических, технико-экономических и других решений [из п. 1.4 ГОСТ 34.602-89]

ТЗ на АС разрабатывают на основании исходных данных, в том числе содержащихся в итоговой документации стадии «Исследование и обоснование создания АС», установленной ГОСТ 34.601 [из п. 1.5 ГОСТ 34.602-89]

В ТЗ на АС включают только те требования, которые дополняют требования к системам данного вида (АСУ, САПР, АСНИ и т.д.), содержащиеся в действующих НТД, и определяются спецификой конкретного объекта, для которого создается система [из п. 1.6 ГОСТ 34.602-89]

Изменения к ТЗ на АС оформляют дополнением или подписанным заказчиком и разработчиком протоколом. Дополнение или указанный протокол являются неотъемлемой частью ТЗ на АС. На титульном листе ТЗ на АС должна быть запись «Действует с . » [из п. 1.7 ГОСТ 34.602-89]

Состав и содержание

ТЗ на АС содержит следующие разделы, которые могут быть разделены на подразделы:

  1. общие сведения;
  2. назначение и цели создания (развития) системы;
  3. характеристика объектов автоматизации;
  4. требования к системе;
  5. состав и содержание работ по созданию системы;
  6. порядок контроля и приемки системы;
  7. требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие;
  8. требования к документированию;
  9. источники разработки.

В ТЗ на АС могут включаться приложения [из п. 2.1 ГОСТ 34.602-89]

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

В ТЗ на части системы не включают разделы, дублирующие содержание разделов ТЗ на АС в целом [из п. 2.2 ГОСТ 34.602-89]

В разделе «Общие сведения» указывают:

  1. полное наименование системы и ее условное обозначение;
  2. шифр темы или шифр (номер) договора;
  3. наименование предприятий (объединений) разработчика и заказчика (пользователя) системы и их реквизиты;
  4. перечень документов, на основании которых создается система, кем и когда утверждены эти документы;
  5. плановые сроки начала и окончания работы по созданию системы;
  6. сведения об источниках и порядке финансирования работ;
  7. порядок оформления и предъявления заказчику результатов работ по созданию системы (ее частей), по изготовлению и наладке отдельных средств (технических, программных, информационных) и программно-технических (программно-методических) комплексов системы.

[из п. 2.3 ГОСТ 34.602-89]

Назначение и цели создания (развития) системы

Назначение системы

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

Для АСУ дополнительно указывают перечень автоматизируемых органов (пунктов) управления и управляемых объектов [из п. 2.4.1 ГОСТ 34.602-89]

Цели создания системы

В подразделе «Цели создания системы» приводят наименования и требуемые значения технических, технологических, производственно-экономических или других показателей объекта автоматизации, которые должны быть достигнуты в результате создания АС, и указывают критерии оценки достижения целей создания системы [из п. 2.4.2 ГОСТ 34.602-89]

Характеристики объекта автоматизации

В разделе «Характеристики объекта автоматизации» приводят:

  1. краткие сведения об объекте автоматизации;
  2. сведения об условиях эксплуатации объекта автоматизации и характеристиках окружающей среды.

Примечание — Для САПР в разделе дополнительно приводят основные параметры и характеристики объектов проектирования [из п. 2.5 ГОСТ 34.602-89]

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

Раздел «Требования к системе» состоит из следующих подразделов:

  1. требования к системе в целом;
  2. требования к функциям (задачам), выполняемым системой;
  3. требования к видам обеспечения.

Состав требований к системе, включаемых в данный раздел ТЗ на АС, устанавливают в зависимости от вида, назначения, специфических особенностей и условий функционирования конкретной системы. В каждом подразделе приводят ссылки на действующие НТД, определяющие требования к системам соответствующего вида [из п. 2.6 ГОСТ 34.602-89]

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

В подразделе «Требования к системе в целом» указывают (требования):

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

[из п. 2.6.1 ГОСТ 34.602-89]

Требования к структуре и функционированию системы

В требованиях к структуре и функционированию системы приводят (требования):

  1. к переченю подсистем, их назначению и основным характеристикм, к числу уровней иерархии и степени централизации;
  2. к способам и средствам связи для информационного обмена между компонентами;
  3. к характеристикам взаимосвязей со смежными системами, к ее совместимости, в том числе указания о способах обмена информацией (автоматически, пересылкой документов, по телефону и т. п.);
  4. к режимам функционирования;
  5. по диагностированию;
  6. к перспективам развития, модернизации.

[из п. 2.6.1.1 ГОСТ 34.602-89]

Требования к численности и квалификации персонала

В требованиях к численности и квалификации персонала на АС приводят:

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

[из п. 2.6.1.2 ГОСТ 34.602-89]

Требования к показателям назначения АС

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

Для АСУ указывают:

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

[из п. 2.6.1.3 ГОСТ 34.602-89]

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

[из п. 2.6.1.4 ГОСТ 34.602-89]

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

В требования по безопасности включают требования по обеспечению безопасности при монтаже, наладке, эксплуатации, обслуживании и ремонте технических средств системы (защита от воздействий электрического тока, электромагнитных полей, акустических шумов и т.п.), по допустимым уровням освещенности, вибрационных и шумовых нагрузок [из п. 2.6.1.5 ГОСТ 34.602-89]

Другие публикации  Mos pgu заявление в загс
Требования по эргономике и технической эстетике

В требования по эргономике и технической эстетике включают показатели АС, задающие необходимое качество взаимодействия человека с машиной и комфортность условий работы персонала [из п. 2.6.1.6 ГОСТ 34.602-89]

Требования к транспортабельности для подвижных АС

Для подвижных АС в требования к транспортабельности включают конструктивные требования, обеспечивающие транспортабельность технических средств системы, а также требования к транспортным средствам [из п. 2.6.1.7 ГОСТ 34.602-89]

Требования к эксплуатации, техническому обслуживанию, ремонту и хранению
  1. условия и регламент (режим) эксплуатации, которые должны обеспечивать использование технических средств (ТС) системы с заданными техническими показателями, в том числе виды и периодичностьобслуживания ТС системы или допустимость работы без обслуживания;
  2. предварительные требования к допустимым площадям для размещения персонала и ТС системы, к параметрам сетей энергоснабжения и т.п.;
  3. требования по количеству, квалификации обслуживающего персонала и режимам его работы;
  4. требования к составу, размещению и условиям хранениякомплекта запасных изделий и приборов;
  5. требования к регламенту обслуживания.

[из п. 2.6.1.8 ГОСТ 34.602-89]

Требования к защите информации от несанкционированного доступа

В требования к защите информации от несанкционированного доступа включают требования, установленные в НТД, действующей в отрасли (ведомстве) заказчика [из п. 2.6.1.9 ГОСТ 34.602-89]

Требования по сохранности информации

В требованиях по сохранности информации приводят перечень событий: аварий, отказов технических средств (в том числе — потеря питания) и т.п., при которых должна быть обеспечена сохранность информации в системе [из п. 2.6.1.10 ГОСТ 34.602-89]

Требования к средствам защиты от внешних воздействий

В требованиях к средствам защиты от внешних воздействий приводят:

  1. требования к радиоэлектронной защите средств АС;
  2. требования по стойкости, устойчивости и прочности к внешним воздействиям (среде применения).

[из п. 2.6.1.11 ГОСТ 34.602-89]

Требования по патентной чистоте

В требованиях по патентной чистоте указывают перечень стран, в отношении которых должна быть обеспечена патентная чистота системы и ее частей [из п. 2.6.1.12 ГОСТ 34.602-89]

Требования к стандартизации и унификации

В требования к стандартизации и унификации включают: показатели, устанавливающие требуемую степень использования стандартных, унифицированных методов реализации функций (задач) системы, поставляемые программные средства, типовые математические методы и модели, типовые проектные решения, унифицированные формы управленческих документов, установленных ГОСТ 6.10.1, общероссийские классификаторы технико-экономической информации и классификаторы других категорий в соответствии с областью их применения, требования к использованию типовых автоматизированных рабочих мест, компонентов и комплексов [из п. 2.6.1.13 ГОСТ 34.602-89]

Дополнительные требования

В дополнительные требования включают:

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

[из п. 2.6.1.14 ГОСТ 34.602-89]

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

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

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

[из п. 2.6.2 ГОСТ 34.602-89]

Требования к видам обеспечения

В подразделе «Требования к видам обеспечения» в зависимости от вида системы приводят требования к математическому, информационному, лингвистическому, программному, техническому, метрологическому, организационному, методическому и другим видам обеспечения системы [из п. 2.6.3 ГОСТ 34.602-89]

Требования к математическому обеспечению

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

Требования к информационному обеспечению

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

  1. требования к составу, структуре и способам организации данных в системе;
  2. требования к информационному обмену между компонентами системы;
  3. требования к информационной совместимости со смежными системами;
  4. требования по использованию общероссийских и зарегистрированных республиканских, отраслевых классификаторов, унифицированных документов и классификаторов, действующих на предприятии;
  5. требования по применению систем управления базами данных;
  6. требования к структуре процесса сбора, обработки, передачи данных в системе и представлению данных;
  7. требования к защите данных от разрушений при авариях и сбоях в электропитании системы;
  8. требования к контролю, хранению, обновлению и восстановлению данных;
  9. требования к процедуре придания юридической силы документам, продуцируемым техническими средствами АС (в соответствии с ГОСТ 6.10.4).

[из п. 2.6.3.2 ГОСТ 34.602-89]

Требования к лингвистическому обеспечению

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

Требования к программному обеспечению

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

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

[из п. 2.6.3.4 ГОСТ 34.602-89]

Требования к техническому обеспечению

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

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

[из п. 2.6.3.5 ГОСТ 34.602-89]

Требования к метрологическому обеспечению

В требованиях к метрологическому обеспечению приводят:

  1. предварительный перечень измерительных каналов;
  2. требования к точности измерений параметров и (или) к метрологическим характеристикам измерительных каналов;
  3. требования к метрологической совместимости технических средств системы;
  4. перечень управляющих и вычислительных каналов системы, для которых необходимо оценивать точностные характеристики;
  5. требования к метрологическому обеспечению технических и программных средств, входящих в состав измерительных каналов системы, средств встроенного контроля;
  6. требования к метрологической пригодности измерительных каналов и средств измерений, используемых при наладке и испытаниях системы;
  7. вид метрологической аттестации (государственная или ведомственная) с указанием порядка ее выполнения и организаций, проводящих аттестацию.

[из п. 2.6.3.6 ГОСТ 34.602-89]

Требования к организационному обеспечению
  1. требования к структуре и функциям подразделений, участвующих в функционировании системы или обеспечивающих эксплуатацию;
  2. требования к организации функционирования системы и порядку взаимодействия персонала АС и персонала объекта автоматизации;
  3. требования к защите от ошибочных действий персонала системы.

[из п. 2.6.3.7 ГОСТ 34.602-89]

Требования к методическому обеспечению

Для методического обеспечения САПР приводят требования к составу нормативно-технической документации системы (перечень применяемых при ее функционировании стандартов, нормативов, методик и т.п.) [из п. 2.6.3.8 ГОСТ 34.602-89]

Состав и содержание работ по созданию (развитию) системы

Раздел «Состав и содержание работ по созданию (развитию) системы» должен содержать перечень стадий и этапов работ по созданию системы в соответствии с ГОСТ 34.601-90, сроки их выполнения, перечень организаций-исполнителей работ, ссылки на документы, подтверждающие согласие этих организаций на участие в создании системы или запись, определяющую ответственного (заказчик или разработчик) за проведение этих работ.

В данном разделе также приводят:

  1. перечень документов по ГОСТ 34.201-89, предъявляемых по окончании соответствующих стадий и этапов работ;
  2. вид и порядок проведения экспертизы технической документации (стадия, этап, объем проверяемой документации, организация-эксперт);
  3. программу работ, направленных на обеспечение требуемого уровня надежности разрабатываемой системы (при необходимости);
  4. перечень работ по метрологическому обеспечению на всех стадиях создания системы с указанием их сроков выполнения и организаций-исполнителей (при необходимости).

[из п. 2.7 ГОСТ 34.602-89]

Порядок контроля и приемки системы

В разделе «Порядок контроля и приемки системы» указывают:

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

[из п. 2.8 ГОСТ 34.602-89]

Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие

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

  1. приведение поступающей в систему информации к виду, пригодному для обработки с помощью ЭВМ (в соответствии с требованиями к информационному и лингвистическому обеспечению);
  2. изменения, которые необходимо осуществить в объекте автоматизации;
  3. создание условий функционирования объекта автоматизации, при которых гарантируется соответствие создаваемой системы требованиям, содержащимся в ТЗ;
  4. создание необходимых для функционирования системы подразделений и служб;
  5. сроки и порядок комплектования штатов и обучения персонала.

Например для АСУ приводят:

  • изменения применяемых методов управления;
  • создание условий для работы компонентов АСУ, при которых гарантируется соответствие системы требованиям, содержащимся в ТЗ.

[из п. 2.9 ГОСТ 34.602-89]

Требования к документированию

В разделе «Требования к документированию» приводят:

  1. согласованныйразработчиком и заказчиком системы перечень подлежащих разработке комплектов и видов документов, соответствующих требованиям ГОСТ 34.201 и НТД отрасли заказчика; перечень документов, выпускаемых на машинных носителях; требования к микрофильмированию документации;
  2. требования по документированию комплектующих элементов межотраслевого применения в соответствии с требованиями ЕСКД и ЕСПД;
  3. при отсутствии государственных стандартов, определяющих требования к документированию элементов системы, дополнительно включают требования к составу и содержанию таких документов.

[из п. 2.10 ГОСТ 34.602-89]

Источники разработки

В разделе «Источники разработки» должны быть перечислены документы и информационные материалы (технико-экономическое обоснование, отчеты о законченных научно-исследовательских работах, информационные материалы на отечественные, зарубежные системы-аналоги и др.), на основании которых разрабатывалось ТЗ и которые должны быть использованы при создании системы [из п. 2.11 ГОСТ 34.602-89]

В состав ТЗ на АС при наличии утвержденных методик включают приложения, содержащие:

Приложения включают в состав ТЗ на АС по согласованию между разработчиком и заказчиком системы [из п. 2.12 ГОСТ 34.602-89]

Правила оформления

Разделы и подразделы ТЗ на АС должны быть размещены в порядке, установленном в разд. 2 настоящего стандарта [из п. 3.1 ГОСТ 34.602-89]

ТЗ на АС оформляют в соответствии с требованиями ГОСТ 2.105 на листах формата A4 по ГОСТ 2.301 без рамки, основной надписи и дополнительных граф к ней. Номера листов (страниц) проставляют, начиная с первого листа, следующего за титульным листом, в верхней части листа (над текстом, посередине) после обозначения кода ТЗ на АС [из п. 3.2 ГОСТ 34.602-89]

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

«Окончательное требование (значение) уточняется в процессе. и согласовывается протоколом с. на стадии. ».

При этом в текст ТЗ на АС изменений не вносят [из п. 3.3 ГОСТ 34.602-89]

На титульном листе помещают подписи заказчика, разработчика и согласующих организаций, которые скрепляют гербовой печатью. При необходимости титульный лист оформляют на нескольких страницах. Подписи разработчиков ТЗ на АС и должностных лиц, участвующих в согласовании и рассмотрении проекта ТЗ на АС, помещают на последнем листе. Форма титульного листа ТЗ на АС приведена в приложении 2. Форма последнего листа ТЗ на АС приведена в приложении 3 [из п. 3.4 ГОСТ 34.602-89]

При необходимости на титульном листе ТЗ на АС допускается помещать установленные в отрасли коды, например: гриф секретности, код работы, регистрационный номер ТЗ и др. [из п. 3.5 ГОСТ 34.602-89]

Титульный лист дополнения к ТЗ на АС оформляют аналогично титульному листу технического задания. Вместо наименования «Техническое задание» пишут «Дополнение № . к ТЗ на AC . » [из п. 3.6 ГОСТ 34.602-89]

На последующих листах дополнения к ТЗ на АС помещают основание для изменения, содержание изменения и ссылки на документы, в соответствии с которыми вносятся эти изменения [из п. 3.7 ГОСТ 34.602-89]

При изложении текста дополнения к ТЗ следует указывать номера соответствующих пунктов, подпунктов, таблиц основного ТЗ на АС и т. п. и применять слова: «заменить», «дополнить», «исключить», «изложить в новой редакции» [из п. 3.8 ГОСТ 34.602-89]

Все права защищены; 2019 Ohrangos.ru