По спецификации: Шаблон спецификации требований к ПО — К. Вигерс

Пишем спецификации. Часть 1. Инструменты — начинаем с простого / Хабр

Итак, наконец-то мы решили начать писать спецификации. Поскольку сам процесс для нас новый, пускай хотя бы инструменты будут привычными.
Что мы хотим от инструмента? Пожалуй, все требования сводятся к одному слову — удобство. Ведь нужно иметь очень веские причины, чтобы заниматься чем-то, если это делать неудобно. А ведь нам хочется, чтобы наши коллеги получали удовольствие от написания спецификаций. Как, например, от программирования.

Лично у меня требований немного:

• Удобство поиска. Нужно уметь найти нужную спецификацию по ключевым словам. Или убедиться, что такой спецификации нет.
• Удобство правки. Чем проще будет процесс написания спецификации, тем с большей охотой наши коллеги будут заниматься этим.
• Удобство чтения. Заранее известно, что круг читателей наших спецификаций будет шире, чем круг писателей. Это и программисты, которые будут кодировать по этим спецификациям, и тестеры, которые потом проверят то, что накодировали программисты, и даже наши клиенты, которым хочется как можно раньше узнать, что для них накодируют программисты.

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

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

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

• Заголовок спецификации: тема, автор / дата / рецензент
• Исходная формулировка / требования от заказчика
• Примечания для тестировщиков
• Примечания для разработчиков – когда в тексте функциональной спецификации нужно на чем-то заострить их внимание. Если же это целиком техническая спецификация, например описание реализации какой-то хитрой функции на сервере, или всякой там архитектуры, то используем обычный стиль.
• Сценарий.

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

Чуть позже стало понятно, что нам нужны перекрестные ссылки из одного документа на другой. Благо в Ворд-е есть относительно удобный механизм для этого. Можно делать ссылки и внутри документа, и между документами. Со временем стали появляться документы – порталы, состоящие в основном из ссылок на другие документы.

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

Итоги:

• За полгода работы над одним из наших проектов было порождено порядка тридцати полновесных спецификаций. Их писали аналитик, ведущий разработчик, и некоторые рядовые разработчики.
• Нам потребовалось:
  • программы из пакета MS Office, по числу пишуших спецификации.
  • общедоступная папка на сервере для хранения документов.

• Разработаны правила оформления и хранения спецификаций.

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

Минусы:

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

Резюме:
Описанный инструментарий вполне достаточен, когда вы только начинаете пробовать свои силы в специфицировании. Его можно использовать в очень небольших проектах с числом разработчиков около пяти. Если же у вас несколько проектов, несколько команд, и главное, вы уже вкусили прелестей спецификаций и вам хочется большего, то вам нужен более продвинутый инструмент. Для себя мы нашли его в Вики.
(см. Часть 2. Вики — всё под рукой)

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

Спецификация требований программного обеспечения (англ. Software Requirements Specification, SRS) является полным описанием поведения системы, которая будет создана. Она включает ряд сценариев использования, которые описывают все виды взаимодействия пользователей с программным обеспечением. Сценарии использования также известны как функциональные требования. В дополнении к сценариям использования, спецификация программного обеспечения также содержат нефункциональные (или дополнительные) требования. Нефункциональные требования — требования, которые налагают дополнительные ограничения на систему (такие как требования эффективности работы, стандарты качества, или проектные ограничения).

Типы требований

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

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

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

• Требования эксплуатации или развёртывания: Где система будет использоваться?
• Профиль миссии или сценарий: Как система достигнет целей миссии?
• Требования производительности: Какие параметры системы являются критическими для достижения миссии?
• Сценарии использования: Как различные компоненты системы должны использоваться? 
• Требования эффективности: Насколько эффективной должна быть система для выполнения миссии?
• Эксплуатационный жизненный цикл: Как долго система будет использоваться?
• Окружающая среда: Каким окружением система должна будет эффективно управлять?

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

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

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

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

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

Производные требования

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

Стандарты и шаблоны для ТЗ на разработку ПО / Habr

Введение

Недавно ко мне обратились, чтобы я посоветовал стандарты для написания технического задания (ТЗ) на разработку автоматизированных систем (АС) и программного обеспечения (ПО). Вот думаю, сейчас зайду в Яндекс, найду подходящую статейку и отправлю её. Но не тут-то было! Одной статьи, где перечисляются стандарты для ТЗ, включая шаблоны и примеры готовых документов, я не нашел. Придется сделать такую статейку самому…

И так, основные стандарты, методологии и своды знаний, где упоминается ТЗ или SRS (Software (or System) Requirements Specification):

• ГОСТ 34

• ГОСТ 19

• IEEE STD 830-1998

• ISO/IEC/ IEEE 29148-2011

• RUP

• SWEBOK, BABOK и пр.

ГОСТ 34

ГОСТ 34.602-89 Техническое задание на создание автоматизированной системы регламентирует структуру ТЗ на создание именно СИСТЕМЫ, в которую входят ПО, аппаратное обеспечение, люди, которые работают с ПО, и автоматизируемые процессы.

Согласно ГОСТ 34 техническое задание должно включать следующие разделы:

1. Общие сведения

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

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

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

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

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

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

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

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

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

ГОСТ 19

“ГОСТ 19.ххх Единая система программной документации (ЕСПД)” — это комплекс государственных стандартов, устанавливающих взаимоувязанные правила разработки, оформления и обращения программ (или ПО) и программной документации. Т.е. этот стандарт относится к разработке именно ПО.
Согласно ГОСТ 19.201-78 Техническое задание, требования к содержанию и оформлению техническое задание должно включать следующие разделы:

1. Введение;

2. Основания для разработки;

3. Назначение разработки;

4. Требования к программе или программному изделию;

5. Требования к программной документации;

6. Технико-экономические показатели;

7. Стадии и этапы разработки;

8. Порядок контроля и приемки;

9. Приложения.

Естественно ГОСТ 34 (и 19) уже устарели, и я не люблю их использовать, но при правильном интерпретации стандартов, можно получить хорошее ТЗ, см. Заключение.

IEEE STD 830-1998

Достаточно хорошее определение стандарта 830-1998 — IEEE Recommended Practice for Software Requirements Specifications дано в самом его описании:

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

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

1. Введение

• 1. Назначение
• 2. Область действия
• 3. Определения, акронимы и сокращения
• 4. Ссылки
• 5. Краткий обзор

2. Общее описание

• 1. Взаимодействие продукта (с другими продуктами и компонентами)
• 2. Функции продукта (краткое описание)
• 3. Характеристики пользователя
• 4. Ограничения
• 5. Допущения и зависимости

3. Детальные требования (могут быть организованы по разному, н-р, так)

• 1. Требования к внешним интерфейсам
  • 1. Интерфейсы пользователя
  • 2. Интерфейсы аппаратного обеспечения
  • 3. Интерфейсы программного обеспечения
  • 4. Интерфейсы взаимодействия

• 2. Функциональные требования
• 3. Требования к производительности
• 4. Проектные ограничения (и ссылки на стандарты)
• 5. Нефункциональные требования (надежность, доступность, безопасность и пр.)
• 6. Другие требования

4. Приложения
5. Алфавитный указатель

На самом деле новичку достаточно трудно понять, что должно содержаться в данных разделах по вышеприведенной структуре (как и в случае с ГОСТом), поэтому нужно читать сам стандарт, который легко найти в Интернете. Как и примеры, правда, на англ. языке.

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

ISO/IEC/ IEEE 29148-2011

Стандарт IEEE 29148-2011 обеспечивает единую трактовку процессов и продуктов, используемых при разработке требований на протяжении всего жизненного цикла систем и программного обеспечения. Он приходит на смену стандартов IEEE 830-1998, IEEE 1233-1998, IEEE 1362-1998.

Данный стандарт содержит два шаблона спецификации требований:

• System requirements specification (SyRS)

• Software requirements specification (SRS)

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

SyRS может содержать следующие разделы:

1. Введение

• 1. Назначение системы
• 2. Содержание системы (границы системы)
• 3. Обзор системы
  • 1. Содержание системы
  • 2. Функции системы
  • 3. Характеристики пользователей

• 4. Термины и определения

2. Ссылки

3. Системные требования

• 1. Функциональные требования
• 2. Требования к юзабилити
• 3. Требования к производительности
• 4. Интерфейс (взаимодействие) системы
• 5. Операции системы
• 6. Состояния системы
• 7. Физические характеристики
• 8. Условия окружения
• 9. Требования к безопасности
• 10. Управление информацией
• 11. Политики и правила
• 12. Требования к обслуживанию системы на протяжении ее жизненного цикла
• 13. Требования к упаковке, погрузке-разгрузки, доставке и транспортировке

4. Тестирование и проверка (список необходимых приемочных тестов, которые отражают зеркально раздел 3)

5. Приложения

• 1. Предположения и зависимости
• 2. Аббревиатуры и сокращений

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

SRS может содержать следующие разделы:

1. Введение

• 1. Назначение
• 2. Содержание (границы)
  • 3. Обзор продукта
  • 1. Взаимодействие продукта (с другими продуктами и компонентами)
  • 2. Функции продукта (краткое описание)
  • 3. Характеристики пользователей
  • 4. Ограничения

• 4. Термины и определения

2. Ссылки

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

• 1. Требования к внешним интерфейсам
• 2. Функции продукта
• 3. Требования к юзабилити
• 4. Требования к производительности
• 5. Требования к логической структуре БД
• 6. Ограничения проектирования
• 7. Системные свойства ПО
• 8. Дополнительные требования

4. Тестирование и проверка (список необходимых приемочных тестов, которые отражают зеркально раздел 3)

5. Приложения

• 1. Предположения и зависимости
• 2. Аббревиатуры и сокращений

Данный стандарт достаточно сложно найти в открытом виде в Интернете, но постараться можно, и опять же только на англ.

RUP

Структура SRS в RUP(Rational Unified Process) представляет собой документ, в котором необходимо описать артефакты, полученные в процессе специфицирования требований.

Шаблон SRS в RUP адаптирован из стандарта IEEE STD 830 и содержит два варианта:

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

• Упрощенный шаблон SRS со структурированными функциональными требованиями в виде вариантов использования (use cases):

1. Введение.

• 1. Цель.
• 2. Краткая сводка возможностей.
• 3. Определения, акронимы и сокращения.
• 4. Ссылки.
• 5. Краткое содержание.

2. Обзор системы

• 1. Обзор вариантов использований.
• 2. Предположения и зависимости.

3. Детальные требований

• 1. Описание вариантов использования.
• 2. Дополнительные требования.
• 3. Другие функциональные требования.
• 4. Нефункциональные требования.

4. Вспомогательная информация.

Естественно, что в Интернете можно найти шаблон и примеры SRS от RUP.

SWEBOK, BABOK и пр.

SWEBOK, BABOK, а также множество других методологий разработки ПО и сводов знаний при упоминании SRS ссылаются на вышеупомянутые зарубежные стандарты.

Также стоит сказать, что для описания требований к АС и ПО используются и другие виды документов, кот каждый называет по разному: FRD (Functional Requirements Document), RD (Requirements Document), ПЗ (Постановка задачи или Пояснительная записка) и пр. Но это все производные документы от вышеупомянутых стандартов, не имеющих отраслевой стандартизации, хотя, в некоторых случаях, уже и с устоявшейся терминологией.

А как же Agile?

Я скажу одной фразой из Манифеста Agile: “Working software over comprehensive documentation”. Поэтому в Agile документации отводится совсем мало места.

Мое же убеждение, что разработать АС без ТЗ можно (используя техники/рекомендации Agile), но вот в дальнейшем сопровождать — невозможно. Поэтому сразу задумайтесь, как вы будете писать ТЗ и другую документацию, при разработке ПО по Agile.

Заключение

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

Но главное, чтобы ТЗ не превращалось в ХЗ, а, именно, содержание (наполнение) в ТЗ — самое главное! Но это уже совсем другая история… Если есть интерес, то можно пройти он-лайн курс Разработка и управление требованиями к ПО.

Ну а кто дочитал до конца — тому бонус: пример ТЗ, который я писал много лет назад (сейчас уже просто аналитиком давно не работаю, да и другие более удачные примеры запрещает открывать на всеобщее обозрение NDA).

Также рекомендую ознакомиться со следующими материалами:

Спецификация — это… Что такое Спецификация?

Спецификация — (позднелат. specificatio, от лат. species — род, вид, разновидность и facio — делают) может означать:

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

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

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

Разновидности

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

Спецификация к счёту — часть расчётного документа.

Техническая спецификация — спецификация технического устройства.

В информатике и компьютерной технике:

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

Содержание документа

Спецификация может содержать:

• Описательное название, номер или другой идентификатор спецификации
• Время последнего пересмотра и отметку, кем был выполнен пересмотр
• Логотип или торговую марку, указывающую кому принадлежит право на копирование, владельца и происхождение документа
• Содержание документа, если документ длинный
• Ответственное лицо или организацию по вопросам по спецификации, по обновлениям и отклонениям
• Важность, область применения спецификации и её назначение
• Термины, определения и аббревиатуры для пояснения сути спецификации
• Способы проверки для всех установленных требований и характеристик
• Материальные требования: физические, механические, электрические, химические и другие. Целевые и допустимые
• Требования по эксплуатационному тестированию. Целевые и допустимые
• Изображения, фотографии или технические иллюстрации
• Требования по мастерству
• Требования к сертифицированности
• Требования по технике безопасности
• Экологические требования
• Контроль по обеспечению качества, образец для проверки, проверка, критерий приёма работы
• Лицо или организация ответственное за выполнение спецификации
• Выполнение и доставка
• Условия по отклонениям, перепроверке, пересмотре, корректировке измерений и характеристик
• Ссылки и цитаты в тексте спецификации которые могут потребоваться для установки ясности документа
• Подписи и разрешения, если они необходимы
• Контроль изменений (с помощью специальных компьютерных программ) для последовательной разработки, проверки и выполнения, если документ предназначен для внутреннего использования
• Приложения, которые раскрывают детали, добавляют ясности, или пояснения по оплате

См. также

Ссылки

Примечания

Спецификация к договору – Образец, бланк 2020 года

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

Что это такое?

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

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

Кто составляет?

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

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

Можно ли вносить изменения?

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

Например, после подписания ДПТ, в спецификации обнаружена техническая недоработка в расчетах, хотя стоимость соглашения обозначена правильно. Согласно закону № 44-ФЗ от 05.04.2013 года, можно составить добавочное соглашение о корректировке спецификации в связи с обнаруженным техническим недочетом. При этом, измененная спецификация вступит в силу после регистрации ДПТ в реестре.

Возможность внедрения правок в спецификацию государственного контракта подтверждается также письмом Минэкономразвития РФ № Д28И-1889 от 30.09.2014 года «О направлении ответов …».

Варианты спецификаций

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

• Купли-продажи.
• Поставки.
• Передачи имущества в залог.
• Дарения.
• Лизинга и финансовой аренды.
• Ренты.

Чаще всего составляются спецификация при заключении ДПТ и предоставления услуг (к примеру – транспортных).

К спецификации выставляются следующие требования:

1. Обозначение ссылки на ДПТ, к которому документ прилагается.
2. Присвоение номера документу, при составлении нескольких приложений.
3. Отображение каждой товарной марки.
4. Обозначение ед. измерения продукции, количества, цены и суммы по каждой категории продукции.
5. Отображение общей суммы с НДС и без него.
6. Подписание сторонами документа, скрепленных печатями.

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

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

Как правильно составить спецификацию к договору?

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

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

Заполнение спецификации начинается с «шапки», в которой отображается:

1) Присвоенный спецификации номер (приложение №__).

2) Номер и дата ДПТ, к которому она прикладывается.

3) Название бланка (Спецификация на …)

4) Вторая часть спецификации выполнена в форме таблицы, с включением следующих данных:

• Порядкового номера.
• Названия продукции.
• Ее количества.
• Ед. измерения.
• Цены за единицу продукции.
• Стоимости продукции.
• Итоговой стоимости, в т.ч. НДС

При потребности таблица дополняется другими сведениями.

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

6) Также здесь можно отметить сроки поставки продукции.

7) В завершении бланк подписывается участниками сделки с указанием:

• Должности подписантов.
• Подписи с расшифровкой фамилий.
• Печатей предприятий.

Оформленная спецификация составляется в 2-х экземплярах, прикладывается к ДПТ и считается неотъемлемым приложением к основному контракту.

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

Занимаясь предпринимательской деятельностью многие предприятия сталкиваются с оформлением ДПТ, по предоставлению услуг, по исполнению различных работ и т. д. Любая из перечисленных сделок требует от участников сотрудничества выполнения договорных условий. Согласно ст. 158 и 434 ГК РФ договор без оформленной спецификации считается действительным в том случае, когда в нем отображены все требуемые договорные условия.

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

Поставка

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

1. Четкого названия каждой категории товара.
2. Числа поставляемой продукции каждой категории.
3. Цены за единицу товара без НДС.
4. Стоимости продукции без НДС.
5. Итоговой стоимости партии поставленной продукции, в т. ч. с обозначением НДС.

Ниже предлагается пример спецификации к ДПТ.

Скачать

Оказание услуг

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

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

1. Оказании огромного списка услуг, предоставляемых согласно контракту.
2. Оказании услуг в различные промежутки времени.
3. Конкретном описании услуги.
4. Подписании ДУ, если стороны не определились со списком услуг.

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

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

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

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

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

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

1. Отображение номера приложения.
2. Обозначение названия документа «Спецификация».
3. Ссылки на ДУ с обозначением его номера и даты.
4. День и место оформления спецификации обязаны совпадать с данными основного ДУ. Это обеспечит недопущение проблем при судебном разбирательстве, в случае разногласий.
5. Наименование участников сделки в спецификации обязаны совпадать с основным ДУ.
6. Реквизиты сторон в конце спецификации можно сократить до названия участников сделки, подписей и расшифровок фамилий.
7. При временном действии спецификации, требуется отобразить условия, особенности предоставления услуг и условия расчетов.

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

Ниже предлагается образец спецификации по ДУ.

Скачать

Как, где и сколько времени хранить документ?

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

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

3.3. Спецификация программного обеспечения

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

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

Рис. 3.8. Процесс
разработки требований

Процесс разработки
требований включает четыре основных
этапа.

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

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

3.
Специфицирование
требований. Осуществляется
перевод всей совокупности информации,
собранной на предыдущем этапе, в документ,
определяющий множество требований.
Этот документ обычно содержит два типа
требований: пользовательские – обобщенные
представления заказчиков и конечных
пользователей о системе; системные –
детальное описание функциональных
показателей системы.

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

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

3.4. Проектирование и реализация программного обеспечения

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

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

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

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

Ниже перечислены
отдельные этапы процесса проектирования.

1.
Архитектурное
проектирование. Определяются
и документируются подсистемы и взаимосвязи
между ними.

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

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

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

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

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

Рис. 3.9. Обобщенная
схема процесса проектирования

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

Спецификация оборудования и материалов в Excel

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

Данный шаблон спецификации выполнен для листа формата А4. Графы в спецификации заполнены в соответствии с формой 1 — ГОСТ 21.110-2013 (действующий). Шрифт в шаблоне принимается GOST type A. Если вам данный шрифт не подходит, его можно изменить как на листе «СВОДНАЯ», так и на листе «Спецификация».

Использовать спецификацию нужно в следующем порядке:

1. Все технические характеристики оборудования, изделий и материалов вы указываете ТОЛЬКО на листе «СВОДНАЯ». На этом же листе, вы можете копировать, вставлять, удалять, редактировать спецификацию как вам угодно. Все данные которые вы указываете на данном листе, также отображаются на листе «Спецификация».

2. На листе «Спецификация» вы уже получаете готовую спецификацию заполненную по форме 1 — ГОСТ 21.110-2013 со штампами. На данном листе вам осталось только заполнить штампы.

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

Поделиться в социальных сетях

Благодарность:

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

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

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

определение спецификации Free Dictionary

Его школа-интернат научила его рисовать до определенных пределов, научила рассчитывать и понимать спецификации. Если в этот момент его страна устала от своих усилий и передала ему незаконченное, чтобы он боролся за жизнь в атмосфере рекламы и индивидуального предпринимательства, это действительно не его вина. Некоторые пчелы какое-то время пробовали новый план и обнаружили. он стоил в восемь раз больше воска, чем старая шестисторонняя спецификация; и, поскольку они никогда не позволяли кластеру повесить трубку и спокойно изготовить воск, настоящего воска было мало.Но какого цвета может быть возражение, если сразу следует спецификация объектов, на которые ссылаются эти общие термины, и они даже не разделены более длинной паузой, чем точка с запятой? Ситуация, почва, климат, характер продукции, природа правительства, гениальность граждан, степень информации, которой они обладают, состояние торговли, искусства, промышленности, эти обстоятельства и многое другое, слишком сложные, мелкие или случайные, чтобы допустить конкретную спецификацию, вызывают различия трудно себе представить в относительном богатстве и богатстве разных стран.В последнее время вы скорее привыкли к этому; но, возможно, это произошло из-за того, что между нами не было правильной спецификации. Поэтому, когда рабочие ушли, он сел, вынул свою записную книжку и занялся составлением наброска плана и определением расходов, которые он мог бы покажите его Берджу на следующее утро и дайте ему задание убедить оруженосца согласиться. Самый длинный список требований к пособию будет выглядеть очень коротким. «Я сделаю все возможное, чтобы закончить спецификации до вашего возвращения.» Если что-то не так. спецификации обязательно что есть.На нем был голубой фланелевый костюм и соломенная шляпа с цветной лентой, и он смотрел на мир, который, как показала его манера, был сконструирован в соответствии с его собственными требованиями, через единственную оправу. действительно очень рад ознакомиться с этими спецификациями, но сейчас у меня на уме это собственное дело. Я не любитель вин, Банни, как ты знаешь, но я надеюсь, что ты ценишь спецификации так же, как и я.
.

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

Резюме

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

Резюме

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

О технологии

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

О книге

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

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

При покупке печатной книги Мэннинг предлагает бесплатные электронные книги в формате PDF, ePub и Kindle.Также доступен весь код из книги.

Что внутри

Общие шаблоны процессов Как избежать неправильных практик Встраивание SBE в ваш процесс Более 50 примеров из практики Дополнительные ресурсы можно найти на сайте спецификацийexample.com.

.

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

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

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

Все новые функции 3.15 помечены соответствующим текстом, начиная с версии 3.15, или в JSDoc с использованием аннотации @since 3.15.0 . Основные новые функции:

Базовый протокол состоит из заголовка и части содержимого (сравнимо с HTTP).Заголовок и контентная часть
разделенные «\ r \ n».

Заголовочная часть состоит из полей заголовка. Каждое поле заголовка состоит из имени и значения, разделенных знаком «:» (двоеточие и пробел). Структура полей заголовка соответствует семантике HTTP. Каждое поле заголовка заканчивается символом «\ r \ n». Учитывая, что последнее поле заголовка и сам общий заголовок оканчиваются на ‘\ r \ n’, и что хотя бы один заголовок является обязательным, это означает, что две последовательности ‘\ r \ n’ всегда непосредственно предшествуют части содержимого сообщения. .

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

Часть заголовка кодируется с использованием кодировки «ascii».Сюда входит «\ r \ n», разделяющий заголовок и часть содержимого.

Содержимое Деталь

Содержит фактическое содержание сообщения. Содержательная часть сообщения использует JSON-RPC для описания запросов, ответов и уведомлений. Часть содержимого кодируется с использованием кодировки, указанной в поле Content-Type. По умолчанию используется кодировка utf-8 , единственная поддерживаемая на данный момент кодировка. Если сервер или клиент получает заголовок с кодировкой, отличной от utf-8 , он должен ответить с ошибкой.

(Предыдущие версии протокола использовали строковую константу utf8 , которая не является правильной константой кодирования в соответствии со спецификацией.) Для обратной совместимости настоятельно рекомендуется, чтобы клиент и сервер обрабатывали строку utf8 как utf-8 .

Пример:

  Длина содержимого: ... \ r \ n
\ г \ п
{
«jsonrpc»: «2.0»,
"id": 1,
"метод": "textDocument / didOpen",
"params": {
...
}
}
  

Базовый протокол JSON-структуры

Следующие определения TypeScript описывают базовый протокол JSON-RPC:

Абстрактное сообщение

Общее сообщение, определенное JSON-RPC.Протокол языкового сервера всегда использует «2.0» в качестве версии jsonrpc .

  интерфейс Сообщение {
jsonrpc: строка;
}
  

Сообщение-запрос

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

  интерфейс RequestMessage расширяет сообщение {

/ **
* Идентификатор запроса.
* /
id: номер | строка;

/ **
* Метод, который нужно вызвать.* /
метод: строка;

/ **
* Параметры метода.
* /
параметры ?: массив | объект;
}
  

Ответное сообщение

Ответное сообщение, отправленное в результате запроса. Если запрос не предоставляет значение результата, получатель запроса все равно должен вернуть ответное сообщение, чтобы соответствовать спецификации JSON RPC. Свойство result ResponseMessage должно иметь значение null в этом случае, чтобы сигнализировать об успешном запросе.

  интерфейс ResponseMessage расширяет сообщение {
/ **
* Идентификатор запроса.* /
id: номер | строка | значение NULL;

/ **
* Результат запроса. Этот участник НЕОБХОДИМ в случае успеха.
* Этот член НЕ ДОЛЖЕН существовать, если при вызове метода произошла ошибка.
* /
результат ?: строка | номер | логическое | объект | значение NULL;

/ **
* Объект ошибки в случае сбоя запроса.
* /
ошибка ?: ResponseError;
}

interface ResponseError {
/ **
* Число, указывающее на тип возникшей ошибки.
* /
кодовое число;

/ **
* Строка с кратким описанием ошибки.
* /
сообщение: строка;

/ **
* Примитивное или структурированное значение, которое содержит дополнительные
* информация об ошибке.Может быть опущено.
* /
данные ?: строка | номер | логическое | массив | объект | значение NULL;
}

экспорт пространства имен ErrorCodes {
// Определено JSON RPC
экспорт const ParseError: number = -32700;
константа экспорта InvalidRequest: number = -32600;
константа экспорта MethodNotFound: number = -32601;
константа экспорта InvalidParams: number = -32602;
экспорт const InternalError: number = -32603;
экспорт константы serverErrorStart: number = -32099;
экспорт const serverErrorEnd: число = -32000;
экспорт const ServerNotInitialized: число = -32002;
экспорт константы UnknownErrorCode: number = -32001;

// Определяется протоколом.export const RequestCancelled: number = -  

.

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

В этом документе описана версия 3.14.x протокола языкового сервера. Реализацию для узла версии протокола 3.14.x можно найти здесь.

Версию этого документа 2.x можно найти здесь.
Версию 1.x этого документа можно найти здесь.

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

Базовый протокол

Базовый протокол состоит из заголовка и части содержимого (сравнимо с HTTP).Заголовок и контентная часть
разделенные «\ r \ n».

Заголовочная часть состоит из полей заголовка. Каждое поле заголовка состоит из имени и значения,
через «:» (двоеточие и пробел).
Каждое поле заголовка заканчивается символом «\ r \ n».
Учитывая, что последнее поле заголовка и сам общий заголовок оканчиваются на «\ r \ n»,
и что хотя бы один заголовок является обязательным, это означает, что две последовательности «\ r \ n» всегда
непосредственно перед содержанием сообщения.

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

Часть заголовка кодируется с использованием кодировки «ascii». Сюда входит «\ r \ n», разделяющий заголовок и часть содержимого.

Содержимое Деталь

Содержит фактическое содержание сообщения. Содержательная часть сообщения использует JSON-RPC для описания запросов, ответов и уведомлений.Часть содержимого кодируется с использованием кодировки, указанной в поле Content-Type. По умолчанию используется кодировка utf-8 , которая на данный момент является единственной поддерживаемой кодировкой. Если сервер или клиент получает заголовок с кодировкой, отличной от utf-8 , он должен ответить с ошибкой.

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

Пример:

  Content-Length: ... \ r \ n
\ г \ п
{
«jsonrpc»: «2.0»,
"id": 1,
"метод": "textDocument / didOpen",
"params": {
...
}
}
  

Базовый протокол JSON-структуры

Следующие определения TypeScript описывают базовый протокол JSON-RPC:

Абстрактное сообщение

Общее сообщение, определенное JSON-RPC. Протокол языкового сервера всегда использует «2.0» в качестве версии jsonrpc .

  интерфейс Сообщение {
jsonrpc: строка;
}
  

Сообщение-запрос

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

  интерфейс RequestMessage расширяет сообщение {

/ **
* Идентификатор запроса.
* /
id: номер | строка;

/ **
* Метод, который нужно вызвать.
* /
метод: строка;

/ **
* Параметры метода.
* /
params ?: Array  | объект;
}
  

Ответное сообщение

Ответное сообщение, отправленное в результате запроса. Если запрос не предоставляет значение результата, получатель запроса все равно должен вернуть ответное сообщение, чтобы соответствовать спецификации JSON RPC.Свойство result ResponseMessage должно иметь значение null в этом случае, чтобы сигнализировать об успешном запросе.

  интерфейс ResponseMessage расширяет сообщение {
/ **
* Идентификатор запроса.
* /
id: номер | строка | значение NULL;

/ **
* Результат запроса. Этот участник НЕОБХОДИМ в случае успеха.
* Этот член НЕ ДОЛЖЕН существовать, если при вызове метода произошла ошибка.
* /
результат ?: строка | номер | логическое | объект | значение NULL;

/ **
* Объект ошибки в случае сбоя запроса.* /
ошибка ?: ResponseError <любой>;
}

interface ResponseError  {
/ **
* Число, указывающее на тип возникшей ошибки.
* /
кодовое число;

/ **
* Строка с кратким описанием ошибки.
* /
сообщение: строка;

/ **
* Примитивное или структурированное значение, которое содержит дополнительные
* информация об ошибке. Может быть опущено.
* /
данные ?: D;
}

экспорт пространства имен ErrorCodes {
// Определено JSON RPC
экспорт const ParseError: number = -32700;
константа экспорта InvalidRequest: number = -32600;
константа экспорта MethodNotFound: number = -32601;
константа экспорта InvalidParams: number = -32602;
экспорт const InternalError: number = -32603;
экспорт константы serverErrorStart: number = -32099;
экспорт const serverErrorEnd: число = -32000;
экспорт const ServerNotInitialized: число = -32002;
экспорт константы UnknownErrorCode: number = -32001;

// Определяется протоколом.экспортная константа RequestCancelled: number = -32800;
константа экспорта ContentModified: number = -32801;
}
  

Уведомление

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

  интерфейс NotificationMessage расширяет сообщение  

.