ВУЗ:
Составители:
16
библиотек допускается объединение разделов 5 и 6. Алгоритм следует называть только в
случае, если он фиксирован внешними требованиями (например, «решать систему линей-
ных уравнений», либо «решать систему линейных уравнений методом Гаусса»).
Раздел «6. Требования к интерфейсу»
Определить требования к общему виду и платформе интерфейса (например, «интер-
фейс командной строки» или «Windows-интерфейс», или «Web-интерфейс»). Если система
обладает несколькими интерфейсами, перечислить их и указать, какая часть функциональ-
ности доступна через каждый из них.
Указать специальные требования к интерфейсу, накладываемые составом целевой
аудитории, ограничениями технических средств либо требованиями заказчика. Например
:
«интерфейс должен быть доступен для использования слепыми людьми», «интерфейс
должен функционировать при использовании браузера Internet Explorer 3.0», «все функции
интерфейса должны быть доступны при использовании для ввода только клавиатуры» и
т. п.
Описать структуру интерфейса, основные команды или органы управления, наиболее
тесно связанные с функциональностью системы. При необходимости использовать модели
экрана.
Если описывается
интерфейс библиотеки подпрограмм, указать прототип каждой
доступной внешнему пользователю функции, класса или и структуры данных. Для каждой
функции указать назначение и, где необходимо, смысл и диапазон допустимых значений
параметров. В случае небольшого объёма библиотеки допустимо объединение с разделом
5, а для библиотеки классов и с разделом 4. В таком случае структурирование подразделов
производится по функциям или классам.
Привести одну или более динамическую диаграмму (например, диаграмму состоя-
ний).
Раздел «7. Прочие требования»
Указать требования к нефункциональным характеристикам системы, отличающиеся
от общепринятых либо имеющие критическое значения для успешной реализации проекта.
Любой из подразделов, а также и весь раздел можно опустить в случае отсутствия соответ-
ствующих требований.
Раздел «7.1. Требования к надёжности»
Оценить вероятность возникновения, возможные последствия и убытки от нештат-
ных ситуаций (рисков), могущих возникнуть в связи с использованием системы, в том
числе:
• отказ оборудования;
• обнаружение ошибок разной степени тяжести;
• утеря или повреждение данных;
• нарушение безопасности;
• резкое изменение экономических условий или производственного процесса.
Сделать вывод о наличии
или отсутствии необходимости мероприятий по управле-
нию данными рисками. Перечислить и описать список мероприятий, для каждого меро-
приятия указать: процедуру проведения, предполагаемую периодичность, категории поль-
зователей, ответственных за его выполнение. Например: «ежедневное резервное копиро-
вание базы данных на магнитную ленту производится в конце рабочего дня Оператором»
библиотек допускается объединение разделов 5 и 6. Алгоритм следует называть только в
случае, если он фиксирован внешними требованиями (например, «решать систему линей-
ных уравнений», либо «решать систему линейных уравнений методом Гаусса»).
Раздел «6. Требования к интерфейсу»
Определить требования к общему виду и платформе интерфейса (например, «интер-
фейс командной строки» или «Windows-интерфейс», или «Web-интерфейс»). Если система
обладает несколькими интерфейсами, перечислить их и указать, какая часть функциональ-
ности доступна через каждый из них.
Указать специальные требования к интерфейсу, накладываемые составом целевой
аудитории, ограничениями технических средств либо требованиями заказчика. Например:
«интерфейс должен быть доступен для использования слепыми людьми», «интерфейс
должен функционировать при использовании браузера Internet Explorer 3.0», «все функции
интерфейса должны быть доступны при использовании для ввода только клавиатуры» и
т. п.
Описать структуру интерфейса, основные команды или органы управления, наиболее
тесно связанные с функциональностью системы. При необходимости использовать модели
экрана.
Если описывается интерфейс библиотеки подпрограмм, указать прототип каждой
доступной внешнему пользователю функции, класса или и структуры данных. Для каждой
функции указать назначение и, где необходимо, смысл и диапазон допустимых значений
параметров. В случае небольшого объёма библиотеки допустимо объединение с разделом
5, а для библиотеки классов и с разделом 4. В таком случае структурирование подразделов
производится по функциям или классам.
Привести одну или более динамическую диаграмму (например, диаграмму состоя-
ний).
Раздел «7. Прочие требования»
Указать требования к нефункциональным характеристикам системы, отличающиеся
от общепринятых либо имеющие критическое значения для успешной реализации проекта.
Любой из подразделов, а также и весь раздел можно опустить в случае отсутствия соответ-
ствующих требований.
Раздел «7.1. Требования к надёжности»
Оценить вероятность возникновения, возможные последствия и убытки от нештат-
ных ситуаций (рисков), могущих возникнуть в связи с использованием системы, в том
числе:
• отказ оборудования;
• обнаружение ошибок разной степени тяжести;
• утеря или повреждение данных;
• нарушение безопасности;
• резкое изменение экономических условий или производственного процесса.
Сделать вывод о наличии или отсутствии необходимости мероприятий по управле-
нию данными рисками. Перечислить и описать список мероприятий, для каждого меро-
приятия указать: процедуру проведения, предполагаемую периодичность, категории поль-
зователей, ответственных за его выполнение. Например: «ежедневное резервное копиро-
вание базы данных на магнитную ленту производится в конце рабочего дня Оператором»
16
Страницы
- « первая
- ‹ предыдущая
- …
- 14
- 15
- 16
- 17
- 18
- …
- следующая ›
- последняя »
