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

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

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

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

     Раздел «4. Спецификация данных»
       Описать внешние (видимые пользователю и/или другим программам) протоколы,
форматы и структуры данных, разработанные в рамках описываемой работы. Сюда входят
форматы файлов, протоколы обмена информацией между подсистемами, описанными в
п. 3, сущности, хранимые в базе данных и имеющие смысл в предметной области.
       Не следует включать в данный раздел протоколы, форматы и структуры:
       1) Стандартные — документированные в существующих и не относящихся к описы-
          ваемой системе документах, например, формат RTF, протокол TCP/IP. Вместо
          описания указать ссылку на соответствующий документ (например, RFC [4]). Если
          некоторый формат или протокол имеет большое значение для понимания структу-
          ры и функциональности программы, можно добавить его краткое (не более одной
          страницы) описание. Если, кроме этого, описание протокола или формата трудно-
          доступно (например, это внутренний формат, принятый в рамках описываемой ор-
          ганизации), то его можно привести в Приложении.
       2) Строго внутренние — в том числе структуры данных в оперативной памяти, про-
          токолы, форматы и сущности, которые никогда не видны внешним пользователям
          и программам и не упоминаются в функциональных требованиях. Эти данные
          должны быть описаны в разделе «Проект».
       3) Секретные и закрытые — попадающие под действие коммерческой или государст-
          венной тайны. Наличие таких данных может служить препятствием для допуска
          работы к защите и должно специально оговариваться с руководителем. Следует
          различать случаи закрытых данных (распространённый случай, не являющийся
          помехой защите работы) и закрытого формата.
                                             13