Спецификация это документ определяющий: спецификация — это… Что такое спецификация? — ICQ Information Center. Продажа ICQ. Продажа уинов. Продажа асек. ICQ sale. Sale ICQ.

Спецификация это документ определяющий: спецификация — это… Что такое спецификация?

Содержание

Выполненный в виде таблицы документ, определяющий состав какого-либо изделия, 12 (двенадцать) букв

Большая Советская Энциклопедия Значение слова в словаре Большая Советская Энциклопедия
(позднелатинского specificatio, от лат. species ≈ вид, разновидность и facio ≈ делаю), определение и перечень специфических особенностей, уточнённая классификация чего-либо, Один из основных документов системы технической документации . В Единой системе …

Толковый словарь русского языка. С.И.Ожегов, Н.Ю.Шведова. Значение слова в словаре Толковый словарь русского языка. С.И.Ожегов, Н.Ю.Шведова.
-и, ж.

(книжн.). см. специфицировать. Определение и перечень специфических особенностей, уточненная классификация чего-н. Один из основных компонентов технической документации. прил. специфика-цибнный, -ая, -ое (ко 2 знач.).
Толковый словарь русского языка. Д.Н. Ушаков Значение слова в словаре Толковый словарь русского языка. Д.Н. Ушаков
спецификации, ж. только ед. Действие по глаг. специфицировать; разработка, перечисление подробностей, деталей (книжн.). Документ с описанием изготовленного предмета (механизма, машины и т. д.), по к-рому определяют его себестоимость или цену (тех., торг.). …
Википедия
Значение слова в словаре Википедия
Спецификация — (, от лат. species — род, вид, разновидность и facio — делают) может означать: определение и перечень особенностей, уточнённая классификация чего-нибудь; инженерный термин, обозначающий набор требований и параметров, которым удовлетворяет …
Новый толково-словообразовательный словарь русского языка, Т. Ф. Ефремова. Значение слова в словаре Новый толково-словообразовательный словарь русского языка, Т. Ф. Ефремова.
ж. Перечисление специфических особенностей чего-л., распределение по разрядам; классификация. ж. Один из основных компонентов технической документации в форме таблицы, содержащий детальное описание объекта.

Технология — 8
ТЕМА 8

СПЕЦИФИКАЦИЯ И ЧТЕНИЕ ЧЕРТЕЖА ИЗДЕЛИЙ,

ИМЕЮЩИХ ДЕТАЛИ С КРУГЛЫМИ ПОВЕРХНОСТЯМИ
Что такое спецификация изделий?
Согласно определению, приведённому в техническом словаре, спецификация — это выполненный в форме таблицы документ, определяющий состав какого-либо изделия. Простейшая форма спецификации — основная надпись (рис. 1, а). В ней содержатся обозначения составных частей, их наименования и количество.

А как читают чертёж?
Рис. 1. Чертеж детали: а — спецификация (основная надпись)
Чтение чертежа заключается в представлении по плоским изображениям объемной формы предмета и в определении его размеров. Эту работу рекомендуется проводить в такой последовательности:
1. Прочитать основную надпись чертежа. Из нее можно узнать название детали, наименование материала, из которого ее изготовляют, масштаб изображений и другие сведения.
2. Определить, какие виды детали даны на чертеже, какой из них является главным
3. Рассмотреть виды во взаимной связи и попытаться определить форму детали со всеми подробностями. Этой задаче помогает анализ изображений, данных на чертеже. Представив по чертежу геометрическую форму каждой части детали, мысленно объединяют их в единое целое.

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

Спецификация сборочного чертежа

Каждый сборочный чертеж сопровождают спецификацией.
Спецификация представляет собой текстовой документ, определяющий состав изделия, состоящего из двух и более частей.
Составляют спецификацию на каждую сборочную единицу.
Спецификация выполняется и оформляется на отдельных листах формата А4 по форме, определяемой ГОСТ 2.108-68 (СТ СЭВ 2516-80).
Если сборочный чертеж выполнен на листе формата А4, допускается совмещать спецификацию с чертежом (рис. 3).
В спецификации выполняются графы, размеры, расположение и содержание которых приведены на рис. 1.
Спецификация в общем случае состоит из разделов, которые располагают в следующей последовательности:
1) документация;
2) комплексы;
3) сборочные единицы;
4) детали;
5) стандартные изделия;
6) прочие изделия;
7) материалы;
8) комплекты.
Рис. 1. Спецификация к сборочному чертежу
При большом количестве составных частей изделия спецификация может располагаться на нескольких листах; в нижней части первого листа должна быть основная надпись по форме 2 (ГОСТ 2.

104-68), а на всех последующих — по упрощенной форме (рис. 2).
Рис. 2. Образец выполнения спецификации по упрощенной форме
Как указывалось выше, спецификация состоит из разделов, последовательность расположения и характер содержания которых представлены в табл. 1.
Таблица 1.
Наименование раздела

Характер содержания раздела

Документация Документы, составляющие комплект конструкторских документов специфицируемого изделия (кроме его спецификации). Например: сборочный чертеж, схема, пояснительная записка, паспорт, технические условия и т. п.
Комплексы Комплексы, непосредственно входящие в специфицируемое изделие
Сборочные единицы Сборочные единицы (их спецификации), входящие в специфицируемое изделие и на которые выполнены чертежи, например, соединения, выполненные запрессовкой, сваркой, пайкой, армированные и другие виды соединений
Детали Детали, входящие непосредственно в специфицируемое изделие, и на которые выполнены чертежи
Стандартные изделия Изделия, примененные по следующим категориям стандартов: государственным, отраслевым, республиканским, и стандартам предприятий
Прочие изделия Изделия, примененные не по стандартам, а по техническим условиям, каталогам, прейскурантам. Примеры: лимб, нониус по нормали станкостроения
Материалы Материалы, применяемые при сборке. Примеры: проволока, ткань, сталь угловая, набивка – шнур и т. п.
Комплекты Комплекты, непосредственно входящие в специфицируемое изделие, например комплект монтажных частей, комплект инструмента и принадлежностей и т. п.
Наличие тех или иных разделов в спецификации определяется составом специфицируемого изделия.
При изучении курса «Черчение» спецификация обычно состоит из следующих разделов: «Документация», «Сборочные единицы», «Детали», «Стандартные изделия», «Прочие изделия», «Материалы». Ниже приводятся основные сведения о заполнении граф спецификации для этих разделов.
Наименование каждого раздела записывается в виде заголовка в графе «Наименование» и подчеркивается. Перед наименованием каждого раздела, а также после наименования оставляется по одной свободной строке.

После каждого раздела спецификации необходимо оставлять несколько свободных строк для дополнительных записей.
В графе «Наименование» указывается:
В разделе «Документация» — наименование документа, например: «Сборочный чертеж», «Габаритный чертеж», «Пояснительная записка», «Технические условия» и т. п.

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

В разделе «Стандартные изделия» записывают условное обозначение изделия (табл. 2). Изделия записывают в последовательности категорий стандартов. В пределах каждой категории стандартов обозначения изделий записывают по однородным группам, например: крепежные изделия, арматура, изделия разные (подшипники, ремни и т. п.), смазочные устройства, гидравлика, электрооборудование. В пределах каждой группы — в алфавитном порядке наименования изделия (например, «Болт», «Винт», «Гайка», «Шайба»).
В пределах каждого наименования — в порядке возрастания обозначений стандарта (например, Болт М10, Болт М12 и т. д.). В пределах каждого обозначения стандарта — в порядке возрастания основных параметров или размеров изделия (например диаметра). В пределах основного параметра или размера изделия — в порядке возрастания прочих параметров или размеров (например длины). Если стандартные изделия изготовляются по одному стандарту и основные параметры и размеры их обозначаются одним числом или буквой, то в обозначении их по ГОСТ 2.108-68 допускаются упрощения (не указывается номер стандарта), например шайбы: Шайба 3, Шайба 4 и т. д.

В разделе «Прочие изделия» указывают наименования и условные обозначения изделий в соответствии с документами на их поставку, с указанием обозначений этих документов. Изделия записывают по однородным группам, в пределах каждой группы — в алфавитном порядке наименований изделий, а в пределах каждого наименования — в порядке возрастания основных параметров или размеров изделия.

В разделе «Материалы» указывают обозначения материалов, установленные стандартами на эти материалы. Материалы записывают по видам в последовательности, определяемой ГОСТ 2.108-68 (СТ СЭВ 2516-80): металлы черные, магнитоэлектрические и ферромагнитные, цветные, благородные, редкие и т. д.
Детали сборочных единиц изготовляют из материалов, которые указаны в основных надписях рабочих чертежей этих деталей. Материал деталей, на которые рабочие чертежи не изготовляются, указывают в спецификации в разделе «Материалы».
Таблица 2. Примеры условных обозначений стандартных изделий на учебных чертежах
Стандартные изделия

Пример условного обозначения

Болт:
Болт М10х60 ГОСТ 7798-70
Шпилька:
Шпилька М16х120 ГОСТ 2034-80
Шайба плоская:
Шайба 12. 01 ГОСТ 11371-78
Шайба граверная:
Шайба 20, 65Г ГОСТ 6402-70
Гайка:
Гайка М12 ГОСТ 5915-81
Шплинт:
Шплинт 5х28,2 ГОСТ 397-79
Винт:
Винт М12х50 ГОСТ 17475-80
Штифт:
Штифт 12h8х60 ГОСТ 23360-78
Шпонка:
Шпонка 18х11х100 ГОСТ 23360-78
Подшипник:
Подшипник 110 ГОСТ 8138-75
В графе «Поз.» (позиция) указывают порядковые номера составных частей, непосредственно входящих в специфицируемое изделие, в последовательности записи их в спецификации.
Составным частям раздела «Документация» номера позиций не присваивают.
В графе «Кол.» (количество) указывают:
в разделе «Материалы» — общее количество материала конкретной позиции на одно специфицируемое изделие с указанием единиц измерения;

в разделе «Документация» эта графа не заполняется;

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

В графе «Примечание» указываются дополнительные сведения, относящиеся к изделиям, записанным в спецификацию. Например, для деталей, на которые не выпущены чертежи, указывают массу.
В графе «Формат» записывают обозначение формата листа конструкторского документа. Для деталей, на которые не выпущены чертежи, проставляют шифр «БЧ» (без чертежа).
В графе «Зона» указывают обозначение зоны чертежа, в которой находится записываемая составная часть изделия. Разбивка поля чертежа на зоны производится при выполнении сборочного чертежа на формате сравнительно большого размера.
В графе «Обозначение» указывают обозначение документов, сборочных единиц деталей.

Более подробные сведения о заполнении спецификации приведены в ГОСТ 2.105-79 (СТ СЭВ 2667-80) и ГОСТ 2.108-68 (СТ СЭВ 2516-80).
Текст спецификации может быть написан от руки чертежным шрифтом, напечатан на машинке или выполнен типографским способом [ГОСТ 2.105-79 (СТ СЭВ 2667-80)]. Если сборочный чертеж выполнен на листе формата А4, спецификация может быть помещена на сборочном чертеже, при этом шифр «СБ» в обозначении сборочного чертежа не проставляется (рис. 3).
Рис. 3. Спецификация, выполненная на одном листе со сборочным чертежом
Каждому конструкторскому документу должно быть присвоено обозначение, записываемое в основную надпись. ГОСТ 2.201-80 устанавливает систему обозначений, которая в учебных условиях вызывает значительные трудности.
В связи с этим при изучении курса «Черчение» обозначение конструкторских документов может осуществляться упрощенно, например обозначение каждого конструкторского документа состоит из буквенно-цифрового индекса, определяющего изделие (например, ТШ-30), и трех пар чисел — ТШ-30. 00.00.00.
Первая пара чисел обозначает порядковый номер сборочной единицы, входящей в изделие; вторая — порядковый номер сборочной единицы, входящей в предыдущие сборочные единицы; третья — порядковый номер деталей, входящих в изделие или сборочную единицу.
Обозначение сборочного чертежа изделия идентично обозначению в соответствующей спецификации, но в конце этого обозначения записывается шифр «СБ» (сборочный).
***
Система обозначения чертежей
Для всех отраслей машиностроения и приборостроения по ГОСТ 2.201-80 установлены две системы обозначения чертежей: первая — обезличенная, вторая — предметно-обезличенная. Основой обезличенной системы является единый классификатор, в котором каждое изделие, деталь, сборочная единица закодированы определенным номером.
Первые четыре знака (рис. 4) определяют индекс организации-разработчика. Этот индекс может состоять из букв или букв и цифр. Последующие шесть знаков дают классификационную характеристику изделия, определяемую по классификатору. Три последних знака — порядковый регистрационный номер.
Рис. 4. Система обозначения чертежей
В предметно-обезличенном варианте обозначений вместо индекса организации-разработчика проставляется индекс изделия. Как видно из схемы (рис. 4), классификационная характеристика по единому классификатору остается та же. Она позволяет быстро находить изделия с данной характеристикой, а также обеспечивает использование документации на ранее выпущенные изделия.
Подробные сведения о системе обозначения чертежей в ГОСТ 2.201-80.
На сборочном чертеже в условиях учебного заведения рекомендуется в соответствии с обозначениями всего изделия в целом присвоить обозначения и составным частям.
Например, подъемный кран с индексом ПК02 обозначается ПК02.00.00.00; одна из сборочных единиц подъемного крана — блок направляющий — с номером 06 обозначается ПК02.06.00.00; одна из деталей блока направляющего — планка — с номером 04 обозначается ПК02. 06.00.04; одна из сборочных единиц блока направляющего — ролик с запрессованной в него втулкой — с номером 01 обозначается ПК02.06.01.02 и т. п.
Чтение и деталирование сборочных чертежей

Главная страница

Дистанционное образование

Специальности

Учебные дисциплины

Олимпиады и тесты

Конструкторские документы текстовые — Энциклопедия по машиностроению XXL
Общие положения Виды и комплектность конструкторских документов Текстовые документы Спецификация [c.119]
Виды изделий (101 ) Виды и комплектность конструкторских документов (102 ) Стадии разработки (103 ) Основные надписи (104 ) Общие требования к текстовым документам (105 ) Текстовые документы (106) Спецификация (108 ) Основные требования к чертежам (109 ) Нормоконтроль (111) Ведомость держателей подлинников (112) Групповые и базовые конструкторские документы (113 ) Технические условия. Правила построения, изложения и оформления (114) Технические условия. Порядок согласования, утверждения и государственной регистрации (115) Карта технического уровня и качества продукции (116) Применения покупных изделий (117) Техническое предложение (118) Эскизный. проект (119) Технический проект (120) Технологический контроль конструкторской документации (121). [c.312]

На учебных чертежах геометрического и проекционного черчения рекомендуется применять не стандартную, а упрощенную основную надпись (рис. 22,6). Об основной надписи для текстовых конструкторских документов будет сказано в соответствующей главе. [c.17]
Конструкторскими документами называются графические (чертеж, схема и др.) и текстовые (спецификация, технические условия и др.) документы, которые в отдельности или в совокупности определяют состав и устройство изделия и содержат необходимые данные для его разработки, изготовления, контроля, приемки, эксплуатации и ремонта. [c.126]
К конструкторским документам относят графические и текстовые документы, которые в отдельности или в совокупности определяют устройство изделия и содержат все необходимые данные для его изготовления, контроля, приемки, эксплуатации и ремонта. [c.216]
Примечание. Как видно из сравнения рис. 207, 143 и 144, содержание основной надписи на текстовых конструкторских документах несколько отличается от основной надписи чертежей. Обычно, в учебных целях, на листах спецификации разрешается выполнять основную надпись по типу рис. 143. [c.227]
К конструкторским документам в соответствии с ГОСТ 2.102—68 принадлежат графические (чертежи) и текстовые документы, которые определяют состав и устройство изделия и содержат все данные для его разработки, изготовления, контроля, эксплуатации и ремонта. [c.301]
Все конструкторские и другие документы, как правило, меют наименование и обозначение документа и организации, выпустившей зтот документ. Чтобы легко было отыскать соответствующий конструкторский документ, предусмотренный Единой системой конструкторской документации, и необходимые данные, приведенные в основной надписи, ГОСТ 2.104—68 устанавливает формы, размеры и порядок заполнения основных надписей (то, что раньше называли угловым штампом) и дополнительных граф к ним. С тем чтобы сократить количество форм конструкторских документов, ГОСТ 2.104—68 предусматривает всего три формы основных надписей одна для графических документов (черт. 26) и две для текстовых (одна — для первого [c.25]
Виды ОСНОВНЫХ надписей, предназначенные для чертежей и схем, приведены на черт. 4 (форма 1) для текстовых конструкторских документов, заглавных листов — на черт. 5 (форма 2) последующих листов — на черт. 6 (форма 2 а). Цифры в кружках на основных надписях и соответствующие им пункты нижеследующего текста указывают порядок заполнения граф [c.8]
Спецификация — это текстовой конструкторский документ, определяющий состав специфицированного изделия и разработанной на него рабочей документации, предназначенный для комплектования конструкторских документов, подготовки производства и изготовления изделия. [c.165]

Комплект — два и более изделий, не соединенных сборочными операциями при изготовлении и представляющих набор изделий, имеющих общее эксплуатационное назначение вспомогательного характера, например комплекты запасных частей, инструментов и принадлежностей, измерительной аппаратуры и т. п. Конструкторские документы — графические и текстовые документы, определяющие состав и устройство изделия и содержащие необходимые данные для его разработки или изготовления, контроля, приемки, эксплуатации и ремонта. [c.206]
ТЕКСТОВЫЕ КОНСТРУКТОРСКИЕ ДОКУМЕНТЫ [c.208]
Рис. 3. Основные надписи и дополнительные графы для текстовых конструкторских документов а — для первого и заглавного листа (форма 2) б — Для последующих листов (форма 2а).
Видь конструкторских документов. Конструкторские документы (КД) подразделяются на графические (чертежи, схемы, графики) и текстовые (спецификации, технические условия, различные ведомости). Как известно, в основу классификации той или иной группы явлений могут быть положены различные признаки. Различные признаки положены и в основу подразделения конструкторской документации на виды, а именно [c.53]
Виды и комплектность конструкторских документов установлены ГОСТ 2.102—68. При этом к конструкторским документам относят графические и текстовые документы, которые в отдельно- [c.338]
Значительная часть конструкторской документации представляется в форме текстовой информации. Для изготовления текстовых документов в САПР применяются печатающие устройства. Указанный ГОСТ дает формы конструкторских документов и извещений об изменениях, выполненных на алфавитно-цифровых печатающих устройствах. [c.268]
ФОРМИРОВАНИЕ ТЕКСТОВЫХ КОНСТРУКТОРСКИХ ДОКУМЕНТОВ [c. 100]
К программному обеспечению, осуществляющему автоматизацию формирования текстовых конструкторских документов, предъявляются следующие требования [c.100]
Структура программного обеспечения автоматизированного получения текстовых конструкторских документов приведена на рис. 5.11. [c.100]
В качестве примера текстового конструкторского документа, выполненного автоматизированно, приведена распечатка спецификации (рис. 5.13). [c.104]
Конструкторскими документами являются графические (чертежи, схемы) и текстовые (спецификации, технические условия, пояснительные записки и г. п.) документы, которые в отдельности или в совокупности определяют состав и устрой- [c.348]
Основная надпись для чертежей и схем должна соответствовать форме 1 (рис. 16.3), основная надпись для текстовых конструкторских документов (первый или заглавный лист) — форме 2 (рис. 16.4), последующие листы всех конструкторских документов — форме 2а (рис. 16,5). [c.355]
Рио. 16.4. Основная надпись для текстовых конструкторских документов (первый или заглавный лист) по ГОСТ 2.104 — 68 (высота граф 27—2У должна быть 14 мм вместо 7 мм) [c.357]
Групповые и базовые конструкторские документы должны содержать данные о двух и более изделиях (деталях, сборочных единицах, комплексах и комплектах), обладающих общими конструктивными признаками при некоторых различиях между собой. Термины, определения и правила выполнения групповых и базовых чертежей (схем), чертежей (схем) исполнений, спецификаций, текстовых документов приведены в ГОСТ 2.113 — 75 (СТ СЭВ 1179 — 78). Некоторые термины приведены ниже. [c.440]

Графическая часть выполняется в соответствии с требованиями ГОСТ 2.109—73. Основные надписи в конструкторских документах, формы, размеры и порядок заполнения документов установлены ГОСТ 2.104—68. Требования к выполнению спецификаций установлены ГОСТ 2. 108—68, текстовых документов — ГОСТ 2.105—79. Формы и правила выполнения ведомостей, пояснительной записки и расчетов установлены ГОСТ 2.106—68. [c.31]
Разработаны рекомендации по применению требований стандартов к выполнению конструкторских документов на устройства вывода ЭВ.М в 1979 г. на основе результатов опытного внедрения этих рекомендаций разработан и утвержден стандарт ЕСКД (ГОСТ 2.004—79), устанавливающий правила выполнения конструкторских документов (текстовых, табличных и графических) на печа-таю[цих и графических устройствах вывода ЭВМ. [c.68]
В номенклатуру курсового проекта по деталям машин в соответствии с ГОСТ 2.102—68 ЕСКД входят следующие конструкторские документы текстовые документы — пояснительная записка (шифр ПЗ) графические документы — чертеж общего вида редуктора (шифр ВО), чертежи деталей. [c.10]
Виды изделий (101) Виды и комплектность конструкторских документов (102) Стадии разработки (103) Основные надписи (104) Общие требования к текстовым документам (105) Текстовые документы (106) Спецификация (108) Основные требования к чертежам (109) Патентный формуляр (ПО) Нормоконт-роль (111) Ведомость держателей подшипников (112) Групповые конструкторские документы (ИЗ) Правила выполнения технических условий (114). [c.363]
Ку )соной проект по Дет 1лям машин прсдстаиляст собой совокупность конструкторских документов графических (чертежи, схемы) и текстовых (пояснительная записка, спецификации). [c.388]
В задачи оформления конструкторской документации входит изготовление текстовых и графических документов. Текстовые документы, кроме описательной части, содержат характеристики и паспортные данные узлов и агрегатов технические условия на изготовление, сборку, наладку и эксплуатацию спецификации и т. д. К графическим документам относятся чертежи сборочные и де-талировочные, графики структурных сеток кинематических цепей, циклограммы и зависимости для выбора параметров режимов работы агрегатов и устройств, схемы структурные, функциональные и принципиальные (электрические, электронные, гидравлические и т. д.). [c.9]
Переходя к вопросу рассмотрения математических моделей изделий конструкторских документов ЕСКД и ЕСТД (рис. 361), следует отметить, что они характеризуются параметрами, определяющими их форму (геометрию) и размеры, а также многими другими сведениями материалом, шероховатостью поверхности, допусками, предельными отклонениями формы и расположения поверхностей, термообработкой, покрытием и другими техническими требованиями. Большинство этих сведений задается в текстовой форме, что не требует сложной пе- [c.327]
Десятый раз (ел содернгит главные положения стандартов ЕСКД, включая оформление и общие правила выполнения чертежей, текстовых и других конструкторских документов. В одиннадцатом разделе представлен справочный материал общего назначения, используемый при конструировании и выполнении чертежей и других конструкторских документов. [c.4]
Со гавить спецификацию изделия, содержащую Леречень составных частей, входящих в специфицируемое изделие, текстовые конструкторские документы, относящиеся к этому изделию (в данном примере — схему деления изделия на составные части), запись сборочного чертежа изделия, к которому относится спецификация. Разделы спецификации располагают в тайой последовательности (см. рис. 71) Документация , Сборочные единицы , Деталиж, Стандартные изделия , Материалы . [c.80]
Пособие содержит семь глав и три приложения. В главе 1 даны структура и основные принципы построения систем АКД предложена обобщенная модель системы АКД. Систематизированно рассмотрены технические и программные средства машинной графики. В главе 2 описан базовый комплекс программных средств ЭПИГРАФ для автоматизации разработки и выполнения конструкторской документации, разработанный и практически реализованный в МИЭТ под руководством автора и основного разработчика А.В.Антипова. В главе 3 рассматривается информационная база как основной компонент системы АКД, способы накопления графической информации в ней. В главе 4 исследуются различные методы автоматизированной разработки конструкторской документации (КД), рассматривается прикладное программное обеспечение АКД. В главе 5 приведены примеры АКД электронных устройств на типовых и унифицированных несущих конструкциях, включающих также формирование текстовых конструкторских документов. В главе 6 даны примеры решения некоторых геометрических задач. В главе 7 изложен подход к созданию учебно-методического комплекса для подготовки специалистов в области АКД. [c.3]
В случае отсутствия спецификации изделия (например, на стадии [)азработки технического проекта) коэффициенты при-меняемс1сти и повторяемости рассчитываются ориентировочно по результатам рассмотрения конструкторских документов на данное изделие, указанных в ведомости технического проекта ( в соответствии с ГОСТ 2.106 — 68 ЕСКД. Текстовые документы ). [c.157]
Часть 1 в основном включает сведения по ЕСКД, являющейся базовой системой, которая используется в той или иной степени в других системах стандартов. Текстовые документы, схемы, чертежи выполнены на требуемом уровне, необходимом для курсовых и дипломных проектов. Конструкторские документы на изделия микроэлектроники ввиду их специфичности выделены в самостоятельный раздел ЕСКД. Представлена документация при проектировании интегральных микросхем и микропроцессорных систем. Приведены также краткие справочные сведения, необходимые в учебном проектировании, из СПДС и СИБИД. [c.5]

Для проектировщиков естественной формой представления изделий и технологических процессов являются текстовые и графические конструкторские документы. Для ЭВМ графическое представление информации не пригодно, так как она может хранить и обрабатывать только дискретные двоичные цифровые коды. При любом обмене графической информацией между проектировщиками и ЭВМ возникает необходимость цифрового кодирования и графического декодированияТ данных, выполняемого вручную или с помощью специальных технических и программных средств. [c.5]
ЕСКД устанавливает виды изделий, виды и комплектность конструкторских документов. Изделия разделяются на детали, сборочные единицы, комплексы и комплекты, а в зависимости от наличия или отсутствия в них составных частей — на неспецифи-цированные и специфицированные детали. К конструкторским документам ЕСКД относятся графические и текстовые документы, которые в отдельности или совокупности определяют состав и устройство изделия и содер>1 ат данные для его разработки, изготовления, контроля, приемки, эксплуатации и ремонта. [c.31]
Словарь терминов

Государственная итоговая аттестация (ГИА-IX)
Государственная итоговая аттестация по образовательным программам основного общего образования

ОГЭ
Основной государственный экзамен

ГВЭ
Государственный выпускной экзамен

ОВЗ
Выпускники с ограниченными возможностями здоровья

ОО
Общеобразовательные организация

ППЭ
Пункт проведения экзамена

АИС «ГИА»
Автоматизированная информационная система «Государственная (итоговая) аттестация выпускников 9 классов»

МОУО
Муниципальный орган управления образованием

Бланки
Стандартные бумажные листы определенного формата, специально разработанные ФЦТ для оформления участниками ОГЭ на экзаменационные задания

Контрольные измерительные материалы (КИМ)
Различные типы заданий на проверку умений и навыков (задания с выбором ответа, задания с кратким ответом, задания с развернутым ответом)

Демоверсия (демонстрационный вариант)
Демоверсия является полным аналогом типовых КИМ, которые будут использоваться на государственной итоговой аттестации по образовательным программам основного общего образования в текущем году

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

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

Шкалирование
Процесс формирования тестовых шкал по правилам начисление тестовых баллов на основе первичных баллов с использованием специальной методики и полных статистических данных о результатах тестирования

Апелляция
Процедура, призванная защитить интересы участника ГИА-IX, в случае выявления нарушений в процедуре проведения экзамена или несогласия с результатом оценивания экзаменационной работы в рамках ГИА-IX

Государственная экзаменационная комиссия (ГЭК-IX)
Создается в целях организации подготовки и проведения ГИА-IX и обеспечения соблюдения прав обучающихся при проведении ГИА-IX

Предметная комиссия (ПК)
Специалисты-преподаватели по определенному предмету, которые привлекаются для проверки экзаменационных работ, пройдя предварительно обучающие курсы

Конфликтная комиссия (КК)
Создается в целях обеспечения соблюдения единых требований и разрешения спорных вопросов при оценке экзаменационных работ в рамках проведения ГИА-IX, а также защиты прав обучающихся, участвующих в ГИА-IX

Общественные наблюдатели
Лица, привлекаемые для усиления контроля за ходом проведения ГИА-IX

Минпросвещения России
Министерство просвещения Российской Федерации

Рособрнадзор
Федеральная служба по надзору в сфере образования и науки

ФЦТ
Федеральный центр тестирования

ФИПИ
Федеральный институт педагогических измерений

ОКУ ИАЦ КО
Областное казнное учреждение «Информационно-аналитический центр» Курской области

РЦОИ
Региональный центр обработки информации

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

Региональная информационная система (РИС)
Региональная информационная система обеспечения проведения государственной итоговой аттестации обучающихся, освоивших основные образовательные программы основного общего и среднего общего образования
1.
Спецификация пиловочных бревен. Составление плана раскроя пиловочника сырья
Похожие главы из других работ:
Водоснабжение и водоотведение
11. СПЕЦИФИКАЦИЯ ОБОРУДОВАНИЯ
№ пп Наименование материала Единицы измерения Количество единиц ГОСТ 1 Трубы стальные d=15 мм М 306 3262-75 Трубы стальные d=20 мм М 178 3262-75 Трубы стальные d=25 мм М 15 3262-75 Трубы стальные d=32 мм М 15 3262-75 Трубы стальные…
Исследование работы тестоделителя «Suction Dough Divider SD-180» и определение неисправностей, нарушающих его работоспособность
2.7 Техническая спецификация
Рис. 14 Габариты тестоделителя Производительность — 750 — 1800 тестовых заготовокчас Весовой диапазон — 120 — 1600 грамм Мощность двигателя — 1.1 кВт Вес нетто — 540 кг Вес брутто — 665 кг Упаковочные габариты — 1.70х0.90х2.05=3…
Организация работы и разработки Белорусского государственного университета информатики и радиоэлектроники
4.
2.4 Спецификация
Спецификацию — документ, определяющий состав изделия и всей конструкторской документации, относящейся к этому изделию, — следует составлять на отдельных листах формата А4 на каждую сборочную единицу, комплекс и комплект…
Особенности производства строганого шпона из древесины лиственницы (сибирской, даурской)
4.1 Поперечная распиловка бревен на кряжи
Рациональный способ раскроя лиственничных кряжей, разработанный СвердНИИПдревом, позволяет получить максимальный выход шпона с учетом требований технических условий и особенностей строения древесины…
Проектирование и расчет лесопильного цеха
2 ТЕХНОЛОГИЧЕСКИЙ РАСКРОЙ БРЕВЕН
Процесс переработки первичного древесного сырья в продукцию лесоперерабатывающей промышленности включает следующие технологические операции: продольный раскрой бревен…
Проектирование лесопильного предприятия
3. Окорка древесины, комплексная линия для окорки и сортировки бревен.
Окорка хлыстов и бревен на лесопильных предприятиях необходима по следующим соображениям: 1. Высококачественная технологическая щепа может быть получена для ЦБП только при наличии окорки пиловочника. 2…
Процесс сорбционного выщелачивания золота.
6. Спецификация.
Позиция Наименование и техническая характеристика Тип, марка оборудования. Завод — изготовитель Единица измерения Кол — во 1-1, 4-1 Измерение расхода воздуха на сорбцию и цианирование, потока пульпы, потока сорбента…
Разработка и изготовление изделия «Шкатулка с геометрической резьбой»
Спецификация шкатулки
Таблица № Наименование…
Разработка модельной конструкции и макета демисезонного мужского пальто
2.5 Спецификация деталей
№п/п Наименование деталей Количество лекал Количество кроя Детали верха драп 1 спинка 1 2 4 полочка 1 2 5 подборт 1 2 6 Верхняя часть рукава 1 2 7 Нижняя часть рукава 1 2 8 Верхний воротник 0. ..
Разработка повседневной женской обуви зимнего сезона
3.3 Спецификация
Таблица 4 — Спецификация [6]. Наименование деталей Количество деталей на одну пару Наименование материалов ГОСТ (ТУ) Толщина деталей, мм Вид обработки 1 2 3 4 5 6 1. Детали верха обуви 1.1 Союзка 2 Яловка 939-88 1,4 — 1…
Разработка технологического процесса лесопильного цеха
2.3 Выбор и обоснование способа раскроя бревен на пиломатериалы
При выборе способа раскроя следует руководствоваться следующими положениями. Если в наличии имеется сырье средних и больших диаметров и требуется выработать чисто обрезные пиломатериалы с большим удельным весом досок одной ширины…
Разъемные соединения деталей
4. СПЕЦИФИКАЦИЯ
Спецификацией называется конструкторский документ, определяющий состав сборочной единицы, комплекса или комплекта. Спецификация может означать: 1. определение и перечень специфических особенностей, уточнённая классификация чего-нибудь; 2…
Раскрой бревна в лесном производстве
4. Выделение из спецификации пиломатериалов основных досок и составление ведомости выбора толщины брусьев и диаметров бревен
Выделяем из спецификации пиломатериалов основные доски поставов. К основным следует отнести все толстые доски от 32 мм и более. Ширины этих досок определят толщину бруса. По толщине бруса определяем расчетный диаметр бревна, заносим в графу 3…
Технологические процессы лесопильного цеха
3. Выбор и обоснование способов раскроя бревен
Выработка пиломатериалов требуемых размеров и качества при распиловке связана с необходимостью выполнять операционной последовательности технологический процесс формирования ширины, толщины и длины выпиливаемой пилопродукции…
Технология лесопильного процесса
4.1 Расчет производительности и количества оборудования для раскроя бревен и брусьев
Сменная производительность бревнопильного оборудования определяется по формуле: , (29) где — пропускная способность оборудования; Т — время смены, мин, Т = 480 мин. ..
ЕСКД. Виды и комплектность конструкторских документов
МЕЖГОСУДАРСТВЕННЫЙ СТАНДАРТ
ЕДИНАЯ СИСТЕМА КОНСТРУКТОРСКОЙ ДОКУМЕНТАЦИИ
ВИДЫ И КОМПЛЕКТНОСТЬ
КОНСТРУКТОРСКИХ ДОКУМЕНТОВ
ГОСТ 2.102-68
МОСКВА
2002

МЕЖГОСУДАРСТВЕННЫЙ СТАНДАРТ

Единая система конструкторской документации

ВИДЫ И КОМПЛЕКТНОСТЬ КОНСТРУКТОРСКИХ
ДОКУМЕНТОВ

Unified system for design documentation.
Types and sets of design documentations.

ГОСТ
2.102-68

Дата введения 1971-01-01
Настоящий стандарт устанавливает виды и комплектность конструкторских документов на изделия всех отраслей промышленности.
(Измененная редакция, Изм. № 3, 8).
1.1. (Исключен, Изм. № 8)
1.2. Конструкторские документы (именуемые в дальнейшем «документы»), подразделяют на виды, указанные в табл. 1.
(Измененная редакция, Изм. № 8).
Таблица 1

Вид документа

Определение

Чертеж детали

Документ, содержащий изображение детали и другие данные, необходимые для ее изготовления и контроля

Сборочный чертеж

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

Чертеж общего вида

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

Теоретический чертеж

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

Габаритный чертеж

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

Электромонтажный чертеж

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

Монтажный чертеж

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

Упаковочный чертеж

Документ, содержащий данные, необходимые для выполнения упаковывания изделия

Схема

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

Спецификация

Документ, определяющий состав сборочной единицы, комплекса или комплекта

Ведомость спецификаций

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

Ведомость ссылочных документов

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

Ведомость покупных изделий

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

Ведомость разрешения применения покупных изделий

Документ, содержащий перечень покупных изделий, разрешенных к применению в соответствии с ГОСТ 2. 124

Ведомость держателей подлинников

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

Ведомость технического предложения

Документ, содержащий перечень документов, вошедших в техническое предложение

Ведомость эскизного проекта

Документ, содержащий перечень документов, вошедших в эскизный проект

Ведомость технического проекта

Документ, содержащий перечень документов, вошедших в технический проект

Пояснительная записка

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

Технические условия

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

Программа и методика испытаний

Документ, содержащий технические данные, подлежащие проверке при испытании изделий, а также порядок и методы их контроля

Таблица

Документ, содержащий в зависимости от его назначения соответствующие данные, сведенные в таблицу

Расчет

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

Эксплуатационные документы

Документы, предназначенные для использования при эксплуатации, обслуживании и ремонте изделия в процессе эксплуатации

Ремонтные документы

Документы, содержащие данные для проведения ремонтных работ на специализированных предприятиях

Инструкция

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

перед видом документа «Чертеж детали»:

Электронная модель детали

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

после вида документа «Чертеж детали»:

Электронная модель сборочной единицы

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

после вида документа «Схема»:

Электронная структура изделия

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

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

Ведомость электронных документов

Документ, содержащий перечень документов, выполненных в электронной форме

(Измененная редакция, Изм. № 1, 4, 7, 8).
1.2а. Все графические документы (чертежи, схемы) могут быть выполнены в электронной форме как электронные чертежи и (или) как электронные модели изделия. Все текстовые документы могут быть выполнены в электронной форме. Вид документа и его наименование при этом сохраняются.
1.2б. Документы одного вида и наименования, независимо от формы выполнения, являются равноправными и взаимозаменяемыми.
1.3. Документы в зависимости от стадии разработки подразделяются на проектные (техническое предложение, эскизный проект и технический проект) и рабочие (рабочая документация).
(Введено дополнительно, Изм. № 8)
1.4. Наименования конструкторских документов в зависимости от способа их выполнения и характера использования приведены в табл. 2.
Таблица 2

Наименование документа

Определение

Документы в бумажной форме

Документы в электронной форме

1. Оригиналы

Документы, выполненные на любом материале, предназначенные для изготовления по ним подлинников и заверенные разработчиком

Электронные документы, предназначенные для изготовления подлинников и подписанные электронной цифровой подписью (ЭЦП) разработчика

2. Подлинники

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

Электронные документы, оформленные установленными ЭЦП и предназначенные для получения с них копий

3. Дубликаты

Копии подлинников, обеспечивающие идентичность воспроизведения подлинника, выполненные на любом материале, позволяющем снятие с них копий

Электронные документы, полученные посредством электронного копирования подлинника, подписанные установленными ЭЦП лиц, ответственных за их изготовление, и предназначенные для изготовления с них копий

4. Копии

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

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

(Измененная редакция, Изм. № 4, 8).
(Поправка, ИУС 4-2007).
1.4а. В случаях, когда одновременно применяют бумажные и электронные формы документов, допускается их взаимное преобразование друг в друга. При этом соблюдают следующие правила:
— преобразование не должно уменьшать порядковый номер документа по табл. 2;
— документы, полученные в результате взаимного преобразования, должны иметь соответствующие ссылки друг на друга;
— взаимное соответствие между этими документами обеспечивает разработчик
(Введено дополнительно, Изм. № 8)
1.5. Документы, предназначенные для разового использования в производстве «(документация материального макета, стендов для лабораторных испытаний и др.), допускается выполнять в виде эскизных конструкторских документов. Наименования эскизных документов в зависимости от способа выполнения и характера использования аналогичны приведенным в табл. 2.
(Измененная редакция, Изм. № 8).
2.1. При определении комплектности конструкторских документов на изделия следует различать:
основной конструкторский документ;
основной комплект конструкторских документов;
полный комплект конструкторских документов.
2.2. Основной конструкторский документ изделия в отдельности или в совокупности с другими записанными в нем конструкторскими документами полностью и однозначно определяют данное изделие и его состав.
За основные конструкторские документы в зависимости от формы выполнения принимают:
для деталей - чертеж детали и (или) электронную модель детали;
для сборочных единиц, комплексов и комплектов — спецификацию и (или) электронную структуру изделия.
Изделие, примененное по конструкторским документам, выполненным в соответствии со стандартами Единой системы конструкторской документации, записывают (включают) в документы других изделий, в которых оно применено, за обозначением своего основного конструкторского документа. Считается, что такое изделие применено по своему основному конструкторскому документу.
(Измененная редакция, Изм. № 8).
2.3. Основной комплект конструкторских документов изделия объединяет конструкторские документы, относящиеся ко всему изделию (составленные на все данное изделие в целом), например, сборочный чертеж, принципиальная электрическая схема, технические условия, эксплуатационные документы.
Допускается, при необходимости, в комплект конструкторской документации включать документы различных форм выполнения (бумажная и электронная) одного вида (табл. 1).
(Измененная редакция, Изм. № 8).
Конструкторские документы составных частей в основной комплект документов изделия не входят.
2.4. Полный комплект конструкторских документов изделия составляют (в общем случае) из следующих документов:
основного комплекта конструкторских документов на данное изделие;
основных комплектов конструкторских документов на все составные части данного изделия, примененные по своим основным конструкторским документам.
Примеры построения полного комплекта конструкторских документов комплекса приведены в приложениях А и Б.
(Измененная редакция, Изм. № 8).
2.5. В основной комплект конструкторских документов изделия могут входить также групповые конструкторские документы, если эти документы распространяются и на данное изделие, например, групповые технические условия.
2.6. Номенклатура конструкторских документов, разрабатываемых на изделия, в зависимости от стадий разработки приведена в табл. 3.
При выполнении и (или) формировании комплекта конструкторской документации вид документа и форму выполнения устанавливает разработчик, если это не указано в техническом задании.
(Измененная редакция, Изм. № 8).

Таблица 3

Код документа

Наименование документа

Техническое предложение

Эскизный проект

Технический проект

Рабочая документация на

Дополнительные указания

детали

сборочные единицы

комплексы

комплекты

—

1. Электронная модель детали

—

—

○¹

●¹

—

—

—

Требования по ГОСТ 2.052

—

2. Чертеж детали

—

—

○¹

●¹

—

—

—

Допускается не выпускать чертеж (модель) в случаях, оговоренных в ГОСТ 2.109

ЭСБ

3. Электронная модель сборочной единицы

○⁴

○⁴

○⁴

—

○⁴

○⁴

○⁴

Требования по ГОСТ 2.052

СБ

4. Сборочный чертеж

—

—

—

—

●²

—

—

—

ВО

5. Чертеж общего вида

○⁴

○⁴

●⁴

—

—

—

—

—

ТЧ

6. Теоретический чертеж

—

○⁴

○⁴

○

○⁴

○⁴

—

—

ГЧ

7. Габаритный чертеж

○

○

○^{2; 4}

○⁴

○^{2; 4}

○

—

—

МЭ

8. Электромонтажный чертеж

—

—

—

—

○

—

—

—

МЧ

9. Монтажный чертеж

—

—

—

—

○²

○

○

—

УЧ

10. Упаковочный чертеж

—

—

—

○⁴

○

○

○

—

По ГОСТ 2.701

11. Схемы

○

○

○

—

○

○

○

Номенклатура различных видов схем установлена ГОСТ 2.701

—

12. Электронная структура изделия

○

○

○

—

●

●

●

Требования по ГОСТ 2.053

—

13. Спецификация

—

—

—

—

●

●

●

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

ВС

14. Ведомость спецификаций

—

—

—

—

○

○

○

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

ВД

15. Ведомость ссылочных документов

—

—

—

—

○

○

○

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

ВП

16. Ведомость покупных изделий

—

○

○

—

○

○

○

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

ВИ

17. Ведомость разрешения применения покупных изделий

—

○

○

—

○

○

○

Ведомость разрешения применения покупных изделий рекомендуется составлять на изделия, предназначенные для самостоятельной поставки

ДП

18. Ведомость держателей подлинников

—

—

—

—

○

○

○

—

ПТ

19. Ведомость технического предложения

●

—

—

—

—

—

—

Ведомость технического предложения, ведомость эскизного проекта, ведомость технического проекта и пояснительную записку для сборочных единиц и комплексов не составляют, если они входят в состав более сложного изделия например, в комплекс), на которое составлены эти документы, содержащие все необходимые сведения по входящим в них сборочным единицам и комплектам

ЭП

20. Ведомость эскизного проекта

—

●

—

—

—

—

—

ТП

21. Ведомость технического проекта

—

—

●

—

—

—

—

ПЗ

22. Пояснительная записка

●³

●³

●³

—

—

—

—

ВДЭ

23. Ведомость электронных документов

—

○

○

—

○

○

○

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

ТУ

24. Технические условия

—

—

○

○

○

○

○

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

Технические условия на изделия народнохозяйственного назначения единичного производства разового изготовления допускается не составлять. Разработку, изготовление, приемку и поставку таких изделий допускается осуществлять по техническому заданию, разработанному в соответствии с ГОСТ 15.001*

ПМ

25. Программа и методика испытаний

—

○

○

○

○

○

—

—

ТБ

26. Таблицы

○

○

○

○

○

○

○

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

РР

27. Расчеты

○³

○³

○³

○

○

○

○

И…

28. Инструкция

—

—

—

○

○

○

○

Д…

29. Документы прочие

○

○

○

○

○

○

○

По ГОСТ 2.601

30. Документы эксплуатационные

—

—

—

○

○

○

○

Номенклатура, формы выполнения и обязательность выполнения эксплуатационных документов установлена ГОСТ 2.601

По ГОСТ 2.602

31. Документы ремонтные

—

—

—

○

○

○

○

Номенклатура, формы выполнения и обязательность выполнения ремонтных документов установлена ГОСТ 2.602

(Измененная редакция, Изм. № 8).
* На территории Российской Федерации действует ГОСТ Р 15.201-2000.
Условные обозначения:
● — документ обязательный;
○ — документ составляют в зависимости от характера, назначения или условий производства изделия с учетом требований, изложенных в графе «Дополнительные указания»;
— — документ не составляют.
* На территории Российской Федерации действует ГОСТ Р 15.201-2000.
Примечания:
1. Документы, для которых над условными обозначениями проставлены одинаковые цифры, могут быть по усмотрению разработчика совмещены. При этом совмещенному документу присваивается код и наименование документа, имеющего наименьший порядковый номер по табл. 3.
2. Номенклатура и форма выполнения конструкторских документов изделий, разрабатываемых по заказам Министерства обороны, должна быть согласована с заказчиком (представительством заказчика).
3. Документы, предназначенные для изделий единичного и вспомогательного производств, допускается выполнять с упрощениями, указанными в ГОСТ 2.109 и ГОСТ 2.503.
4. Спецификацию, ВС, ВД, ВП, ВИ, ДП, ПТ, ЭП, ТП, ВДЭ, ЗИ, ВЭ и др. при выполнении автоматизированным способом следует получать, при возможности, как отчет из электронной структуры изделия
(Измененная редакция, Изм. № 1, 2, 4, 5, 6, 7, 8).

2.7. В обозначении основных конструкторских документов в конце обозначения код документа не указывают. При обозначении всех остальных конструкторских документов в конце обозначения проставляется код документа по табл. 3.
2.8. Электронным документам присваивают дополнительные коды в соответствии с табл. 4, которые указывают в реквизитной части документа.
Таблица 4

Вид документа

Дополнительный код документа

Электронная структура изделия

ЭС

Все чертежи в виде электронной модели изделия (детали, сборочные единицы)

ЗБ

Все чертежи и схемы в электронной форме

2Б

Все текстовые документы в электронной форме

ТЭ

Примечания:
1. Если электронная модель изделия (детали, сборочной единицы) однозначно определяет все необходимые для соответствующего вида документа данные, то ей присваивают код документа согласно табл. 3.
2. Если необходимо совместное использование электронной модели изделия (детали, сборочной единицы) и чертежа, то чертежу присваивают код документа согласно табл. 3, а электронной модели изделия (детали, сборочной единице) присваивается соответственно код «МД» или «МС».
(Измененная редакция, Изм. № 8).
Примечания:
1. Основной конструкторский документ изделия показан в овале.
2. Документы основного комплекта показаны в прямоугольниках (в примере показана только часть документов основного комплекта, предусмотренных в табл. 3).
3. Документы, обведенные в двойные рамки, предусматриваются только для изделий, предназначенных для самостоятельной поставки.
4. Число ступеней входимости для комплексов, сборочных единиц и комплектов, а также число входящих комплектов сборочных единиц, комплектов и деталей не ограничиваются.
(Измененная редакция, Изм. № 4).
Примечание. Разбитые на графы текстовые документы (Спецификация, ВС, ВД, ВП, ВИ, ДП, ПТ, ЭП, ТП, ВЭД, ЗИ и др.), как правило, не ассоциируют с элементами структуры изделия, их следует получать в виде отчетов из электронной структуры изделия.
(Введено дополнительно, Изм. № 8)
ИНФОРМАЦИОННЫЕ ДАННЫЕ
1. РАЗРАБОТАН И ВНЕСЕН Комитетом стандартов, мер и измерительных приборов при Совете Министров СССР
2. УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Постановлением Комитета стандартов, мер и измерительных приборов при Совете Министров СССР 28.06.68 № 1029
3. (Исключен, Изм. № 8)
4. ВЗАМЕН ГОСТ 5295-60 в части разд. I и II и ГОСТ 5291-60
5. ССЫЛОЧНЫЕ НОРМАТИВНО-ТЕХНИЧЕСКИЕ ДОКУМЕНТЫ
(Измененная редакция, Изм. № 8).
6. ПЕРЕИЗДАНИЕ (июнь 2002 г.) с Изменениями № 1, 2, 3, 4, 5, 6, 7, утвержденными в августе 1981 г., ноябре 1981 г., марте 1985 г., сентябре 1985 г., октябре 1986 г., сентябре 1987 г., июле 1988 г. (ИУС № 10-81, 4-82, 5-85, 12-85, 1-87, 12-87, 11-88)
СОДЕРЖАНИЕ

Каковы системные требования, спецификации / программное обеспечение (SRS)?
Спецификация требований к системе (SRS) (также известная как Спецификация требований к программному обеспечению) — это документ или набор документации, описывающий функции и поведение системы или программного приложения. Он включает в себя множество элементов (см. Ниже), которые пытаются определить предполагаемую функциональность, необходимую клиенту для удовлетворения различных пользователей.
В дополнение к определению того, как система должна вести себя, спецификация также определяет на высоком уровне основные бизнес-процессы, которые будут поддерживаться, какие упрощающие допущения были сделаны и какие ключевые параметры производительности должны быть соблюдены системой.
Основные элементы
В зависимости от используемой методологии (гибкая или водопадная) уровень формальности и детализации в SRS будет варьироваться, но в целом SRS должен включать описание функциональных требований, системных требований, технических требований, ограничений, допущений и критериев приемлемости. Каждый из них более подробно описан ниже:
Функциональные и системные требования
Бизнес и системные сценарии использования
Ограничения и допущения
Драйверы для бизнеса
В этом разделе описаны причины, по которым заказчик хочет построить систему.Обоснование новой системы важно, поскольку она будет определять решения, принимаемые бизнес-аналитиками, системными архитекторами и разработчиками. Еще одна веская причина для документирования бизнес-обоснования системы заключается в том, что заказчик может сменить персонал во время проекта. Документация, которая четко определяет бизнес-причины для системы, поможет поддерживать проект, если первоначальный спонсор уйдет.
Драйверы могут включать как проблемы (причины, по которым текущие системы / процессы недостаточны), так и возможности (новые бизнес-модели, которые система сделает доступными).Обычно для мотивации новой системы требуется сочетание проблем и возможностей.
Бизнес-модель
В этом разделе описывается базовая бизнес-модель клиента, которую система должна будет поддерживать. Сюда входят такие элементы, как организационный контекст, диаграммы текущего и будущего состояния, бизнес-контекст, ключевые бизнес-функции и диаграммы потоков процессов. Этот раздел обычно создается на этапе функционального анализа.
Функциональные и системные требования
Этот раздел обычно состоит из иерархической организации требований с бизнес-требованиями / функциональными требованиями на самом высоком уровне и подробными системными требованиями, перечисленными в качестве их дочерних элементов.
Как правило, требования записываются в виде формулировок типа «Системе требуется способность делать x» с дополнительными деталями и информацией, включенной по мере необходимости.
Случаи использования бизнеса и системы
Этот раздел обычно состоит из диаграммы вариантов использования UML, которая иллюстрирует основные внешние объекты, которые будут взаимодействовать с системой, а также различные варианты использования (цели), которые им необходимо будет выполнить. Для каждого варианта использования будет формальное определение шагов, которые необходимо выполнить для достижения бизнес-цели, вместе с любыми необходимыми предварительными и последующими условиями.
Бизнес-варианты использования обычно выводятся из функциональных требований, а системные варианты использования обычно выводятся из системных требований.
Шаги вариантов использования также могут быть представлены в виде блок-схемы:
Технические требования
Этот раздел используется для перечисления любых «нефункциональных» требований, которые по сути воплощают техническую среду, в которой должен работать продукт, и включают технические ограничения, в которых он должен работать.Эти технические требования имеют решающее значение для определения того, как функциональные требования более высокого уровня будут разложены на более конкретные системные требования.
Системные качества
Этот раздел используется для описания «нефункциональных» требований, которые определяют «качество» системы. Эти предметы часто называют «-способностями», потому что большинство из них оканчиваются на «умения». Они включали такие элементы, как: надежность, доступность, удобство обслуживания, безопасность, масштабируемость, ремонтопригодность.
В отличие от функциональных требований (которые обычно имеют описательную форму), характеристики системы обычно состоят из таблиц конкретных показателей, которым система должна соответствовать, чтобы быть принятой.
Ограничения и допущения
В этом разделе будут описаны любые конструктивные ограничения, которые были наложены на конструкцию системы заказчиком, тем самым исключив некоторые варианты из рассмотрения разработчиками. Кроме того, этот раздел будет содержать любые предположения, которые были сделаны группой разработки требований при сборе и анализе требований.Если какое-либо из предположений окажется ложным, спецификацию системных требований необходимо будет повторно оценить, чтобы убедиться, что задокументированные требования по-прежнему действительны.
Критерии приемки
В этом разделе будут описаны критерии, по которым заказчик будет «подписывать» окончательную систему. В зависимости от методологии это может происходить в конце фазы тестирования и обеспечения качества или в гибкой методологии в конце каждой итерации.
Критерии обычно относятся к необходимости завершения всех пользовательских приемочных тестов и исправлению всех дефектов / ошибок, которые соответствуют заранее определенному приоритету или порогу серьезности.
Альтернативы
В гибких методологиях, таких как экстремальное программирование или формальная схватка, статическая документация, такая как спецификация требований к программному обеспечению (SRS), обычно избегается в пользу более легкой документации требований, а именно с помощью пользовательских историй и приемочных тестов.
Этот подход требует, чтобы заказчик был легко доступен для разъяснения требований во время разработки, а также предполагает, что члены команды, ответственные за написание пользовательских историй с заказчиком, будут разработчиками, создающими систему.Более формальный подход может потребоваться, если клиент недоступен и / или отдельная группа бизнес-аналитиков будет разрабатывать требования.
В методологиях быстрой разработки приложений (RAD), таких как DSDM или унифицированный процесс (RUP, AUP), спецификация требований часто хранится на более высоком уровне с большей частью подробных требований, воплощенных в прототипах и макетах планируемой системы. Эти прототипы представляют собой более наглядный способ представления требований и помогают заказчику легче понять, что планируется (и, следовательно, обеспечить более своевременную обратную связь).
Функциональные и нефункциональные требования: спецификация и типы
Время чтения: 11 минут
Четко определенные требования — важные знаки на пути к успешному проекту. Они заключают формальное соглашение между клиентом и поставщиком, что они оба работают для достижения одной и той же цели. Высококачественные подробные требования также помогают снизить финансовые риски и обеспечить выполнение проекта в соответствии с графиком.Согласно определению Свода знаний бизнес-анализа (BABOK), требования — это удобное представление потребности.
Создание требований — сложная задача, поскольку она включает в себя набор процессов, таких как выявление, анализ, спецификация, проверка и управление. В этой статье мы обсудим основные типы требований к программным продуктам и дадим ряд рекомендаций по их использованию.
Виды требований
BABOK, который является признанным набором отраслевых стандартов бизнес-анализа, предлагает следующую классификацию требований.
Бизнес-требования
Сюда входят высокоуровневые заявления о целях, задачах и потребностях. Бизнес-требования не содержат каких-либо подробностей или конкретных функций. Они просто формулируют проблему и бизнес-цель, которую необходимо достичь, например,
увеличение доходов / пропускной способности / охвата клиентов,
снижение затрат / ошибок,
улучшенное обслуживание клиентов и т. Д.
Требования к пользователю (заинтересованной стороне)
Потребности отдельных групп заинтересованных сторон (менеджеры высшего звена, неуправленческий персонал, клиенты и т. Д.)) указаны, чтобы определить, чего они ожидают от конкретного решения. Эта группа служит мостом между обобщенными бизнес-требованиями и требованиями конкретных решений. Они изложены в Спецификации требований к пользователю и могут включать, например, возможность создавать различные отчеты, просматривать историю и статус заказов, управлять базами данных клиентов и т. Д.
Требования к решению
Требования к решению описывают конкретные характеристики, которыми должен обладать продукт для удовлетворения потребностей заинтересованных сторон и самого бизнеса.Они делятся на две большие группы.
Функциональные требования определяют, что должен делать продукт, каковы его характеристики и функции.
Нефункциональные требования описывают общие свойства системы. Они также известны как атрибутов качества .
Переходные требования
Дополнительная группа требований определяет, что требуется от организации для успешного перехода из текущего состояния в желаемое с новым продуктом.Они необходимы только на короткий период времени, пока происходит переход. Примеры могут быть такими: « пользователей должны быть обучены работе с системой» или «предыдущие данные должны быть перенесены в облачное хранилище».
Чтобы узнать больше о документации и планировании программного обеспечения, рассмотрите возможность просмотра нашего видеообъяснения.
Документация и планирование программного обеспечения за 11 минут или меньше
Эта статья посвящена функциональным и нефункциональным типам требований.Прежде чем углубляться в подробное описание, давайте сравним их рядом.
Функциональные и нефункциональные требования
Функциональные требования — это особенности продукта или функции, которые разработчики должны реализовать, чтобы пользователи могли выполнять свои задачи. Поэтому важно прояснить их как для команды разработчиков, так и для заинтересованных сторон. Как правило, функциональные требования описывают поведение системы в определенных условиях. Например:
Система отправляет запрос на одобрение после того, как пользователь вводит личную информацию.
Функция поиска позволяет пользователю искать среди различных счетов-фактур, если они хотят кредитовать выставленный счет.
Система отправляет электронное письмо с подтверждением при создании новой учетной записи.
Нефункциональные требования, не связанные с функциональностью системы, а определяют, как система должна работать. Вот несколько примеров:
Страницы сайта должны загружаться за 3 секунды при общем количестве одновременных пользователей <5 тысяч.
Система должна поддерживать 20 миллионов пользователей без снижения производительности.
Вот краткое сравнение, а затем мы перейдем к более подробному объяснению каждой группы.
Функциональные и нефункциональные требования
Виды функциональных требований и их спецификации
Функциональные требования можно классифицировать по разным критериям. Например, мы можем сгруппировать их на основе функций , которые данная функция должна выполнять в конечном продукте.Конечно, они будут отличаться в зависимости от разрабатываемого продукта, но для примера можно указать типы функциональных требований
.
Аутентификация
Уровни авторизации
Соответствие законам и постановлениям
Внешние интерфейсы
Обработка транзакций
Отчетность
Деловые правила и др.
Требования обычно записываются в тексте, особенно для проектов, управляемых Agile. Однако они также могут быть визуальными.Вот наиболее распространенные форматы и документы:
Документ со спецификацией требований к программному обеспечению
Примеры использования
Истории пользователей
Иерархическая структура работ (WBS) или функциональная декомпозиция
Прототипы
Модели и схемы
Давайте посмотрим, о чем каждый из них.
Документ со спецификацией требований к программному обеспечению
Как функциональные, так и нефункциональные требования могут быть формализованы в документе «Спецификация требований к программному обеспечению» (SRS) .Чтобы узнать больше о документации по программному обеспечению в целом, прочтите нашу статью по этой теме. SRS содержит описания функций и возможностей, которые должен обеспечивать продукт. В документе также определены ограничения и предположения. SRS может быть единым документом, сообщающим о функциональных требованиях, или может сопровождать другую документацию по программному обеспечению, например истории пользователей и сценарии использования.
Мы не рекомендуем составлять SRS для всего решения до начала разработки, но вам следует задокументировать требования для каждой отдельной функции перед ее созданием.Получив первоначальный отзыв пользователя, вы можете обновить документ.
СГД должна включать следующие разделы:
Назначение . Определения, обзор системы и предыстория.
Общее описание. Допущения, ограничения, бизнес-правила и видение продукта.
Особые требования. Системные атрибуты, функциональные требования и требования к базе данных.
Очень важно сделать SRS доступной для чтения всем заинтересованным сторонам.Вы также должны использовать шаблоны с визуальным акцентом, чтобы структурировать информацию и помочь в ее понимании. Если у вас есть требования, хранящиеся в других форматах документов, дайте ссылку на них, чтобы читатели могли найти необходимую информацию.
Пример: Если вы хотите увидеть настоящий документ, загрузите этот пример SRS, созданный в Университете штата Мичиган, который включает все упомянутые выше пункты в дополнение к представлению вариантов использования для иллюстрации частей продукта.Ниже приводится краткий список содержимого SRS.
Шаблон спецификации требований к программному обеспечению, источник: Требования к программному обеспечению от Карла Вигерса Джой Битти
Примеры использования
Сценарии использования описывают взаимодействие между системой и внешними пользователями, которое приводит к достижению определенных целей.
Каждый вариант использования включает три основных элемента:
Актеры. Это внешние пользователи, которые взаимодействуют с системой.
Система . Система описывается функциональными требованиями, которые определяют предполагаемое поведение продукта.
Целей . Цели взаимодействия между пользователями и системой обозначены как цели.
Есть два формата для представления вариантов использования:
Спецификация варианта использования структурирована в текстовом формате
Диаграмма вариантов использования
Спецификация варианта использования представляет последовательность событий вместе с другой информацией, относящейся к этому варианту использования.Типовой шаблон спецификации варианта использования включает следующую информацию:
Описание
Условие до и после взаимодействия
Базовый путь взаимодействия
Альтернативный путь
Путь исключения
Пример:
Шаблон спецификации сценария использования
Диаграмма вариантов использования не содержит много деталей. Он показывает общий обзор отношений между участниками, различными вариантами использования и системой.
Схема вариантов использования включает следующие основные элементы:
Сценарии использования. Обычно нарисованные овалами варианты использования представляют различные сценарии взаимодействия, которые субъекты могут иметь с системой ( войти в систему, совершить покупку, просмотреть элементы, и т. Д. , ).
Границы системы. Границы обведены рамкой, в которой сгруппированы различные варианты использования в системе.
Актеры. Это цифры, которые изображают внешних пользователей (людей или системы), которые взаимодействуют с системой.
Ассоциации. Ассоциации нарисованы линиями, показывающими различные типы отношений между участниками и вариантами использования.
Пример:
Пример диаграммы вариантов использования
Истории пользователей
История пользователя — это задокументированное описание функции программного обеспечения с точки зрения конечного пользователя. Пользовательская история описывает, что именно пользователь хочет от системы. В проектах Agile пользовательские истории организованы в бэклог , который представляет собой упорядоченный список функций продукта.В настоящее время пользовательские истории считаются лучшим форматом для элементов невыполненной работы.
Типичная пользовательская история записывается так:
Как <тип пользователя>, я хочу <некоторая цель>, чтобы <какая-то причина>.
Пример :
Как администратор, я хочу добавлять описания к продуктам, чтобы пользователи могли позже просматривать эти описания и сравнивать продукты.
Истории пользователей должны сопровождаться критериями приемлемости .Это условия, которым должен удовлетворять продукт, чтобы он был принят пользователем, заинтересованными сторонами или владельцем продукта. У каждой пользовательской истории должен быть хотя бы один критерий приемлемости. Эффективные критерии приемки должны быть проверяемыми, краткими и полностью понятными для всех членов команды и заинтересованных сторон. Они могут быть записаны в виде контрольных списков, обычного текста или в формате «Дано / Когда / Тогда».
Пример:
Вот пример контрольного списка критериев приемлемости для пользовательской истории, описывающей функцию поиска:
Поле поиска доступно на верхней панели.
Поиск запускается, когда пользователь нажимает Отправить .
Заполнитель по умолчанию — серый текст. Введите имя .
Заполнитель исчезает, когда пользователь начинает печатать.
Язык поиска — английский.
Пользователь может ввести не более 200 символов.
Не поддерживает специальные символы. Если пользователь ввел специальный символ в поле поиска, отображается предупреждающее сообщение: Ввод поиска не может содержать специальные символы .
Наконец, все пользовательские истории должны соответствовать модели качества INVEST :
I — Независимый
N — договорная
V — ценный
E — Примерно
S — Малый
T — тестируемый
Независимый. Это означает, что вы можете запланировать и реализовать каждую пользовательскую историю отдельно.Это очень полезно, если вы внедряете процессы непрерывной интеграции.
Торг. Это означает, что все стороны соглашаются отдать приоритет переговорам над спецификацией. Это также означает, что детали будут постоянно создаваться во время разработки.
Ценный. История должна быть ценной для покупателя. Вы должны спросить себя с точки зрения клиента, «почему» вам нужно реализовать ту или иную функцию.
Приблизительно. Качественный пользовательский рассказ можно оценить.Это поможет составить график команды и расставить приоритеты в реализации. Чем масштабнее история, тем труднее ее оценить.
Малый. Хорошие истории пользователей, как правило, достаточно малы, чтобы их можно было запланировать для коротких производственных выпусков. Небольшие истории позволяют делать более точные оценки.
Тестируемый. Если историю можно проверить, она достаточно ясна и хороша. Проверенные истории означают, что требования выполнены и готовы к использованию.
Функциональная декомпозиция или структурная декомпозиция работ (WBS)
Функциональная декомпозиция или WBS — это визуальный документ, показывающий, как сложные процессы разбиваются на более простые компоненты.WBS — это эффективный подход, позволяющий проводить независимый анализ каждой части. WBS также помогает получить полную картину проекта.
Предлагаем следующую логику функциональной декомпозиции:
Найдите наиболее общую функцию.
Найдите ближайшую подфункцию.
Найдите следующий уровень подфункции.
Проверьте свою диаграмму.
Или процесс разложения может выглядеть так:
Функция высокого уровня -> Подфункция -> Процесс -> Действие
Функции должны быть разложены до такой степени, что части нижнего уровня не могут быть разбиты дальше.
Пример:
Пример функциональной декомпозиции
Программные прототипы
Прототип программного обеспечения — это общий термин для различных форм результатов на ранней стадии, которые создаются для демонстрации того, как должны быть реализованы требования. Прототипы помогают преодолеть пробелы в видении и позволяют заинтересованным сторонам и командам прояснить сложные области разрабатываемых продуктов. Традиционно прототипы представляют, как решение будет работать, и дают примеры того, как пользователи будут взаимодействовать с ним для выполнения своих задач.
Прототипы могут быть дешевыми и быстрыми визуальными представлениями требований ( одноразовые прототипы ) или более сложными ( эволюционных прототипов ). Последние могут даже стать ранними версиями продукта, в которых уже есть некоторые фрагменты окончательного кода. По сути, эволюционные прототипы могут даже превратиться в минимально жизнеспособные продукты или MVP, которые мы описали в отдельной статье.
Конструкторская документация и прототипы
Требования к дизайну обычно собираются и документируются с использованием трех основных форматов, которые трансформируются один в другой:
Каркасы. Каркасы — это графические структуры веб-сайта или приложения с низкой точностью воспроизведения. Они помогают отображать различные страницы продуктов с разделами и интерактивными элементами.
Пример каркаса
Мокапы. Когда каркасы готовы, они превращаются в макеты, визуальные дизайны, передающие внешний вид конечного продукта. Со временем макеты могут стать финальным дизайном продукта.
Конструкторские прототипы. Эти документы содержат визуальные элементы и допускают некоторые взаимодействия с интерфейсом, такие как прокрутка, нажатие на ссылки или заполнение форм.Дизайнерские прототипы можно создавать с нуля, используя HTML и CSS, но большинство UX-команд используют сервисы прототипирования, такие как InVision.
Пример:
Чтобы узнать больше о том, как обрабатываются процессы проектирования UX, ознакомьтесь с нашим примером создания решения для управления поездками для Cornerstone, корпоративного поставщика SaaS, в котором мы использовали все три типа требований к дизайну.
Дизайн интерфейса статуса полета для платформы на 4 площадки
Примеры нефункциональных требований
Как мы уже упоминали, нефункциональные требования описывают, как система должна себя вести, и устанавливают ограничения ее функциональности.Этот тип требований также известен как системные атрибуты качества . Если вам нужна подробная информация о типах нефункциональных требований, а также о том, как подойти к ним и задокументировать их, ознакомьтесь с нашей специальной статьей.
Здесь мы кратко опишем наиболее типичные нефункциональные требования.
Удобство использования
Юзабилити определяет, насколько сложно пользователю будет изучить систему и работать с ней. Юзабилити можно оценить с разных точек зрения:
Эффективность использования: среднее время, необходимое для достижения целей пользователя, сколько задач пользователь может выполнить без какой-либо помощи, количество транзакций, завершенных без ошибок, и т. Д.
Интуитивность: насколько просто понять интерфейс, кнопки, заголовки и т. Д.
Низкая воспринимаемая рабочая нагрузка: количество попыток, необходимое пользователям для выполнения определенной задачи.
Пример: Требования к удобству использования могут учитывать языковые барьеры и задачи локализации: Люди, не понимающие французского, должны иметь возможность использовать продукт . Или вы можете установить требования доступности: Пользователи клавиатуры, которые перемещаются по веб-сайту с помощью , должны иметь возможность нажимать кнопку «Добавить в корзину» на странице продукта за 15 щелчков мышью.
Безопасность
Требования безопасности гарантируют, что программное обеспечение защищено от несанкционированного доступа к системе и хранимым в ней данным. Он учитывает разные уровни авторизации и аутентификации для разных ролей пользователей. Например, конфиденциальность данных — это характеристика безопасности, которая описывает, кто может создавать, просматривать, копировать, изменять или удалять информацию. Безопасность также включает защиту от вирусов и вредоносных программ.
Пример: A Права доступа для конкретной системной информации могут быть изменены только администратором данных системы.
Надежность
Надежность определяет, насколько вероятно, что программное обеспечение будет работать без сбоев в течение заданного периода времени. Надежность снижается из-за ошибок в коде, сбоев оборудования или проблем с другими компонентами системы. Чтобы измерить надежность программного обеспечения, вы можете подсчитать процент правильно выполненных операций или отслеживать средний период времени, в течение которого система работает до отказа.
Пример: Процесс обновления базы данных должен откатить все связанные обновления в случае сбоя любого обновления.
Производительность
Производительность — это атрибут качества, который описывает реакцию системы на различные взаимодействия пользователя с ней. Низкая производительность приводит к негативному восприятию пользователями. Это также ставит под угрозу безопасность системы при ее перегрузке.
Пример: Время загрузки главной страницы должно быть не более 2 секунд для пользователей, которые получают доступ к веб-сайту через мобильное соединение LTE.
Наличие
Доступность определяется периодом времени, в течение которого функции и услуги системы доступны для использования во всех операциях.Таким образом, плановые периоды технического обслуживания напрямую влияют на этот параметр. И важно определить, как минимизировать влияние обслуживания. При написании требований к доступности команда должна определить наиболее важные компоненты системы, которые должны быть доступны в любое время. Также следует подготовить уведомления пользователей на случай, если система или одна из ее частей станут недоступны.
Пример: Развертывание нового модуля не должно влиять на доступность первой страницы, страниц продукта и страниц оформления заказа и не должно занимать более одного часа.Остальные страницы, на которых могут возникнуть проблемы, должны отображать уведомление с таймером, показывающим, когда система снова будет работать.
Масштабируемость
Требования к масштабируемости описывают, как система должна расти без отрицательного влияния на ее производительность. Это означает обслуживание большего числа пользователей, обработку большего количества данных и выполнение большего числа транзакций. Масштабируемость имеет значение как для оборудования, так и для программного обеспечения. Например, вы можете повысить масштабируемость, добавив память, серверы или дисковое пространство.С другой стороны, вы можете сжимать данные, использовать алгоритмы оптимизации и т. Д.
Пример: Лимит посещаемости веб-сайта должен быть достаточно масштабируемым, чтобы поддерживать 200 000 пользователей одновременно.
Лучшие практики документирования требований
Создание документации — неотъемлемая часть любого проекта разработки программного обеспечения. Хорошо задокументированные требования гарантируют, что заинтересованные стороны и разработчики находятся на одной странице, а также помогают определить объем проекта и бюджет.Вот несколько полезных советов о том, как создавать отличную документацию.
Требования должны быть ясными и понятными . Убедитесь, что ваши требования изложены кратко, не содержат двусмысленности и не допускают различных интерпретаций. Также старайтесь избегать технологического жаргона. Помните, что все аудитории разные, и заинтересованные стороны могут быть незнакомы со специализированной технической терминологией. Вместо этого обогатите свои документы визуальными элементами, диаграммами и графиками, чтобы поддержать информацию и облегчить ее восприятие.Также полезно добавлять глоссарии и перекрестные ссылки.
Требования должны быть конкретными, точными и полными. При написании документации следуйте языку и убедитесь, что ваши требования точны. Они должны охватывать все сценарии, но никогда не противоречить друг другу. Избегайте расплывчатости и слабых фраз, таких как «система должна быть быстрой» или «когда что-то происходит». Будьте конкретны и дайте количественную оценку терминам, чтобы все читатели могли понять их одинаково.
Требования должны быть протестированы. Напишите требования таким образом, чтобы после создания продукта тестирование могло показать, успешно ли они доставлены.
Требования должны быть выполнимыми и разумными. Сосредоточьтесь на функциональности и характеристиках качества, которые действительно нужны пользователям. Помните, что требования должны отражать бизнес-цели более высокого уровня.
Сетевая рабочая группа S.Брэднер Запрос комментариев: 2119 Гарвардский университет BCP: 14 марта 1997 г. Категория: Лучшая текущая практика Ключевые слова для использования в RFC для обозначения уровней требований Статус этого меморандума Этот документ определяет лучшие текущие практики Интернета для Интернет-сообщество, и просит обсуждение и предложения по улучшения. Распространение памятки не ограничено. Абстрактный Во многих стандартных путевых документах используются несколько слов для обозначения требования в спецификации.Эти слова часто заглавные. В этом документе эти слова определяются так, как они должны быть интерпретируется в документах IETF. Авторы, которые следуют этим рекомендациям должны включить эту фразу в начале своего документа: Ключевые слова «ДОЛЖНЫ», «НЕ ДОЛЖНЫ», «ОБЯЗАТЕЛЬНО», «ДОЛЖНЫ», «ДОЛЖНЫ» НЕ »,« ДОЛЖЕН »,« НЕ ДОЛЖЕН »,« РЕКОМЕНДУЕТСЯ »,« МОЖЕТ »и «ДОПОЛНИТЕЛЬНО» в этом документе следует толковать, как описано в RFC 2119. Обратите внимание, что сила этих слов изменена требованием уровень документа, в котором они используются.1. ОБЯЗАТЕЛЬНО Это слово или термины «ТРЕБУЕТСЯ» или «ДОЛЖЕН» означать, что определение является абсолютным требованием спецификации. 2. НЕ ДОЛЖНЫ. Эта фраза или фраза «НЕ ДОЛЖНЫ» означать, что определение — это абсолютный запрет на указание. 3. СЛЕДУЕТ это слово или прилагательное «РЕКОМЕНДУЕТСЯ» означать, что там могут существовать веские причины в определенных обстоятельствах игнорировать конкретный пункт, но необходимо понимать все последствия и тщательно взвесить, прежде чем выбрать другой курс.4. НЕ ДОЛЖНЫ эта фраза или фраза «НЕ РЕКОМЕНДУЕТСЯ» означать, что могут существовать уважительные причины в определенных обстоятельствах, когда конкретное поведение приемлемо или даже полезно, но полное следует понимать последствия и тщательно взвешивать случай перед реализацией любого поведения, описанного этим ярлыком. Лучшие современные практики Брэднера [Страница 1] RFC 2119 Ключевые слова RFC Март 1997 г. 5. МОЖЕТ Это слово или прилагательное «НЕОБЯЗАТЕЛЬНО» означать, что предмет является действительно необязательно.Один поставщик может включить товар, потому что конкретная торговая площадка требует этого или потому, что продавец считает, что он улучшает продукт, в то время как другой поставщик может опустить тот же элемент. Реализация, которая не включает конкретную опцию, ДОЛЖНА быть подготовлен к взаимодействию с другой реализацией, которая включить эту опцию, хотя, возможно, и с ограниченной функциональностью. в в том же духе реализация, которая включает в себя конкретную опцию ДОЛЖЕН быть готов к взаимодействию с другой реализацией, которая не включает эту опцию (за исключением, конечно, функции вариант предусматривает.) 6. Рекомендации по использованию этих императивов. Императивы типа, определенного в этом документе, должны использоваться с осторожностью. и экономно. В частности, они ДОЛЖНЫ использоваться только там, где это необходимо. фактически требуется для взаимодействия или для ограничения поведения, которое возможность причинения вреда (например, ограничение повторных передач) Например, их нельзя использовать для навязывания определенного метода на разработчиках, где метод не требуется для совместимость. 7. Соображения безопасности Эти термины часто используются для обозначения поведения с безопасностью. подразумеваемое.Последствия для безопасности невыполнения ОБЯЗАТЕЛЬНО или ДОЛЖЕН или делать то, что в спецификации НЕ ДОЛЖНО или НЕ ДОЛЖНО НЕ делать может быть очень тонким. Авторы документов должны найти время проработать последствия несоблюдения правил безопасности рекомендации или требования, так как у большинства разработчиков не будет извлекли пользу из опыта и обсуждения, которые привели к Технические характеристики. 8. Благодарности Определения этих терминов представляют собой совокупность определений, взятых из ряда RFC.Кроме того, были внесены предложения включены из ряда людей, включая Роберта Ульмана, Томаса Нартен, Нил МакБёрнетт и Роберт Элз. Лучшие современные практики Брэднера [Страница 2] RFC 2119 Ключевые слова RFC Март 1997 г. 9. Адрес автора. Скотт Брэднер Гарвардский университет 1350 Mass. Ave. Кембридж, Массачусетс 02138 телефон — +1617 495 3864 электронная почта — [email protected] Лучшие современные практики Брэднера [Страница 3]
Документ с требованиями бизнеса: обзор высокого уровня
У многих предприятий есть процессы, помогающие в управлении и реализации проектов.Одна из возможностей для улучшения заключается в том, чтобы сделать разумные оценки того, насколько велик проект и сколько он будет стоить.
У инструментов, используемых в этом процессе, есть много разных названий: спецификация бизнес-потребностей, спецификация требований или просто бизнес-требования.
Бизнес-требования — это критически важные действия предприятия, которые должны выполняться для достижения организационных целей, оставаясь при этом независимыми от решений.
Документ бизнес-требований (BRD) подробно описывает бизнес-решение для проекта, включая документацию о потребностях и ожиданиях клиентов.Если инициатива направлена на изменение существующего (или введение нового) аппаратного / программного обеспечения, следует создать новый BRD.
Процесс BRD может быть включен в культуру Шести сигм DMAIC (определение, измерение, анализ, улучшение, контроль).
Наиболее распространенные цели BRD:
Для согласования с заинтересованными сторонами
Обеспечить основу для того, чтобы сообщить поставщику технологических услуг, что решение должно делать для удовлетворения потребностей клиентов и бизнеса.
Чтобы внести вклад в следующую фазу этого проекта
Чтобы описать то, что решение не удовлетворяет потребности клиента / бизнеса.
BRD важен, потому что он является основой для всех последующих результатов проекта, описывая, какие входы и выходы связаны с каждой функцией процесса.Функция процесса предоставляет CTQ (критически важные для качества). CTQ передают голос клиента (VOC). BRD описывает, как система будет выглядеть с точки зрения бизнеса.
BRD проводит различие между бизнес-решением и техническим решением. При изучении бизнес-решения BRD должен ответить на вопрос: «Что хочет сделать бизнес?» Например, предприятие хочет подавать 100 бутылок красного вина каждую ночь во время трехдневной конференции, и при розливе вино должно иметь температуру 57 градусов по Фаренгейту.Техническое решение должно поддерживать бизнес-решение. Например, компании потребуется винный грот или холодильная установка, способная вместить более 300 бутылок с температурой от 48 до 52 градусов по Фаренгейту.
Кто должен участвовать в создании BRD?
Ряд команд и партнеров должны создать BRD:
Основная команда проекта
Деловой партнер (ы)
Владелец или представители процесса
Специалисты в предметной области
Управление изменениями / проектами / продуктами, отделом качества и / или управление ИТ по мере необходимости или при наличии
Предварительные требования для BRD
Предварительным условием для BRD является устав проекта, созданный на этапе определения проекта DMAIC.BRD дает возможность пересмотреть устав проекта, чтобы убедиться, что цель, цели, объем, проектная группа и утверждающие точно отражены.
Второе предварительное условие — это оценка текущей среды, созданная на этапе измерения. Это включает в себя подробную карту процесса текущей среды с выделением областей, которые будут изменены в ходе проекта. Подробные карты процессов «как есть» должны включать:
Четко определенные начальная и конечная точки процесса
Функции процесса второго и третьего уровней
Определенные области переделок и этапов, не связанных с добавленной стоимостью
Время цикла, мощность и информация о доработках для каждого шага процесса, если таковая имеется
Базовый план для каждого CTQ для текущей среды
Третье предварительное условие — это CTQ, определенные на этапах определения или измерения и подтвержденные базовыми измерениями, целями и спецификациями.
Текущие показатели: данные, которые определяют и описывают текущую производительность — сигма-уровень CTQ включает определение того, как характеристики продукта / услуги должны быть определены количественно.
Целевая / номинальная стоимость: Какова цель продукта / услуги? Если бы в продукте / услуге никогда не было никаких изменений, это было бы постоянное значение.
Пределы спецификации: Какие отклонения клиент готов допустить в доставке продукта или услуги? Определите верхний и нижний пределы спецификации в соответствии с требованиями заказчика.
Допустимый уровень брака: как часто производители готовы производить продукт / услугу, выходящие за пределы спецификации?
Четвертое предварительное условие — это оценка целевой среды, созданная на этапе измерения и включающая подробную карту процесса целевой среды, включая функции второго уровня. При различении функций второго или третьего уровня сгруппируйте функции процесса по следующим категориям:
Люди: люди обрабатывают информацию и принимают решения [основная группа разрабатывает дизайн высокого уровня / дизайн низкого уровня (HLD / LLD)]
Системы: Системы обрабатывают информацию и принимают решения
Системы / люди: Система обрабатывает информацию, и люди принимают решения.
Различать сотрудника и клиента
Различать требования к руководству для сотрудника в случае, если полномочия по принятию решений должны быть повышены
Fishbone: для каждой технологической функции для оценки воздействия
Общая информация о проекте и передовой опыт
Приложение BRD может использоваться для перечисления ряда деталей проекта — ограничений, предположений и зависимостей, бизнес-правил, объема, отчетов об измерениях и других тем, важных для проекта.При рассмотрении всего проекта необходимо учитывать следующие вопросы:
Есть ли какие-либо нормативные или географические ограничения (например, законы штата), которые следует учитывать? Если это так, эти ограничения должны быть четко задокументированы в таблице подробностей процесса BRD или в разделе общих сведений о проекте в приложении.
Какие допущения или зависимости применяются?
Какие применяются бизнес-правила?
Существуют ли какие-либо требования к измерениям или отчетности, применимые к проекту?
Лучшие Лрактики
Подтвердить область действия: проанализировать и уточнить область действия по мере необходимости на основе таблицы деталей процесса, идентифицируя любые изменения в том, что входит или выходит за рамки области сейчас, когда требования были разработаны.Завершите это до получения согласия делового партнера (ов) и зафиксируйте объем проекта. Любые изменения в проекте после этого этапа будут обрабатываться через процесс управления изменениями.
Создание документа, затронутого системой: Создайте схему элементов дизайна для каждой функции процесса второго или третьего уровня для оценки воздействия на:
Люди
Процесс
Технологии
Материалы и принадлежности
Удобства
Товар
Машины и оборудование
Другое по мере необходимости (в зависимости от организации)
Определения и сокращения: Определите любые термины, которые не всем понятны.
Упаковка BRD
Упакуйте BRD так, чтобы он имел логическую последовательность и простоту выполнения. Пример высокоуровневого списка разделов:
Обзор проекта, включая информацию об уставе, объеме и целях проекта
Текущая оценка окружающей среды и обзор систем (см. Дополнительную информацию ниже)
Карта будущего процесса
Таблица деталей процесса
Общие бизнес-правила и ограничения проекта
Оценка воздействия («рыбья кость» для технологических функций)
Функциональные требования (дополнительная информация ниже)
Данные, подлежащие хранению (дополнительная информация доступна ниже)
График и бюджет
Термины и определения
Информация о заверителе
Информация о команде
Деловой партнер Выход из системы
Деловые партнеры должны быть активными участниками разработки BRD, но окончательная проверка и согласование также важны.
Дополнительная информация
В BRD включен ряд пунктов, которые требуют подробной документации для обеспечения успешной реализации. Ниже приводится общий обзор типов деталей, которые следует учитывать:
Примеры вопросов для текущей оценки окружающей среды и обзора систем:
Кто предполагаемый пользователь?
Сколько у вас пользователей? Они одного типа пользователей или разные?
Какой уровень опыта работы с компьютером будет у пользователей (или необходим)?
Какая необходимая безопасность?
Есть ли аппаратные ограничения — сетевые или автономные?
Какое приблизительное количество записей требуется на начальном этапе плюс ожидаемый рост?
Какая техническая поддержка необходима и доступна внутри компании?
Какие еще системы необходимо интегрировать / обмениваться данными?
Резервное копирование.Опишите текущий режим резервного копирования (например, однодневное резервное копирование на магнитную ленту). Как с этим согласуется новая система? Если это в настоящее время не определено, подумайте, сколько данных может быть случайно потеряно. Например, будет ли потеря последних 30 минут работы серьезной катастрофой или данные за вчерашнюю / прошлую неделю будут сохранены?
Результаты. Каковы ожидания — система, файлы справки, документация, полный исходный код, обучение, поддержка и т. Д.? Детализируйте то, что важно и что приятно. Не просите автоматически все, если в этом нет необходимости.Если менеджер проекта должен поддерживать систему, убедитесь, что он заявляет, что ему требуется полный исходный код — в качестве альтернативы, если разработчик должен поддерживать систему, рассмотрите возможность заключения соглашения об условном депонировании (где источник находится у независимой третьей стороны). Рассказывайте об инструментах, необходимых для помощи. Если разработчик не желает оказывать необходимую поддержку, найдите кого-нибудь, кто это сделает.
Раздел функциональных требований должен описывать, «что» должна выполнять система, а не «как».”Составьте список приоритетов, подобный следующему:
Подробное описание требования, включая цели (например, создание отчета о затратах / отделе / году по запросу, когда пользователь выбирает отдел и требуемый финансовый год), необходимо знать, как компания определяет финансовый год.
Насколько важно это требование (существенно, желательно, приятно иметь, не обязательно и т. Д.)?
Есть ли какие-либо известные проблемы проектирования / реализации, связанные с этим требованием?
Взаимодействует ли это требование с другими требованиями?
Хранимые данные: образец извещения
Опишите таблицы ожидаемых данных.Примеры включают записи о клиентах, контактные данные, записи о машинах и т. Д. Предоставьте как можно больше подробностей — запись о клиенте может состоять из имени, адреса, номера телефона, факса, номера мобильного телефона, региона, типа бизнеса, количества сотрудников и т. Д. Укажите любые уникальные поля (например, номер вакансии) и показать, как разные таблицы соотносятся друг с другом (очень важно). Например, проекты связаны с клиентами через номер клиента. У каждого клиента не может быть ни одного, одного или нескольких связанных проектов.Каждый проект связан с одной или несколькими вакансиями. Работа может существовать независимо от проекта, но при этом будет связана с заказчиком. У проекта всегда будет только один заказчик.
Обычно нет необходимости определять таблицы в терминах базы данных (например, номер клиента — длинное целое число), но примеры данных, которые должны храниться в полях, полезны (например, типичный номер задания может быть FH / 1234, где FH указывает на отдел, выполняющий задание, а 1234 — это уникальный номер. На практике хороший разработчик базы данных тогда распознает, что «реальный» номер задания на самом деле является частью 1234, а FH — просто ассоциированным полем).Если известен максимальный размер любого поля — например, поле «Название компании» составляет 100 символов — включите это. Если есть какие-либо определения таблиц из существующих систем, укажите в них любые требуемые изменения.
Сводка
Как и любой другой инструмент, BRD может иметь как преимущества, так и режимы отказа. Преимущества, полученные от хорошего BRD, включают меньшее количество изменений на этапах улучшения и контроля DMAIC, а также сокращение времени до развертывания. Режимы отказа из-за плохого BRD означают, что разработанная система не будет соответствовать бизнес-требованиям.Создание успешного BRD требует планирования и координации. Есть несколько передовых методов, которым следует следовать в этом процессе. Команда должна провести специальный выездной сеанс, чтобы завершить BRD со 100-процентной доступностью всех необходимых ресурсов. Планирование — ключ к успеху здесь. По мере того, как каждый инструмент / результат завершается в рамках методологии, создайте BRD. Выделите недельный крайний срок для завершения элементов действий из внеофисного сеанса и проведите заключительную сессию обзора через два-три часа после выполнения элементов действий.
Вам также может понравиться
Документ о бизнес-требованиях: определение и советы
По мере роста бизнеса или изменения направления его требования к документации также изменяются. В этой статье мы исследуем, что такое документ бизнес-требований, чем он отличается от документа функциональных требований (FRD), а также советы по написанию эффективного документа.
Что такое документ с бизнес-требованиями?
Документ бизнес-требований (BRD) — это формальный отчет, в котором подробно описаны все цели или «требования» для нового проекта, программы или бизнес-решения.Он описывает бизнес-потребность или цель, а также то, что ожидается в ходе реализации проекта. После утверждения BRD компания или команда могут приступить к поиску наилучшего подхода к созданию решения. Таким образом, BRD обеспечивает ясность, сохраняет фокус и устраняет двусмысленность в отношении потребностей проекта.
Связано: Как вести команду через изменения
Каковы преимущества BRD?
Хорошо разработанный BRD имеет несколько преимуществ, в том числе то, что он может:
Снижает количество сбоев проекта из-за несогласованных или искаженных требований
Подключается к более широким бизнес-целям и помогает контролировать общее состояние проекта
Создает консенсус и сотрудничество между заинтересованными сторонами и члены команды
Экономия затрат, связанных с запросами на изменения, обучением, инфраструктурой и т. д.
Связанный: Что такое стратегическое планирование? Определение, методы и примеры
Кто создает BRD?
BRD — один из первых документов, созданных в жизненном цикле проекта.Хотя документ обычно готовится бизнес-аналитиком, в его создании должны участвовать несколько человек, в том числе команда проекта, бизнес-партнеры и ключевые заинтересованные стороны. Их основной аудиторией будут спонсоры проектов, высшее руководство, менеджеры среднего звена и аналитики.
Разница между BRD и FRD
Документ бизнес-требований часто путают с документом функциональных требований (FRD), другим термином в администрировании компании.Хотя оба документа работают согласованно для создания и достижения бизнес-целей компании, они очень различаются по своей природе. В то время как BRD обсуждает, что нужно делать бизнесу, FRD описывает, как это делать. Каждый из них имеет свою ценность в бизнес-стратегии, и ни один из них не должен игнорироваться как часть процесса.
Связано: Документы функциональной спецификации: инструкции и советы
Семь шагов для создания BRD
Перед созданием документа бизнес-требований необходимо выполнить предварительные требования и выполнить задачи.Эти шаги включают:
1. Определите потребности компании
Шаг заключается в разработке четкого и подтвержденного определения проблем, стоящих перед бизнесом. Документ должен четко и кратко объяснять проблему или ситуацию, которую компания пытается преодолеть, чтобы все участники понимали и соглашались.
2. Определите цели BRD
Когда вы узнаете проблему, следующим шагом будет четкое определение целей для документа бизнес-требований.Это может дать несколько преимуществ, в том числе:
Обеспечение исходных данных для следующего этапа проекта
Создание основы для определения подходящих решений для нужд и требований бизнеса и клиентов
Достижение консенсуса между участниками
Описание что и как достичь поставленных целей
Также важно установить объем требований для всех этапов проекта.Объем включает то, что требуется и ожидается на каждом этапе проекта.
3. Вовлеките других
Чтобы убедиться, что все необходимые детали включены в документ, вам следует запросить мнение всех вовлеченных сторон. После этого команда сможет увидеть проект с разных точек зрения, что может способствовать более продуктивному мозговому штурму и поиску новых решений.
4. Определите фазы проекта
Если в проекте задействованы разные фазы, каждая фаза должна иметь заявленные требования или входы и ожидаемые результаты или выходы.Например, сколько требуется работы и что она даст? BRD должен продемонстрировать четкие и ожидаемые функции для завершения проекта.
5. Установите стандарты для всех требований
Поскольку в проекте могут быть разные фазы и другие участники, важно установить стандарты для ожидаемых результатов. Стандарты помогут регулировать качество и количество работ, направленных на выполнение бизнес-требований, и обеспечить выполнение проекта в соответствии с графиком.
6. Разработайте планирование и измерение процесса
Перед созданием BRD необходимо установить критические вехи с критическим рабочим графиком, детализирующим путь для завершения каждого из них. Это гарантирует, что проект будет идти по плану с своевременными результатами и успешным завершением. В документ бизнес-требований также должен быть включен надежный метод мониторинга и измерения прогресса.
Связанные: Цели SMART: определение и примеры
7.Используйте соответствующий шаблон
После того, как вся необходимая информация будет собрана, используйте соответствующий шаблон для представления требований. Шаблон упрощает создание документа и обеспечивает четкое представление информации в привлекательном и понятном формате.
10 элементов BRD
Десять важнейших элементов составляют эффективную BRD, в том числе:
1. Краткое содержание
Краткое резюме описывает требования проекта.Обычно он пишется после завершения BRD, чтобы можно было включить все основные моменты.
2. Цель
Использование формата SMART — эффективный метод для создания конкретной, измеримой, достижимой, реалистичной и зависящей от времени цели. Это позволяет легко заключить всеобъемлющее соглашение, сохраняя при этом целенаправленность и выполнение проекта. Часто упускаемый из виду компонент — это процесс измерения, который определяет и позволяет вносить изменения, если и когда это необходимо.
3. Заявление о потребностях
Заявление о потребностях или «справочная информация» объясняет, почему проект необходим и как завершение проекта будет соответствовать требованиям.
4. Объем проекта
Объем проекта очерчивает границы проекта и является одним из наиболее важных компонентов. Объем отвечает на три важных вопроса:
Какие проблемы решает проект?
Каковы границы реализации проекта?
Какова ожидаемая рентабельность инвестиций от завершения проекта?
5.Финансовая отчетность
Финансовая отчетность важна для общего представления о влиянии проекта на баланс и ожидаемые доходы компании. Этот раздел также должен включать подробную информацию о том, как будет финансироваться проект.
6. Функциональные требования
В разделе функциональных требований подробно описано, кто отвечает за что, как, когда и где будет завершен проект и что необходимо для этого. Это должно включать временные рамки, диаграммы и диаграммы, чтобы помочь в планировании и регистрации прогресса.
7. Требования к персоналу
Требования к персоналу иллюстрируют ожидаемые человеческие ресурсы, необходимые для проекта, в том числе, кто и когда должен быть нанят. В этом разделе также будет указана стоимость этих ресурсов.
8. График, сроки и крайние сроки
Создайте тщательно спланированный и подробный график, который включает крайние сроки, контрольные точки и систему мониторинга. Это поможет вам держать ключевые заинтересованные стороны в курсе проекта на конкретных этапах.Можно вносить корректировки для добавления или вычитания ресурсов, чтобы поддерживать определенные компоненты проекта, такие как затраты и ресурсы, в рабочем состоянии.
9. Анализ затрат и выгод
Анализ затрат и выгод подробно описывает все сопутствующие затраты, связанные с проектом, вместе с ожидаемыми выгодами.
10. Ожидания и предположения
В зависимости от продолжительности проекта предположения потребуются. Включите ожидания и предположения, которые могут повлиять на результат проекта, поскольку они могут иметь драматические последствия.Часто учитываемые ожидания включают изменение делового климата, предпочтений клиентов, процентных ставок или обстоятельств, которые не поддаются контролю. Четко формулируйте предположения, чтобы избежать проблем в дальнейшем.
Подробнее: План непрерывного улучшения рабочего места: определение, методы и примеры
Советы по написанию документа бизнес-требований
Следуйте этим советам для написания эффективного документа бизнес-требований:
Используйте слова, которые Побуждать к действию: Есть несколько способов побудить к действию с помощью слов, включая использование простого и несложного жаргона, который легко понять.
Вовлекайте других: Поощряйте других участвовать в таких мероприятиях, как мозговой штурм, фокус-группы, интервью, опросы и идеи для создания прототипов.
Проведите небольшое исследование: Изучите прошлые проекты, чтобы определить осуществимость вашего BRD. Оцените свой проект, чтобы определить, выдерживает ли он тщательную проверку.
Включите визуальные элементы: Включите визуальные элементы, такие как диаграммы и диаграммы, когда это необходимо, так как они могут помочь в изложении вашей мысли.
Проверьте содержимое: После написания документа бизнес-требований проверьте его перед распространением. Получите подтверждение информации и содержания, включая предположения, и убедитесь, что все ошибки или упущения исправлены.
Связано: что такое проектная документация? (С советами)
Советы по написанию документов бизнес-требований
Основой успешного проекта является хорошо составленный документ бизнес-требований (BRD).BRD описывает проблемы, которые пытается решить проект, и требуемые результаты, необходимые для создания ценности.
Когда все сделано правильно, документ с бизнес-требованиями направляет проект и держит всех на одной странице. Однако документация требований может легко стать неясной и дезорганизованной, что может быстро сбить проект с пути.
Чтобы избежать сползания проекта и гарантировать, что ваша команда предоставляет правильную ценность, следуйте этим советам для написания идеального документа с бизнес-требованиями.
Что такое документ с бизнес-требованиями?
Документ бизнес-требований описывает бизнес-решение для проекта (т. Е. То, что должен делать новый или обновленный продукт), включая потребности и ожидания пользователя, цель этого решения и любые ограничения высокого уровня, которые могут повлиять на успешный результат. развертывание.
По сути, BRD выступает в качестве руководства для заинтересованных сторон при принятии решений относительно приоритетов, дизайна и структуры проекта, чтобы гарантировать соответствие проекта общим целям бизнеса.
Он также представляет собой базовый контракт между заказчиком и поставщиком, в котором излагаются ожидания и результаты проекта. BRD устанавливает стандарты для определения того, когда проект достиг успешного завершения.
Бизнес-требования и функциональные требования
Хотя эти термины часто используются как синонимы, бизнес-требования не совпадают с функциональными требованиями для проекта. Бизнес-требования описывают, какие результаты необходимы, но не как их достичь.
Эта информация («как») должна быть задокументирована в функциональных требованиях проекта. Обычно они изложены в документации по требованиям к программному обеспечению для проектов разработки, но некоторые организации включают в свои BRD раздел функциональных требований. Эти функциональные требования подробно описывают, как система должна работать для выполнения бизнес-требований.
Бизнес-требования — это средство достижения целей организации. Они должны быть высокоуровневыми, детализированными и написанными с точки зрения клиента.
Напротив, функциональные требования гораздо более конкретны, узко сфокусированы и написаны с точки зрения системы. Функциональные требования — это средство предоставления эффективного решения, отвечающего бизнес-требованиям и ожиданиям клиента в отношении этого проекта.
Несмотря на то, что различие тонкое, важно знать разницу между бизнес-требованиями и функциональными требованиями, чтобы обеспечить эффективное выявление, документирование и реализацию требований.Понимание разницы также поможет вам правильно сфокусировать и согласовать проект, чтобы ваша команда могла удовлетворить как потребности пользователей, так и бизнес-цели в конце проекта.
Анатомия великого BRD
Большинство предприятий следуют шаблону для всей документации по проектным требованиям. Это полезно для соблюдения стандартов документации во всей организации.
Структура может различаться, но базовая BRD будет включать следующие разделы и компоненты:
Обзор проекта (включая видение, цели и контекст)
Факторы успеха
Объем проекта
Идентификация заинтересованных сторон
Бизнес-требования
Объем решения
Ограничения проекта (например, график и бюджет)
Меры контроля качества
Некоторым командам может потребоваться включить дополнительные разделы в зависимости от потребностей и сложности проекта, таких как текущая оценка, будущий процесс карта и потребности в обучении.
Кроме того, в зависимости от процесса документирования организации, разделы функциональных и нефункциональных требований также могут быть включены в BRD, а не в отдельные документы с требованиями.
5 лучших советов по написанию идеального BRD
Теперь, когда вы понимаете, что должен выполнять документ с бизнес-требованиями, вы можете следовать этим рекомендациям, чтобы убедиться, что вы напишете исключительный документ.
1. Практикуйте эффективное выявление требований
Даже если вы напишете впечатляющий BRD, он не будет эффективным, если вы не определили и не задокументировали все необходимые требования.Чтобы ваш BRD был полным и целостным, вам необходимо применить соответствующие методы извлечения информации.
В Руководстве по своду знаний по бизнес-анализу (более известному как Руководство BABOK) перечислены девять основных методов выявления:
Мозговой штурм
Анализ документов
Анализ интерфейса
Фокус-группы
Создание прототипов
Семинары по требованиям
Интервью
Наблюдение
Опросы
Вы можете использовать все девять или несколько избранных, но вам, безусловно, потребуется использовать несколько подходов, чтобы собрать исчерпывающий набор требований.
Какие бы методы вы ни использовали, примите во внимание следующие советы для улучшения процесса сбора информации.
Постоянный сбор требований
Хотя сбор большинства требований происходит на ранней стадии жизненного цикла проекта, бизнес-аналитик всегда должен быть открыт для выявления и документирования новых требований по мере необходимости. Может возникнуть соблазн скрыть новую информацию, если вы уже прошли начальные этапы проекта. Однако конечный продукт будет лучше, если вы конкретизируете все необходимые требования, даже если они будут добавлены позже в игре.
Познакомьтесь со своими заинтересованными сторонами
Установите взаимопонимание со своими заинтересованными сторонами и узнайте, как они работают. Адаптируйте свои методы обнаружения к их стилю или предпочтительному методу. Хотя одни люди лучше всего работают на собеседовании, другие могут предпочесть подготовить письменные ответы. Приспосабливая свои методы к конкретному человеку, вы сможете более эффективно и действенно собирать требования.
Всегда будьте готовы
Приходите на встречи с заинтересованными сторонами подготовленными с вопросами и даже ответами.Правильных вопросов часто бывает достаточно, чтобы сдвинуть дело с мертвой точки, но если команда пытается найти ответ, предложите его самостоятельно. Предложение вариантов может побудить группу к мозговому штурму и более стратегическому обдумыванию проблемы.
2. Используйте понятный язык без жаргона
Документы с требованиями часто бывают длинными и насыщенными текстом. Чтобы избежать путаницы или неправильного толкования, используйте ясный язык без жаргона. Имейте в виду, что этот документ будут использовать несколько заинтересованных сторон, и не все из них будут технически подкованными.Соблюдая ясный язык, вы можете быть уверены, что все его поймут.
Если вам действительно нужно включить жаргон или другие технические термины, обязательно добавьте их в раздел словаря проекта в документе. Этот раздел может служить полезным справочником по всем необычным терминам, встречающимся в документе, поэтому никто не может неправильно понять требования.
3. Изучите прошлые проекты
Отличный способ ускорить процесс документирования — изучить аналогичные проекты, которые ваша организация выполняла в прошлом.
Изучите документацию по этим проектам и используйте эти идеи, чтобы помочь вам определить требования и другие ключевые моменты, которые следует включить в вашу собственную BRD. Эти проекты также могут помочь вашей команде обосновать определенные требования на основе успешных прошлых результатов.
4. Подтвердите документацию
После того, как вы закончите писать документ с требованиями, попросите эксперта в предметной области и заинтересованных сторон проекта изучить его. Это время для всех, чтобы проверить информацию и предложить отзывы или исправления.
Этот шаг имеет решающее значение для создания успешного BRD. Без него вы рискуете пропустить ключевые требования или оставить критические ошибки, которые могут сбить ваш проект с пути.
5. Включите визуальные элементы
Хотя BRD обычно содержат много текста, визуальные элементы играют важную роль в представлении и уточнении информации, а также в создании более удобного документа. Разбивайте стены текста с помощью визуализаций данных, таких как потоки процессов и модели областей видимости.
Что такое документ с требованиями к продукту (PRD)?
Что такое документ с требованиями к продукту?
Документ требований к продукту (PRD) — это артефакт, используемый в процессе разработки продукта, чтобы сообщить, какие возможности должны быть включены в выпуск продукта, группам разработки и тестирования.Этот документ обычно больше используется в каскадных средах, где определение продукта, его проектирование и доставка выполняются последовательно, но его также можно использовать в гибкой среде.
PRD будет содержать все, что должно быть включено в выпуск, чтобы его можно было считать завершенным, и служить руководством для последующих документов в процессе выпуска. Хотя PRD могут намекать на потенциальную реализацию, чтобы проиллюстрировать вариант использования, они могут не диктовать конкретную реализацию.
См. Также: Документ о рыночных требованиях (MRD)
В чем разница между PRD и MRD?
На протяжении десятилетий документ с требованиями к продукту (PRD) был самым важным артефактом, который создавали менеджеры по продукту.В нем тщательно перечислено все, что требуется для данного выпуска продукта, и он служит документом записи, на котором основан весь выпуск. Короче говоря, если он не включен в PRD, он не будет включен в выпуск.
PRD может следовать по пятам за документом с маркетинговыми требованиями (MRD), который также создается маркетингом продукта, маркетингом или менеджментом продукта, который описывает потребительский спрос, рыночные возможности и бизнес-обоснование для продукта в целом или конкретного продукта. выпуск продукта.
PRD сам по себе не затрагивает рыночных возможностей или доходов, но вместо этого прочно опирается на варианты использования и желаемую функциональность. Каждая функция или возможность обычно описывается как отдельный элемент, и для каждого элемента также обычно указывается вариант использования.
На основе PRD ряд других артефактов будет создан другими сотрудниками организации. Разработчики создадут функциональную спецификацию, которая описывает, как каждый элемент PRD будет реализован, и они также могут создать (или обновить) документ архитектурного проектирования.UX создаст каркасы и макеты по мере необходимости, а служба контроля качества напишет план тестирования, гарантирующий, что каждый отдельный вариант использования в PRD может быть успешно выполнен во время тестирования.
Что должен содержать документ с требованиями к продукту?
PRD должен включать все явные возможности, необходимые для выпуска. Для поддержки каждой желаемой возможности должен быть сопроводительный вариант использования, иллюстрирующий, как пользователь будет использовать эту функцию, и для информирования плана тестирования.
Если функция является сложной, можно использовать подпункты, чтобы предоставить более подробную информацию и детализацию для технических групп. Каждый из этих подпунктов должен включать собственный вариант использования, когда это необходимо.
В дополнение к конкретным функциям и возможностям PRD должен включать обзор / цель выпуска. Хотя это не должно пытаться воспроизвести то, что находится в MRD, оно должно точно указывать на то, чего команда продукта пытается достичь с помощью этого конкретного выпуска (поскольку MRD может использоваться для нескольких выпусков одного и того же продукта / набора продуктов).
Помимо функциональных требований, в PRD также должны быть прописаны любые другие требования. К ним относятся любые системные или экологические требования (т.е. этот продукт должен работать в Windows 10 или более поздней версии или он должен работать в браузерах Firefox, Chrome и Safari), а также любые требования к удобству использования (например, навигация одной рукой для мобильных приложений).
Последняя партия ингредиентов для PRD — это предположения, ограничения и зависимости.
Предположения — это все, что вы ожидаете (но не гарантируется), например, предположение, что все пользователи будут подключены к Интернету.
Ограничения диктуют то, чего не может потребовать окончательная реализация, будь то бюджетные или технические ограничения.
Зависимости — это любое известное состояние или элемент, на который будет опираться продукт, например, зависимость от Google Maps для добавления маршрутов для приложения для выгула собак.
Какой пример документа с требованиями к продукту?
Ниже приводится основная схема того, что должно быть включено в PRD. Для этого нет жестких правил, но обычно присутствуют следующие элементы:
Задача / цель: Объясните, зачем вы это строите и чего надеетесь достичь.
Функции: Для каждой функции вы должны включать как минимум описание, цель и вариант использования. Дополнительные сведения могут быть полезны или необходимы в зависимости от сложности функции, например, элементы, выходящие за рамки.
Примечания к потоку и проектированию UX: Большинство организаций завершают проектирование функций UX после того, как PRD был рассмотрен и принят. Однако на этом этапе могут потребоваться некоторые общие рекомендации, чтобы гарантировать достижение целей выпуска.Это не место для макетов с идеальной точностью до пикселя или каркасов, которые отображают все возможные сценарии; вместо этого его можно использовать для описания рабочего процесса пользователя в целом.
Требования к системе и среде: Какие среды конечного пользователя будут поддерживаться (например, браузеры, операционные системы, память, вычислительная мощность и т. Д.).
Допущения, ограничения и зависимости: Перечислите, что ожидается от пользователей, любые ограничения для реализации, о которых следует знать, и любые внешние элементы, необходимые для работоспособности окончательного решения.
Каковы этапы создания PRD?
Предполагая, что MRD уже существует, менеджменту продукта следует сначала проконсультироваться с отделом маркетинга продукта, чтобы обеспечить полное понимание бизнес-драйверов для конкретной версии, описанной в PRD. Оттуда, какие методы приоритизации продуктов уже используются, следует использовать, чтобы определить, что входит в объем выпуска.
Пришло время создать документ, используя примечания и отзывы пользователей, записанные для каждой функции, включенной в выпуск.Документ должен пройти несколько раундов проверки с другими членами группы разработки продукта, если это возможно, чтобы убедиться, что даны ответы на как можно больше потенциальных вопросов и что документ является максимально подробным.
После полностью заполненного PRD его следует затем разослать заинтересованным сторонам бизнеса, чтобы подтвердить, что они соответствуют цели выпуска и включенным функциям для достижения этой цели. Когда консенсус достигнут, пора передать PRD инженерам.
На этом этапе у технической группы появятся вопросы, пояснения и проблемы, которые следует решать устно и при необходимости обновлять в PRD.Цель состоит в том, чтобы PRD был достаточно полным и всесторонним, чтобы в дальнейшем не было сюрпризов.

Наименование раздела	Характер содержания раздела
Документация	Документы, составляющие комплект конструкторских документов специфицируемого изделия (кроме его спецификации). Например: сборочный чертеж, схема, пояснительная записка, паспорт, технические условия и т. п.
Комплексы	Комплексы, непосредственно входящие в специфицируемое изделие
Сборочные единицы	Сборочные единицы (их спецификации), входящие в специфицируемое изделие и на которые выполнены чертежи, например, соединения, выполненные запрессовкой, сваркой, пайкой, армированные и другие виды соединений
Детали	Детали, входящие непосредственно в специфицируемое изделие, и на которые выполнены чертежи
Стандартные изделия	Изделия, примененные по следующим категориям стандартов: государственным, отраслевым, республиканским, и стандартам предприятий
Прочие изделия	Изделия, примененные не по стандартам, а по техническим условиям, каталогам, прейскурантам. Примеры: лимб, нониус по нормали станкостроения
Материалы	Материалы, применяемые при сборке. Примеры: проволока, ткань, сталь угловая, набивка – шнур и т. п.
Комплекты	Комплекты, непосредственно входящие в специфицируемое изделие, например комплект монтажных частей, комплект инструмента и принадлежностей и т. п.

Стандартные изделия	Пример условного обозначения
Болт:	Болт М10х60 ГОСТ 7798-70
Шпилька:	Шпилька М16х120 ГОСТ 2034-80
Шайба плоская:	Шайба 12. 01 ГОСТ 11371-78
Шайба граверная:	Шайба 20, 65Г ГОСТ 6402-70
Гайка:	Гайка М12 ГОСТ 5915-81
Шплинт:	Шплинт 5х28,2 ГОСТ 397-79
Винт:	Винт М12х50 ГОСТ 17475-80
Штифт:	Штифт 12h8х60 ГОСТ 23360-78
Шпонка:	Шпонка 18х11х100 ГОСТ 23360-78
Подшипник:	Подшипник 110 ГОСТ 8138-75

Государственная итоговая аттестация (ГИА-IX)	Государственная итоговая аттестация по образовательным программам основного общего образования
ОГЭ	Основной государственный экзамен
ГВЭ	Государственный выпускной экзамен
ОВЗ	Выпускники с ограниченными возможностями здоровья
ОО	Общеобразовательные организация
ППЭ	Пункт проведения экзамена
АИС «ГИА»	Автоматизированная информационная система «Государственная (итоговая) аттестация выпускников 9 классов»
МОУО	Муниципальный орган управления образованием
Бланки	Стандартные бумажные листы определенного формата, специально разработанные ФЦТ для оформления участниками ОГЭ на экзаменационные задания
Контрольные измерительные материалы (КИМ)	Различные типы заданий на проверку умений и навыков (задания с выбором ответа, задания с кратким ответом, задания с развернутым ответом)
Демоверсия (демонстрационный вариант)	Демоверсия является полным аналогом типовых КИМ, которые будут использоваться на государственной итоговой аттестации по образовательным программам основного общего образования в текущем году
Кодификатор	Один из документов, регламентирующих разработку КИМ. Он представляет собой перечень элементов обязательного минимума содержания среднего (полного) и основного общего образования по учебному предмету, в котором каждому элементу содержания присвоен собственный код. Кодификатор составлен на основе Федерального компонента государственных стандартов основного общего и среднего (полного) общего образования (2004 года) с учетом базового и профильного уровней обучения по каждому предмету
Спецификация	Документ, определяющий структуру и содержание КИМ по учебному предмету. Спецификация описывает назначение экзаменационной работы, устанавливает распределение заданий по содержанию, видам деятельности и уровню сложности, раскрывает систему оценивания отдельных заданий и работы в целом, обозначает условия проведения и проверки результатов экзамена. На основе плана экзаменационной работы, содержащегося в спецификации, формируются КИМ
Шкалирование	Процесс формирования тестовых шкал по правилам начисление тестовых баллов на основе первичных баллов с использованием специальной методики и полных статистических данных о результатах тестирования
Апелляция	Процедура, призванная защитить интересы участника ГИА-IX, в случае выявления нарушений в процедуре проведения экзамена или несогласия с результатом оценивания экзаменационной работы в рамках ГИА-IX
Государственная экзаменационная комиссия (ГЭК-IX)	Создается в целях организации подготовки и проведения ГИА-IX и обеспечения соблюдения прав обучающихся при проведении ГИА-IX
Предметная комиссия (ПК)	Специалисты-преподаватели по определенному предмету, которые привлекаются для проверки экзаменационных работ, пройдя предварительно обучающие курсы
Конфликтная комиссия (КК)	Создается в целях обеспечения соблюдения единых требований и разрешения спорных вопросов при оценке экзаменационных работ в рамках проведения ГИА-IX, а также защиты прав обучающихся, участвующих в ГИА-IX
Общественные наблюдатели	Лица, привлекаемые для усиления контроля за ходом проведения ГИА-IX
Минпросвещения России	Министерство просвещения Российской Федерации
Рособрнадзор	Федеральная служба по надзору в сфере образования и науки
ФЦТ	Федеральный центр тестирования
ФИПИ	Федеральный институт педагогических измерений
ОКУ ИАЦ КО	Областное казнное учреждение «Информационно-аналитический центр» Курской области
РЦОИ	Региональный центр обработки информации
Федеральная информационная система (ФИС)	Федеральная информационная система обеспечения проведения государственной итоговой аттестации обучающихся, освоивших основные образовательные программы основного общего и среднего общего образования, и приема граждан в образовательные организации для получения среднего профессионального и высшего образования
Региональная информационная система (РИС)	Региональная информационная система обеспечения проведения государственной итоговой аттестации обучающихся, освоивших основные образовательные программы основного общего и среднего общего образования

Вид документа	Определение
Чертеж детали	Документ, содержащий изображение детали и другие данные, необходимые для ее изготовления и контроля
Сборочный чертеж	Документ, содержащий изображение сборочной единицы и другие данные, необходимые для ее сборки (изготовления) и контроля. К сборочным чертежам также относят чертежи, по которым выполняют гидромонтаж и пневмомонтаж
Чертеж общего вида	Документ, определяющий конструкцию изделия, взаимодействие его составных частей и поясняющий принцип работы изделия
Теоретический чертеж	Документ, определяющий геометрическую форму (обводы) изделия и координаты расположения составных частей
Габаритный чертеж	Документ, содержащий контурное (упрощенное) изображение изделия с габаритными, установочными и присоединительными размерами
Электромонтажный чертеж	Документ, содержащий данные, необходимые для выполнения электрического монтажа изделия
Монтажный чертеж	Документ, содержащий контурное (упрощенное) изображение изделия, а также данные, необходимые для его установки (монтажа) на месте применения. К монтажным чертежам также относят чертежи фундаментов, специально разрабатываемых для установки изделия
Упаковочный чертеж	Документ, содержащий данные, необходимые для выполнения упаковывания изделия
Схема	Документ, на котором показаны в виде условных изображений или обозначений составные части изделия и связи между ними
Спецификация	Документ, определяющий состав сборочной единицы, комплекса или комплекта
Ведомость спецификаций	Документ, содержащий перечень всех спецификаций составных частей изделия с указанием их количества и входимости
Ведомость ссылочных документов	Документ, содержащий перечень документов, на которые имеются ссылки в конструкторских документах изделия
Ведомость покупных изделий	Документ, содержащий перечень покупных изделий, примененных в разрабатываемом изделии
Ведомость разрешения применения покупных изделий	Документ, содержащий перечень покупных изделий, разрешенных к применению в соответствии с ГОСТ 2. 124
Ведомость держателей подлинников	Документ, содержащий перечень предприятий (организаций), на которых хранят подлинники документов, разработанных и (или) примененных для данного изделия
Ведомость технического предложения	Документ, содержащий перечень документов, вошедших в техническое предложение
Ведомость эскизного проекта	Документ, содержащий перечень документов, вошедших в эскизный проект
Ведомость технического проекта	Документ, содержащий перечень документов, вошедших в технический проект
Пояснительная записка	Документ, содержащий описание устройства и принципа действия разрабатываемого изделия, а также обоснование принятых при его разработке технических и технико-экономических решений
Технические условия	Документ, содержащий требования (совокупность всех показателей, норм, правил и положений) к изделию, его изготовлению, контролю, приемке и поставке, которые нецелесообразно указывать в других конструкторских документах
Программа и методика испытаний	Документ, содержащий технические данные, подлежащие проверке при испытании изделий, а также порядок и методы их контроля
Таблица	Документ, содержащий в зависимости от его назначения соответствующие данные, сведенные в таблицу
Расчет	Документ, содержащий расчеты параметров и величин, например, расчет размерных цепей, расчет на прочность и др.
Эксплуатационные документы	Документы, предназначенные для использования при эксплуатации, обслуживании и ремонте изделия в процессе эксплуатации
Ремонтные документы	Документы, содержащие данные для проведения ремонтных работ на специализированных предприятиях
Инструкция	Документ, содержащий указания и правила, используемые при изготовлении изделия (сборке, регулировке, контроле, приемке и т.п.)
перед видом документа «Чертеж детали»:

Электронная модель детали	Документ, содержащий электронную геометрическую модель детали и требования к ее изготовлению и контролю (включая предельные отклонения размеров, шероховатости поверхностей и др. )
после вида документа «Чертеж детали»:
Электронная модель сборочной единицы	Документ, содержащий электронную геометрическую модель сборочной единицы, соответствующие электронные геометрические модели составных частей, свойства, характеристики и другие данные, необходимые для сборки (изготовления) и контроля. К электронным моделям сборочных единиц также относят электронные модели для выполнения гидромонтажа и пневмомонтажа
после вида документа «Схема»:
Электронная структура изделия	Документ, содержащий в электронной форме состав сборочной единицы, комплекса или комплекта и иерархические отношения (связи) между его составными частями и другие данные в зависимости от его назначения
после вида документа «Пояснительная записка»:
Ведомость электронных документов	Документ, содержащий перечень документов, выполненных в электронной форме

Наименование документа	Определение
Наименование документа	Документы в бумажной форме	Документы в электронной форме
1. Оригиналы	Документы, выполненные на любом материале, предназначенные для изготовления по ним подлинников и заверенные разработчиком	Электронные документы, предназначенные для изготовления подлинников и подписанные электронной цифровой подписью (ЭЦП) разработчика
2. Подлинники	Документы, оформленные подлинными установленными подписями и выполненные на любом материале, позволяющем многократное воспроизведение с них копий. Допускается в качестве подлинника использовать оригинал, репрографическую копию или экземпляр документа, изданного типографским способом, завизированные подлинными подписями лиц, разработавших данный документ и ответственных за нормоконтроль	Электронные документы, оформленные установленными ЭЦП и предназначенные для получения с них копий
3. Дубликаты	Копии подлинников, обеспечивающие идентичность воспроизведения подлинника, выполненные на любом материале, позволяющем снятие с них копий	Электронные документы, полученные посредством электронного копирования подлинника, подписанные установленными ЭЦП лиц, ответственных за их изготовление, и предназначенные для изготовления с них копий
4. Копии	Документы, выполненные способом, обеспечивающим их идентичность с подлинником (дубликатом), и предназначенные для непосредственного использования при разработке, в производстве, эксплуатации, ремонте изделий. Копиями являются также микрофильмы-копии, полученные с микрофильма-дубликата	Электронные документы, выполненные способом, обеспечивающим идентичность их с подлинниками (дубликатами), подписанные установленными ЭЦП лиц, ответственных за их изготовление

Код документа	Наименование документа	Техническое предложение	Эскизный проект	Технический проект	Рабочая документация на				Дополнительные указания
Код документа	Наименование документа	Техническое предложение	Эскизный проект	Технический проект	детали	сборочные единицы	комплексы	комплекты	Дополнительные указания
—	1. Электронная модель детали	—	—	○¹	●¹	—	—	—	Требования по ГОСТ 2.052
—	2. Чертеж детали	—	—	○¹	●¹	—	—	—	Допускается не выпускать чертеж (модель) в случаях, оговоренных в ГОСТ 2.109
ЭСБ	3. Электронная модель сборочной единицы	○⁴	○⁴	○⁴	—	○⁴	○⁴	○⁴	Требования по ГОСТ 2.052
СБ	4. Сборочный чертеж	—	—	—	—	●²	—	—	—
ВО	5. Чертеж общего вида	○⁴	○⁴	●⁴	—	—	—	—	—
ТЧ	6. Теоретический чертеж	—	○⁴	○⁴	○	○⁴	○⁴	—	—
ГЧ	7. Габаритный чертеж	○	○	○^{2; 4}	○⁴	○^{2; 4}	○	—	—
МЭ	8. Электромонтажный чертеж	—	—	—	—	○	—	—	—
МЧ	9. Монтажный чертеж	—	—	—	—	○²	○	○	—
УЧ	10. Упаковочный чертеж	—	—	—	○⁴	○	○	○	—
По ГОСТ 2.701	11. Схемы	○	○	○	—	○	○	○	Номенклатура различных видов схем установлена ГОСТ 2.701
—	12. Электронная структура изделия	○	○	○	—	●	●	●	Требования по ГОСТ 2.053
—	13. Спецификация	—	—	—	—	●	●	●	Спецификацию комплектов монтажных, сменных и запасных частей, инструмента, принадлежностей и материалов, укладок, тары допускается не составлять, если изделия и материалы, входящие в комплект, целесообразно записывать непосредственно в спецификацию изделия, для которого они предназначаются
ВС	14. Ведомость спецификаций	—	—	—	—	○	○	○	Ведомость спецификаций рекомендуется составлять на комплексы и сборочные единицы, имеющие две и более ступени входимости составных частей и предназначенные для самостоятельной поставки. При передаче конструкторской документации предприятию-изготовителю составление ведомости спецификаций на эти изделия обязательно
ВД	15. Ведомость ссылочных документов	—	—	—	—	○	○	○	Ведомость ссылочных документов составляют при передаче конструкторской документации организации-изготовителю, ее допускается выпускать к моменту передачи документации. При передаче документации на комплекс допускается составлять только одну (общую) ведомость на всю передаваемую документацию комплекса
ВП	16. Ведомость покупных изделий	—	○	○	—	○	○	○	Ведомость покупных изделий рекомендуется составлять на изделия, предназначенные для самостоятельной поставки
ВИ	17. Ведомость разрешения применения покупных изделий	—	○	○	—	○	○	○	Ведомость разрешения применения покупных изделий рекомендуется составлять на изделия, предназначенные для самостоятельной поставки
ДП	18. Ведомость держателей подлинников	—	—	—	—	○	○	○	—
ПТ	19. Ведомость технического предложения	●	—	—	—	—	—	—	Ведомость технического предложения, ведомость эскизного проекта, ведомость технического проекта и пояснительную записку для сборочных единиц и комплексов не составляют, если они входят в состав более сложного изделия например, в комплекс), на которое составлены эти документы, содержащие все необходимые сведения по входящим в них сборочным единицам и комплектам
ЭП	20. Ведомость эскизного проекта	—	●	—	—	—	—	—
ТП	21. Ведомость технического проекта	—	—	●	—	—	—	—
ПЗ	22. Пояснительная записка	●³	●³	●³	—	—	—	—
ВДЭ	23. Ведомость электронных документов	—	○	○	—	○	○	○	Ведомость электронных документов рекомендуется составлять на комплексы и сборочные единицы, имеющих в своем составе более трех документов, выполненных в электронной форме. При передаче конструкторской документации организации-изготовителю составление ведомости на эти изделия обязательно
ТУ	24. Технические условия	—	—	○	○	○	○	○	Технические условия на изделия, предназначенные для самостоятельной поставки (реализации) потребителю. По согласованию потребителя (заказчика) и поставщика (разработчика) конструкторской документации технические условия могут быть составлены на отдельные составные части изделия. Технические условия на изделия народнохозяйственного назначения единичного производства разового изготовления допускается не составлять. Разработку, изготовление, приемку и поставку таких изделий допускается осуществлять по техническому заданию, разработанному в соответствии с ГОСТ 15.001*
ПМ	25. Программа и методика испытаний	—	○	○	○	○	○	—	—
ТБ	26. Таблицы	○	○	○	○	○	○	○	Номенклатура необходимых таблиц, расчетов, инструкций и прочих документов устанавливается разработчиком в зависимости от характера и условий производства изделий
РР	27. Расчеты	○³	○³	○³	○	○	○	○
И…	28. Инструкция	—	—	—	○	○	○	○
Д…	29. Документы прочие	○	○	○	○	○	○	○
По ГОСТ 2.601	30. Документы эксплуатационные	—	—	—	○	○	○	○	Номенклатура, формы выполнения и обязательность выполнения эксплуатационных документов установлена ГОСТ 2.601
По ГОСТ 2.602	31. Документы ремонтные	—	—	—	○	○	○	○	Номенклатура, формы выполнения и обязательность выполнения ремонтных документов установлена ГОСТ 2.602

Вид документа	Дополнительный код документа
Электронная структура изделия	ЭС
Все чертежи в виде электронной модели изделия (детали, сборочные единицы)	ЗБ
Все чертежи и схемы в электронной форме	2Б
Все текстовые документы в электронной форме	ТЭ