Сдам Сам

ПОЛЕЗНОЕ


КАТЕГОРИИ







Интерфейсы программного обеспечения





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

- Имя;

- Мнемонический код;

- Номер спецификации;

- Номер версии;

- Источник.

Авторское право © 1998 IEEE. Все права сохранены. 13


Стандарт IEEE 830-1998 Методика составления спецификаций требований к программному обеспечению

(Пересмотр стандарта IEEE 830-1993)

Для каждого интерфейса необходимо обеспечить следующее:

а) Обсуждение назначения интерфейса программного обеспечения в отношении программного изделия.

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

Интерфейсы связи

Этот подраздел должен определять различные интерфейсы связи, такие как локальные сетевые протоколы и т.д.

Ограничения памяти

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

Операции

Этот подраздел должен определять стандартные и специальные операции, требуемые пользователем, такие как:

а) Различные режимы операций в организации пользователя (например, операции, инициализируемые пользователем);

б) Периоды интерактивных операций и периоды автоматических операций;

в) Функции поддержки обработки данных;

г) Операции по резервированию и восстановлению.

ПРИМЕЧАНИЕ - Этот подраздел иногда указывается как часть раздела Интерфейсы пользователя.

Требования к адаптации места использования

Этот подраздел должен:

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

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

Функции изделия (Подраздел 2.2 SRS)

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

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

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

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

14 Авторское право © 1998 IEEE. Все права сохранены.


Рекомендуемая Институтом Инженеров по Электротехнике и Радиоэлектронике (IEEE) Стандарт IEEE 830-1998

(Пересмотр стандарта IEEE 830-1993)

Характеристики пользователя (Подраздел 2.3 SRS)

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

Ограничения (Подраздел 2.4 SRS)

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

а) Регулирующие политики;

б) Аппаратные ограничения (например, требования к синхронизации сигналов);

в) Интерфейсы с другими приложениями;

г) Параллельные операции;

д) Функции контроля;

е) Функции управления;

ж) Требования к языку более высокого порядка;

з) Протоколы квитирования сигналов (например, XON-XOFF..ACK-NACK);

и) Требования к надежности;

к) Критичность применения;

л) Критерии безопасности и защиты.

Допущения и зависимости (Подраздел 2.5 SRS)

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

Распределение требований (Подраздел 2.6 SRS)

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

Специфические требования (Раздел 3 SRS)

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

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

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

в) Все требования должны быть однозначно идентифицируемы.

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

Авторское право © 1998 IEEE. Все права сохранены. 15


Стандарт IEEE 830-1998 Методика составления спецификаций требований к программному обеспечению

(Пересмотр стандарта IEEE 830-1993)

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

Внешние интерфейсы

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

Он должен включать содержание и формат следующим образом:

а) Наименование позиции;

б) Описание назначения;

в) Источник входных данных или адресат выходных данных;

г) Допустимый диапазон, точность и/или допуск;

д) Единицы измерения;

е) Синхронизация;

ж) Связи с другими входами/выходами;

з) Форматы/организация экрана;

и) Форматы/организация окна;

к) Форматы данных;

л) Форматы команд;

м) Сообщения о конце.

Функции

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

Они включают:

а) Проверку достоверности по входам;

б) Точную последовательность операций;

в) Отклики на ненормальные ситуации, включая:

1) Переполнение

2) Средства связи

3) Обработка и устранение ошибок;

г) Влияние параметров;

д) Связь выходов с входами, включая:

1) Последовательности ввода/вывода

2) Формулы для преобразования ввода-вывода..

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







Что делает отдел по эксплуатации и сопровождению ИС? Отвечает за сохранность данных (расписания копирования, копирование и пр.)...

Что будет с Землей, если ось ее сместится на 6666 км? Что будет с Землей? - задался я вопросом...

Конфликты в семейной жизни. Как это изменить? Редкий брак и взаимоотношения существуют без конфликтов и напряженности. Через это проходят все...

ЧТО ТАКОЕ УВЕРЕННОЕ ПОВЕДЕНИЕ В МЕЖЛИЧНОСТНЫХ ОТНОШЕНИЯХ? Исторически существует три основных модели различий, существующих между...





Не нашли то, что искали? Воспользуйтесь поиском гугл на сайте:


©2015- 2024 zdamsam.ru Размещенные материалы защищены законодательством РФ.