Методические указания по подготовке и защите отчетов на специализации "Прикладная математика. Системное программирование". Кленин А.С. - 15 стр.

     Раздел «4.3. Описание протокола»
      Описать назначение протокола.
      Указать стороны, сообщающиеся при помощи данного протокола, а также базовый
протокол более низкого уровня (например, согласно модели OSI [1]). Формализовать ото-
бражение описываемого протокола на базовый. Описать формат сообщений протокола и
общие правила их интерпретации, аналогично п. 4.1. Указать динамические требования к
протоколу (задержки, тайм-ауты, повтор сообщений и т. д.). Указать наличие хранимого
состояния в протоколе (stateful или stateless).
      Перечислить список всех сообщений протокола, для каждого сообщения указать со-
держащиеся в нём значения фиксированных полей (например, тип пакета) и семантику пе-
ременных полей, а также сопутствующие изменения в состояниях сторон. Обратить вни-
мание на возможные ошибки и непредвиденные ситуации, в частности, непредвиденное
прекращение функционирования одной из сторон и разрыв канала связи.
      Привести одну или более динамическую диаграмму (например, диаграмму состоя-
ний).

     Раздел «5. Функциональные требования»
     Перечислить требования в формате ненумерованного списка, предварённого фразой
«Система должна:» или «Система должна позволять пользователю:». Если система состоит
из подсистем согласно п. 3, то данный раздел должен быть соответственно разбит на под-
разделы, объединяющие требования к каждой из подсистем.
     Отдельные требования должны начинаться с глагола в неопределённой форме (на-
пример, «создавать», «редактировать») либо с условия, за которым следует такой глагол
(например, «в случае сбоя выдавать сообщение об ошибке»). Допускается объединение
нескольких требований в одно предложение (например, «добавлять и удалять записи»).
Следует, где это возможно, использовать глаголы несовершенного вида («просматривать»,
но не «просмотреть»), поскольку этим подчёркивается повторяемость действий.
     Требования должны быть чётко сформулированными и иметь однозначную интер-
претацию. В случае необходимости следует привести уточняющее предложение (напри-
мер, «редактировать данные о пользователе, при этом изменять значения всех полей, кро-
ме идентификатора пользователя»). Для сокращения повторяющихся наборов требований
рекомендуется вводить дополнительные определения (например, «здесь и далее под тер-
мином работать со списком понимается возможность добавлять, удалять и изменять эле-
менты списка»).
     В случае если у системы или подсистемы имеется несколько категорий пользовате-
лей с различными возможностями, разбить список требований на отдельные списки для
каждого пользователя, и указать перед ними соответствующие фразы (например, «Система
должна позволять Бухгалтеру…»). При этом названия категорий должны точно соответст-
вовать разделу 2.3. Альтернативным вариантом является указание списка пользователей
для каждого требования в отдельности. Следует выбрать один из вариантов (обычно из со-
ображений компактности представления), и последовательно придерживаться его на про-
тяжении всего раздела.
     Привести, по мере необходимости, детализированные диаграммы вариантов исполь-
зования, диаграммы кооперации, и другие.

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