Гост функциональная схема: ГОСТ 2.702-2011 Единая система конструкторской документации (ЕСКД). Правила выполнения электрических схем, ГОСТ от 03 августа 2011 года №2.702-2011

ГОСТ 2.703-2011 Единая система конструкторской документации (ЕСКД). Правила выполнения кинематических схем, ГОСТ от 03 августа 2011 года №2.703-2011

ГОСТ 2.703-2011

Группа Т52

МКС 01.100.20
ОКСТУ 0002

Дата введения 2012-01-01

Предисловие

Цели, основные принципы и основной порядок проведения работ по межгосударственной стандартизации установлены в ГОСТ 1.0-2015 «Межгосударственная система стандартизации. Основные положения» и ГОСТ 1.2-2015 «Межгосударственная система стандартизации. Стандарты межгосударственные, правила и рекомендации по межгосударственной стандартизации. Правила разработки, принятия, обновления и отмены»

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

1 РАЗРАБОТАН Федеральным государственным унитарным предприятием «Всероссийский научно-исследовательский институт стандартизации и сертификации в машиностроении» (ФГУП «ВНИИНМАШ»), Автономной некоммерческой организацией «Научно-исследовательский центр CALS-технологий «Прикладная логистика»» (АНО НИЦ CALS-технологий «Прикладная логистика»)

2 ВНЕСЕН Федеральным агентством по техническому регулированию и метрологии

3 ПРИНЯТ Межгосударственным советом по стандартизации, метрологии и сертификации (протокол от 12 мая 2011 г. N 39)

За принятие проголосовали:

4 Приказом Федерального агентства по техническому регулированию и метрологии от 3 августа 2011 г. N 211-ст межгосударственный стандарт ГОСТ 2.703-2011 введен в действие в качестве национального стандарта Российской Федерации с 1 января 2012 г.

5 ВЗАМЕН ГОСТ 2.703-68

6 ПЕРЕИЗДАНИЕ. Декабрь 2018 г.

Информация об изменениях к настоящему стандарту публикуется в ежегодном информационном указателе «Национальные стандарты», а текст изменений и поправок — в ежемесячном информационном указателе «Национапьные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ежемесячном информационном указателе «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)

1 Область применения

Настоящий стандарт устанавливает правила выполнения кинематических схем изделий всех отраслей промышленности.

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

2 Нормативные ссылки

В настоящем стандарте использованы нормативные ссылки на следующие межгосударственные стандарты:

ГОСТ 2.051-2013 Единая система конструкторской документации. Электронные документы. Общие положения

ГОСТ 2.303-68 Единая система конструкторской документации. Линии

ГОСТ 2.701-2008 Единая система конструкторской документации. Схемы. Виды и типы. Общие требования к выполнению

Примечание — При пользовании настоящим стандартом целесообразно проверить действие ссылочных стандартов в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет или по ежегодно издаваемому информационному указателю «Национальные стандарты», который опубликован по состоянию на 1 января текущего года, и по соответствующим ежемесячно издаваемым информационным указателям, опубликованным в текущем году. Если ссылочный стандарт заменен (изменен), то при пользовании настоящим стандартом следует руководствоваться заменяющим (измененным) стандартом. Если ссылочный стандарт отменен без замены, то положение, в котором дана ссылка на него, применяется в части, не затрагивающей эту ссылку.

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

3.1 Схема кинематическая — документ, содержащий в виде условных изображений или обозначений механические составные части и их взаимосвязи.

Схемы кинематические выполняют в соответствии с требованиями настоящего стандарта и ГОСТ 2.701.

3.2 Схемы кинематические могут быть выполнены как бумажный и (или) электронный конструкторский документ.

Схемы в форме электронного конструкторского документа рекомендуется выполнять однолистными с обеспечением деления этого листа при печати на необходимые форматы.

Примечание — Если схема кинематическая выполняется как электронный конструкторский документ, следует дополнительно руководствоваться ГОСТ 2.051.

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

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

— принципиальные;

— структурные;

— функциональные.

4 Правила выполнения схем

4.1 Правила выполнения принципиальных схем

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

4.1.2 Принципиальную схему изделия изображают, как правило, в виде развертки (см. приложение А).

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

4.1.3 Все элементы на схеме изображают условными графическими обозначениями (УГО) или упрощенно в виде контурных очертаний.

Примечание — Если УГО стандартами не установлено, то разработчик выполняет УГО на полях схемы и дает пояснения.

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

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

4.1.5 Если в состав изделия входит несколько одинаковых механизмов, допускается выполнять принципиальную схему для одного из них в соответствии с требованиями раздела 6, а другие механизмы — изображать упрощенно.

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

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

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

4.1.7 На схеме кинематической, не нарушая ясности схемы, допускается:

— переносить элементы вверх или вниз от их истинного положения, выносить их за контур изделия, не меняя положения;

— поворачивать элементы в положения, наиболее удобные для изображения.

В этих случаях сопряженные звенья пары, вычерченные раздельно, соединяют штриховой линией.

4.1.8 Если валы или оси при изображении на схеме пересекаются, то линии, изображающие их, в местах пересечения не разрывают.

Если на схеме валы или оси закрыты другими элементами или частями механизма, то их изображают как невидимые.

Допускается валы условно поворачивать так, как это показано на рисунке 1.

Рисунок 1

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

4.1.10 На принципиальных схемах изображают в соответствии с ГОСТ 2.303:

— валы, оси, стержни, шатуны, кривошипы и т.д. — сплошными основными линиями толщиной ;

— элементы, показанные упрощенно в виде контурных очертаний, зубчатые колеса, червяки, звездочки, шкивы, кулачки и т.д. — сплошными линиями толщиной ;

— контур изделия, в который вписана схема, — сплошными тонкими линиями толщиной ;

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

— линии взаимосвязи между элементами или между ними и источником движения через немеханические (энергетические) участки — двойными штриховыми линиями толщиной ;

— расчетные взаимосвязи между элементами — тройными штриховыми линиями толщиной .

4.1.11 На принципиальной схеме изделия указывают:

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

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

Примерный перечень основных характеристик и параметров кинематических элементов приведен в приложении Б.

4.1.12 Если принципиальная схема изделия содержит элементы, параметры которых уточняют при регулировании подбором, то на схеме эти параметры указывают на основе расчетных данных и делают надпись: «Параметры подбирают при регулировании».

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

4.1.14 На принципиальной схеме допускается указывать:

— предельные значения чисел оборотов валов кинематических цепей;

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

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

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

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

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

Элементы покупных или заимствованных механизмов (например, редукторов, вариаторов) не нумеруют, а порядковый номер присваивают всему механизму в целом.

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

Характеристики и параметры кинематических элементов допускается помещать в перечень элементов, оформленный в виде таблицы по ГОСТ 2.701.

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

Допускается таблицу характеристик выполнять на отдельных листах.

4.2 Правила выполнения структурных схем

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

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

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

4.3 Правила выполнения функциональных схем

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

4.3.2 Функциональные части изображают простыми геометрическими фигурами.

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

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

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

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

Приложение А (справочное). Пример выполнения принципиальной кинематической схемы

Приложение А
(справочное)

Приложение Б (справочное). Примерный перечень основных характеристик и параметров кинематических элементов

Приложение Б
(справочное)

Таблица Б.1

Приложение В (рекомендуемое). Буквенные коды наиболее распространенных групп элементов

Приложение В
(рекомендуемое)

Таблица В.1

Электронный текст документа
подготовлен АО «Кодекс» и сверен по:
официальное издание
М.: Стандартинформ, 2019

ГОСТ 2.701-84* «ЕСКД. Схемы. Виды и типы. Общие требования к выполнению»

ГОСТ 34.201-89 Информационная технология. Комплекс стандартов…

ГОСТ 34.201-89

Группа П87

ИНФОРМАЦИОННАЯ ТЕХНОЛОГИЯ

Комплекс стандартов на автоматизированные системы

ВИДЫ, КОМПЛЕКТНОСТЬ И ОБОЗНАЧЕНИЕ ДОКУМЕНТОВ ПРИ СОЗДАНИИ АВТОМАТИЗИРОВАННЫХ СИСТЕМ

Information technology. Set of standards for automated systems. Types, sets and indication of documents for automated systems making

ОКСТУ 0034*
________________
* См. примечание ФГУП «СТАНДАРТИНФОРМ»

Дата введения 1990-01-01

_________________
* См. примечание ФГУП «СТАНДАРТИНФОРМ»

1. РАЗРАБОТАН И ВНЕСЕН Государственным комитетом СССР по стандартам, Министерством приборостроения, средств автоматизации и систем управления СССР

2. УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Постановлением Государственного комитета СССР по стандартам от 24.03.89 N 664

3. Срок проверки — 1999 г., периодичность проверки — 10 лет

4. ВЗАМЕН ГОСТ 24.101-80, ГОСТ 24.102-80, РД 50-617-86

5. ССЫЛОЧНЫЕ НОРМАТИВНО-ТЕХНИЧЕСКИЕ ДОКУМЕНТЫ

6. ИЗДАНИЕ с Изменением N 1, утвержденным в декабре 1990 г. (ИУС 4-91)

Настоящий стандарт распространяется на автоматизированные системы (АС), используемые в различных сферах деятельности (управление, исследование, проектирование и т.п.), включая их сочетание, и устанавливает виды, наименование, комплектность и обозначение документов, разрабатываемых на стадиях создания АС, установленных ГОСТ 34.601.

Пояснения терминов, применяемых в настоящем стандарте, приведены в приложении 1.

1. ВИДЫ И НАИМЕНОВАНИЕ ДОКУМЕНТОВ

1.1. Состав видов документов, разрабатываемых на стадии «Исследование и обоснование создания АС» определяют в соответствии с разд.3 ГОСТ 34.601, исходя из требуемых результатов выполнения данной стадии.

1.2. На стадии «Техническое задание» разрабатывают Техническое задание (ТЗ) на создание автоматизированной системы в соответствии с требованиями ГОСТ 34.602.

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

1.3. Виды документов, разрабатываемых на стадиях «Эскизный проект», «Технический проект», «Рабочая документация», приведены в табл.1.

Таблица 1

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

Таблица 2

_______________
* Документы, код которых установлен в соответствии с требованиями стандартов ЕСКД.

Примечания:

1. В таблице приняты следующие обозначения: ЭП — эскизный проект; ТП — технический проект; РД — рабочая документация; ОР — общесистемные решения; ОО — решения по организационному обеспечению; ТО — решения по техническому обеспечению; ИО — решения по информационному обеспечению; ПО — решения по программному обеспечению; МО — решения по математическому обеспечению.

2. Знак Х — означает принадлежность к проектно-сметной или эксплуатационной документации.

3. Номенклатуру документов одного наименования устанавливают в зависимости от принятых при создании системы проектных решений.

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

(Измененная редакциия, Изм. N 1).

1.3.2. Виды документов на программные средства, используемые при создании АС (ее частей), — по ГОСТ 19.101.

1.3.3. Виды документов на технические средства, используемые при создании АС (ее частей), — по ГОСТ 2.102 и по ГОСТ 2.601 в части эксплуатационных документов.

1.3.4. В зависимости от применяемых методов проектирования и специфики создаваемых АС допускается:

1) разрабатывать групповые и базовые документы в соответствии с разд.1, 3, 4, 6 ГОСТ 2.113;

2) выпускать документы отдельными самостоятельными частями, соответствующими разделам основного документа;

3) расширять номенклатуру документов, установленную настоящим стандартом.

1.4. На стадии «Ввод в действие» разрабатывают следующие организационно-распорядительные документы:

1) акт завершения работ;

2) акт приемки в опытную эксплуатацию;

3) акт приемки в промышленную эксплуатацию;

4) план-график работ;

5) приказ о составе приемочной комиссии;

6) приказ о проведении работ;

7) программа работ;

8) протокол испытаний;

9) протокол согласования.

2. КОМПЛЕКТНОСТЬ ДОКУМЕНТАЦИИ

2.1. Перечень наименований разрабатываемых документов и их комплектность на систему и ее части должен быть определен в техническом задании на создание автоматизированной системы (подсистемы).

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

2.2. На каждый комплект должна быть составлена ведомость документов.

2.3. Комплектность документации, обеспечивающей разработку, изготовление, приемку и монтаж технических средств, — по ГОСТ 2.102. Комплектность эксплуатационной документации на эти средства — по ГОСТ 2.601.

2.4. Комплектность документации на программные средства вычислительной техники — по ГОСТ 19.101.

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

3. ОБОЗНАЧЕНИЯ ДОКУМЕНТОВ

3.1. Каждому разработанному документу должно быть присвоено самостоятельное обозначение. Документ, выполненный на разных носителях данных, должен иметь одно обозначение. К обозначению документов, выполненных на машинных носителях, добавляют букву «М».

Заимствованным документам сохраняют ранее присвоенные обозначения.

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

3.3. Обозначение документа имеет следующую структуру:

3.3.1. Правила обозначения системы (части системы) приведены в приложении 2.

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

Код документа отделяют от предыдущего обозначения точкой.

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

3.3.4. Номер редакции документа присваивают, начиная со второй в порядке возрастания от 2 до 9, и отделяют от предыдущего значения точкой. Очередной номер редакции присваивают в случаях сохранения (не аннулирования) предыдущей редакции.

3.3.5. Номер части документа отделяют от предыдущего обозначения дефисом. Если документ состоит из одной части, то дефис не проставляют и номер части документа не присваивают.

3.3.6. Признак документа, выполненного на машинных носителях, вводят при необходимости. Букву «М» отделяют от предыдущего обозначения точкой.

ПРИЛОЖЕНИЕ 1 (справочное). ПОЯСНЕНИЯ ТЕРМИНОВ, ПРИМЕНЯЕМЫХ В НАСТОЯЩЕМ СТАНДАРТЕ

ПРИЛОЖЕНИЕ 1
Справочное

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

Проектно-сметная документация на АС — часть документации на АС, разрабатываемая для выполнения строительных и монтажных работ, связанных с созданием АС.

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

ПРИЛОЖЕНИЕ 2 (рекомендуемое). ПРАВИЛА ОБОЗНАЧЕНИЯ СИСТЕМ И ИХ ЧАСТЕЙ

ПРИЛОЖЕНИЕ 2
Рекомендуемое

1. Структура обозначения автоматизированной системы или ее части имеет вид:

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

3. Код классификационной характеристики системы или ее части (подсистемы, комплекса, компонента) присваивают в соответствии с правилами, установленными в отрасли на основе 425 подкласса общесоюзного классификатора продукции и (или) общесоюзного классификатора подсистем и комплексов задач АСУ — 1 84 154.

4. Порядковый регистрационный номер системы (части системы) присваивает служба организации разработчика, ответственная за ведение картотеки и учет обозначений. Регистрационные номера присваивают с 001 до 999 по каждому коду регистрационной характеристики.

ПРИМЕЧАНИЕ ФГУП «СТАНДАРТИНФОРМ»

На первой странице дополнить кодом: МКС 35.240 (указатель «Национальные стандарты», 2008).

Информационные данные. Ссылочные нормативно-технические документы: ГОСТ 2.601-95 заменен на ГОСТ 2.601-2006.

Электронный текст документа
подготовлен АО «Кодекс» и сверен по:
официальное издание
М.: Стандартинформ, 2008

ГОСТ 2.797-2016 Единая система конструкторской документации (ЕСКД). Правила выполнения вакуумных схем (с Поправкой), ГОСТ от 31 января 2017 года №2.797-2016

ГОСТ 2.797-2016

Группа Т52

МКС 01.110

Дата введения 2017-09-01

Предисловие

Цели, основные принципы и основной порядок проведения работ по межгосударственной стандартизации установлены в ГОСТ 1.0-2015 «Межгосударственная система стандартизации. Основные положения» и ГОСТ 1.2-2015 «Межгосударственная система стандартизации. Стандарты межгосударственные, правила и рекомендации по межгосударственной стандартизации. Правила разработки, принятия, обновления и отмены»

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

1 РАЗРАБОТАН Федеральным государственным унитарным предприятием «Всероссийский научно-исследовательский институт стандартизации и сертификации в машиностроении» (ВНИИНМАШ), Автономной некоммерческой организацией Научно-исследовательский центр CALS-технологий «Прикладная логистика» (АНО НИЦ CALS-технологий «Прикладная логистика»)

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 051 (МТК 051) «Система конструкторской документации»

3 ПРИНЯТ Межгосударственным советом по стандартизации, метрологии и сертификации (протокол от 25 октября 2016 г. N 92-П)

За принятие проголосовали:

(Поправка. ИУС N 4-2019).

4 Приказом Федерального агентства по техническому регулированию и метрологии от 31 января 2017 г. N 26-ст межгосударственный стандарт ГОСТ 2.797-2016 введен в действие в качестве национального стандарта Российской Федерации с 1 сентября 2017 г.

5 ВЗАМЕН ГОСТ 2.797-81

6 ПЕРЕИЗДАНИЕ. Декабрь 2018 г.

Информация об изменениях к настоящему стандарту публикуется в ежегодном информационном указателе «Национальные стандарты», а текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ежемесячном информационном указателе «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)

ВНЕСЕНА поправка, опубликованная в ИУС N 4, 2019 год

Поправка внесена изготовителем базы данных

1 Область применения

Настоящий стандарт распространяется на вакуумные схемы изделий всех отраслей промышленности и устанавливает правила их выполнения.

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

2 Нормативные ссылки

В настоящем стандарте использованы нормативные ссылки на следующие межгосударственные стандарты:

ГОСТ 2.051-2013 Единая система конструкторской документации. Электронные документы. Общие положения

ГОСТ 2.701-2008 Единая система конструкторской документации. Схемы. Виды и типы. Общие требования к выполнению

ГОСТ 2.704-2011 Единая система конструкторской документации. Правила выполнения гидравлических и пневматических схем

ГОСТ 2.710-81 Единая система конструкторской документации. Обозначения буквенно-цифровые в электрических схемах

ГОСТ 2.784-96 Единая система конструкторской документации. Обозначения условные графические. Элементы трубопроводов

ГОСТ 2.721-74 Единая система конструкторской документации. Обозначения условные графические в схемах. Обозначения общего применения

ГОСТ 2.785-70 Единая система конструкторской документации. Обозначения условные графические. Арматура трубопроводная

ГОСТ 2.796-95 Единая система конструкторской документации. Обозначения условные графические в схемах. Элементы вакуумных систем

Примечание — При пользовании настоящим стандартом целесообразно проверить действие ссылочных стандартов в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет или по ежегодно издаваемому информационному указателю «Национальные стандарты», который опубликован по состоянию на 1 января текущего года, и по соответствующим ежемесячно издаваемым информационным указателям, опубликованным в текущем году. Если ссылочный стандарт заменен (изменен), то при пользовании настоящим стандартом следует руководствоваться заменяющим (измененным) стандартом. Если ссылочный стандарт отменен без замены, то положение, в котором дана ссылка на него, применяется в части, не затрагивающей эту ссылку.

3 Термины и определения

В настоящем стандарте применены следующие термины с соответствующими определениями:

3.1

3.2

3.3

3.4

3.5

3.6

4 Основные положения

4.1 Вакуумная схема — документ, содержащий в виде условных изображений или обозначений составные части изделия, действующие при помощи вакуума, либо создающих вакуум и их взаимосвязи.

4.2 Вакуумные схемы могут быть выполнены как бумажный и/или электронный конструкторский документ (КД).

Примечание — Если вакуумная схема выполняется как электронный КД, следует дополнительно руководствоваться ГОСТ 2.051.

4.3 Общие требования к выполнению, типы вакуумных схем — по ГОСТ 2.701.

4.4 Направление потока рабочей среды, элементы привода и управления, знаки регулирования следует выполнять по ГОСТ 2.721, условное графическое обозначение (УГО) элементов трубопроводов и линии связи — по ГОСТ 2.784.

4.5 УГО элементов вакуумных схем следует выполнять по ГОСТ 2.796, УГО арматуры трубопроводов — по ГОСТ 2.785.

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

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

— структурные;

— принципиальные;

— соединений.

5 Правила выполнения вакуумных схем

5.1 Правила выполнения структурных схем — по ГОСТ 2.704.

5.2 Правила выполнения принципиальных схем

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

Элементы (устройства) на принципиальной вакуумной схеме следует изображать с помощью УГО — по ГОСТ 2.796.

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

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

Буквенные коды наиболее распространенных элементов (устройств) должны соответствовать приложению А.

5.2.3 Буквенный код элемента (устройства) должен содержать одну прописную букву (первую букву кода — обязательно) или несколько прописных букв латинского алфавита в соответствии с приложением А.

Первая буква кода элемента (общий буквенный код) должна соответствовать виду группы элементов, к которой принадлежит данный элемент; например клапан тарельчатый VT принадлежит к видам клапанов V.

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

Примечание — Знаки 0 и 1 следует использовать и читать как цифры нуль и единица, за исключением тех случаев, когда их используют в буквенных сочетаниях при образовании позиционных обозначений и устройств, если это не приведет к неправильному пониманию позиционных обозначений. При выборе буквенного кода элемента (устройства) латинского алфавита допускается не учитывать название элемента схемы (устройства).

5.2.4 Порядковый номер буквенно-цифрового позиционного обозначения элемента (устройства) должен быть выполнен арабскими цифрами.

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

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

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

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

5.2.6 Позиционные обозначения следует проставлять на схеме рядом с условными графическими обозначениями элементов (устройств) с правой стороны или над ними (см. рисунок 1).

Рисунок 1

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

Данные об элементах следует записывать в перечень элементов или помещать рядом с элементами (устройствами) на свободном поле схемы. Связь перечня с условными графическими обозначениями элементов должна осуществляться через позиционные обозначения. Форма перечня элементов и порядок его заполнения — по ГОСТ 2.701.

5.2.8 На схеме установки, в состав которой входят функциональные группы, позиционные обозначения элементам следует присваивать по правилам, установленным в 5.2.2-5.2.7, 5.2.9, 5.2.10.

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

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

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

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

Условные порядковые номера в перечне элементов указывать не следует.

5.2.10 На схеме следует указывать обозначения выводов (соединений) элементов (устройств), нанесенные на установке или установленные в их КД.

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

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

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

5.2.11 На вакуумной схеме около УГО элементов, требующих пояснения условий эксплуатации, следует помещать соответствующие надписи, знаки или графические обозначения.

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

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

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

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

5.2.13 На линиях связи следует указывать направления потоков рабочей среды.

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

Рисунок 2

5.3 Правила выполнения схем соединений (монтажных)

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

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

Элементы на схеме соединений следует изображать с помощью УГО, упрощенных внешних очертаний или в виде прямоугольников.

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

5.3.4 Расположение графических обозначений элементов и устройств на схеме соединений должно примерно соответствовать действительному размещению элементов в вакуумной системе (установке).

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

5.3.5 На вакуумной схеме около или внутри УГО элементов и устройств следует указывать позиционное обозначение, присвоенное им на принципиальной схеме.

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

5.3.6 На схеме соединений следует присваивать позиционные обозначения элементам (устройствам), не вошедшим в принципиальную схему (например, соединения трубопроводов и т.п.), по правилам, установленным в 5.2.2-5.2.10.

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

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

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

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

Приложение А (обязательное). Буквенные коды наиболее распространенных видов элементов (устройств)

Приложение А
(обязательное)

Таблица А.1

Редакция документа с учетом
изменений и дополнений подготовлена
АО «Кодекс»

Entity Relationship Diagram — ER-диаграмма в СУБД

Чайтанья Сингх | Файл: DBMS

Модель Entity-Relationship (ER-модель) описывает структуру базы данных с помощью диаграммы, которая известна как Entity Relationship Diagram (ER Diagram) . Модель ER — это проект или план базы данных, которая позже может быть реализована как база данных. Основными компонентами модели E-R являются: набор сущностей и набор отношений.

Что такое диаграмма отношений сущностей (диаграмма ER)?

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

Простая диаграмма ER:

На следующей диаграмме у нас есть две сущности Student и College и их отношения. Отношения между студентом и колледжем многозначны, поскольку в колледже может быть много студентов, однако студент не может учиться в нескольких колледжах одновременно.Сущность «Студент» имеет такие атрибуты, как Stu_Id, Stu_Name и Stu_Addr, а сущность College имеет такие атрибуты, как Col_ID и Col_Name.

Вот геометрические фигуры и их значение на диаграмме E-R. Мы подробно обсудим эти термины в следующем разделе («Компоненты ER-диаграммы») этого руководства, поэтому не беспокойтесь об этих терминах сейчас, просто просмотрите их один раз.

Прямоугольник : представляет наборы сущностей.
Эллипсов : Атрибуты
Алмазы : Набор отношений
Строки : Они связывают атрибуты с наборами сущностей, а наборы сущностей с набором отношений
Двойные эллипсы: Многозначные атрибуты
Двойные эллипсы с пунктирными линиями : Производные атрибуты : Наборы слабых объектов
Двойные строки : Общее участие объекта в наборе отношений

Компоненты ER-схемы

Как показано на приведенной выше диаграмме, ER-диаграмма состоит из трех основных компонентов:
1.Сущность
2. Атрибут
3. Отношение

1. Организация

Сущность — это объект или компонент данных. Сущность представлена ​​в виде прямоугольника на диаграмме ER.
Например: На следующей диаграмме ER у нас есть две сущности Student и College, и эти две сущности имеют отношение «многие к одному», так как многие студенты учатся в одном колледже. Мы узнаем больше об отношениях позже, а пока сосредоточимся на сущностях.

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

2. Атрибут

Атрибут описывает свойство объекта. На диаграмме ER атрибут представлен как овал. Есть четыре типа атрибутов:

1. Ключевой атрибут
2. Составной атрибут
3. Многозначный атрибут
4. Производный атрибут

1.Ключевой атрибут:

Ключевой атрибут может однозначно идентифицировать объект из набора объектов. Например, список учеников

.

Free DFD Tutorial и DFD лучший инструмент для рисования DFD, попробуйте прямо сейчас! Бесплатно

Пример системы заказа еды

Контекстный DFD

Контекстная диаграмма — это диаграмма потока данных, которая показывает только верхний уровень, также известный как уровень 0. На этом уровне есть только один видимый узел процесса, который представляет функции всей системы в отношении того, как она взаимодействует с внешними объектами. . Некоторые из преимуществ контекстной диаграммы:

1. Показывает обзор границ системы
2. Для понимания простых обозначений не требуется никаких технических знаний
3. Просто рисовать, изменять и дорабатывать в качестве ограниченного обозначения

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

Контекстный DFD — это вход в модель потока данных. Он содержит один и только один процесс и не показывает никаких хранилищ данных.

Уровень 1 DFD

На рисунке ниже показан уровень 1 DFD, который представляет собой декомпозицию (т. Е. Разбивку) процесса системы заказа еды, показанного в контексте DFD. Прочтите диаграмму, а затем мы познакомим вас с некоторыми ключевыми концепциями, основанными на этой диаграмме.

Пример диаграммы потока данных системы заказа еды содержит три процесса, четыре внешних объекта и два хранилища данных.

На основании диаграммы мы знаем, что Клиент может разместить Заказ . Процесс Order Food получает заказ Order , пересылает его в Kitchen , сохраняет в хранилище данных Order и сохраняет обновленные сведения об инвентаризации в хранилище данных Inventory . Процесс также доставляет Счет клиенту .

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

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

Советы и предостережения по схеме потока данных

подсказок

1. Метки процесса должны быть глагольными фразами; хранилища данных представлены существительными
2. Хранилище данных должно быть связано как минимум с процессом
3. Внешний объект должен быть связан как минимум с процессом
4. Не позволяйте этому усложняться; обычно 5-7 человек в среднем могут управлять процессами
5. DFD не является детерминированным — нумерация не обязательно указывает последовательность, это полезно для идентификации процессов при обсуждении с пользователями
6. Хранилища данных не должны быть подключены к внешнему объекту, в противном случае это будет означать, что вы предоставляете внешнему объекту прямой доступ к вашим файлам данных
7. Потоки данных не должны существовать между 2 внешними объектами без прохождения процесса
8. Процесс, который имеет входы, но не имеет выходов, считается процессом черной дыры

Предупреждения

Не путайте поток данных и поток процесса

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

Имейте в виду, что диаграмма потоков данных была разработана для представления обмена информацией. Соединители в диаграмме потока данных предназначены для представления данных, а не для представления потока процесса, шага или чего-либо еще. Когда мы обозначаем поток данных, который заканчивается в хранилище данных, «запросом», это означает, что мы передаем запрос как данные в хранилище данных.Хотя это может иметь место на уровне реализации, поскольку некоторые СУБД действительно поддерживают использование функций, которые принимают некоторые значения в качестве параметров и возвращают результат, в диаграмме потока данных мы склонны рассматривать хранилище данных как единственного держателя данных, который не обладают способностью к обработке. Если вы хотите смоделировать поток системы или поток процессов, используйте вместо этого диаграмму действий UML или диаграмму бизнес-процессов BPMN. Если вы хотите смоделировать внутреннюю структуру хранилища данных, используйте диаграмму отношений сущностей.

.

Функциональные и нефункциональные требования: спецификация и типы

Время чтения: 9 минут

Четко определенные требования — важные знаки на пути к успешному проекту. Они заключают формальное соглашение между клиентом и поставщиком, что они оба работают для достижения одной и той же цели. Высококачественные подробные требования также помогают снизить финансовые риски и обеспечить выполнение проекта в соответствии с графиком. Согласно определению Свода знаний Business Analysis, требования — это пригодное для использования представление потребности.

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

Классификация требований

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

Требования высокого уровня переходят каскадом к конкретным деталям

Бизнес-требования. Сюда входят высокоуровневые заявления о целях, задачах и потребностях.

Требования заинтересованных сторон. Также указываются потребности отдельных групп заинтересованных сторон, чтобы определить, чего они ожидают от конкретного решения.

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

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

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

Давайте рассмотрим функциональные и нефункциональные требования более подробно.

Функциональные требования и их спецификации

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

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

Вот еще один простой пример: Как гость, мне нужен диван, на котором я могу спать всю ночь .

Требования обычно записываются в виде текста, особенно для проектов, управляемых Agile.Однако они также могут быть визуальными. Вот наиболее распространенные форматы и документы:

• Документ спецификации требований к программному обеспечению
• Примеры использования
• Истории пользователей
• Иерархическая структура работ (WBS) (функциональная декомпозиция)
• Прототипы
• Модели и схемы

Документ спецификации требований к программному обеспечению

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

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

СГД должна включать следующие разделы:

Назначение . Определения, обзор системы и предыстория.

Общее описание. Допущения, ограничения, бизнес-правила и видение продукта.

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

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

Пример: Если вы хотите увидеть настоящий документ, загрузите этот пример SRS, созданный в Университете штата Мичиган, который включает в себя все вышеупомянутые пункты, а также варианты использования для иллюстрации частей продукта.

Примеры использования

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

Каждый вариант использования включает три основных элемента:

Актеры. Это пользователи вне системы, которые взаимодействуют с системой.

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

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

Есть два формата для представления вариантов использования:

• Спецификация варианта использования структурирована в текстовом формате
• Диаграмма вариантов использования

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

• Описание
• Состояние до и после взаимодействия
• Базовый путь взаимодействия
• Альтернативный путь
• Путь исключения

Пример:

Шаблон спецификации варианта использования

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

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

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

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

Актеры. Это цифры, которые отображают внешних пользователей (людей или системы), которые взаимодействуют с системой.

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

Пример:

Пример схемы использования

Истории пользователей

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

Типичная пользовательская история записывается так:

Как <тип пользователя>, я хочу <некоторая цель>, чтобы <какая-то причина>.

Пример :

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

Пользовательские истории должны сопровождаться критериями приемлемости . Это условия, которым должен удовлетворять продукт, чтобы его приняли пользователь, заинтересованные стороны или владелец продукта. У каждой пользовательской истории должен быть хотя бы один критерий приемлемости. Эффективные критерии приемки должны быть проверяемыми, краткими и полностью понятными для всех членов команды и заинтересованных сторон. Они могут быть записаны в виде контрольных списков, обычного текста или в формате Given / When / Then.

Пример:

Вот пример контрольного списка критериев приемлемости для пользовательской истории, описывающей функцию поиска:

• Поле поиска доступно на верхней панели.
• Поиск запускается, когда пользователь нажимает Отправить .
• Заполнитель по умолчанию — серый текст. Введите имя .
• Заполнитель исчезает, когда пользователь начинает печатать.
• Язык поиска — английский.
• Пользователь может ввести не более 200 символов.
• Не поддерживает специальные символы. Если пользователь ввел специальный символ в поле поиска, отображается сообщение с предупреждением: Ввод поиска не может содержать специальные символы .

Наконец, все пользовательские истории должны соответствовать модели качества INVEST :

• I — Независимый
• N — договорная
• V — ценный
• E — Примерно
• S — Малый
• T — Тестируемый

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

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

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

Приблизительно. Качественный пользовательский рассказ можно оценить.Это поможет составить график команды и расставить приоритеты в реализации. Чем масштабнее история, тем труднее ее оценить.

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

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

Функциональная декомпозиция или структуры декомпозиции работ (WBS)

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

Предлагаем следующую логику функциональной декомпозиции:

1. Найдите наиболее общую функцию.
2. Найдите ближайшую подфункцию.
3. Найдите следующий уровень подфункции.
4. Проверьте свою схему.

Или процесс разложения может выглядеть так:

Функция высокого уровня -> Подфункция -> Процесс -> Действие

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

Пример:

Пример функциональной декомпозиции

Программные прототипы

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

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

Конструкторская документация и прототипы

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

Вайрфреймы. Каркасы — это графические структуры веб-сайта или приложения с низкой точностью. Они помогают отображать различные страницы продуктов с разделами и интерактивными элементами.

Мокапы. Когда макеты готовы, они превращаются в макеты, визуальные дизайны, которые передают внешний вид конечного продукта. В конечном итоге макеты могут стать финальным дизайном продукта.

Дизайн-прототипы. Эти документы содержат визуальные элементы и допускают некоторые взаимодействия с интерфейсом, такие как прокрутка, нажатие на ссылки или заполнение форм.Дизайнерские прототипы можно создавать с нуля, используя HTML и CSS, но большинство UX-команд используют сервисы прототипирования, такие как InVision.

Пример:

Чтобы узнать больше о том, как обрабатываются процессы проектирования UX, ознакомьтесь с нашим примером создания решения для управления поездками для Cornerstone, корпоративного поставщика SaaS, в котором мы использовали все три типа требований к дизайну.

Нефункциональные требования

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

Давайте внимательно рассмотрим типичные нефункциональные требования.

Удобство использования

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

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

Интуитивность: насколько просто понять интерфейс, кнопки, заголовки и т. Д.

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

Пример: Требования к удобству использования могут учитывать языковые барьеры и задачи локализации: Люди, не понимающие французского, должны иметь возможность использовать продукт . Или вы можете установить требования доступности: Пользователи клавиатуры, которые перемещаются по веб-сайту с помощью , должны иметь возможность дотянуться до кнопки «Добавить в корзину» на странице продукта за 15 кликов.

Безопасность

Требования безопасности обеспечивают защиту программного обеспечения от несанкционированного доступа к системе и хранимым в ней данным. Он учитывает разные уровни авторизации и аутентификации для разных ролей пользователей. Например, конфиденциальности данных — это характеристика безопасности, которая описывает, кто может создавать, просматривать, копировать, изменять или удалять информацию. Безопасность также включает защиту от вирусов и вредоносных программ.

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

Надежность

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

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

Производительность

Производительность — это атрибут качества, который описывает реакцию системы на различные взаимодействия пользователя с ней. Низкая производительность приводит к негативному восприятию пользователями. Это также ставит под угрозу безопасность системы, когда она перегружена.

Пример: Время загрузки главной страницы должно быть не более 2 секунд для пользователей, которые получают доступ к веб-сайту через мобильное соединение LTE.

Наличие

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

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

Масштабируемость

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

Пример: Лимит посещаемости веб-сайта должен быть достаточно масштабируемым, чтобы поддерживать 200 000 пользователей одновременно.

Заключительные слова

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

.