Перевод с англ.: (C)
Dale, 05.05.2011 — 12.05.2011.
Продолжение.
Первая частьВ этом разделе обсуждается каждая основная часть SRS. Эти части упорядочены ниже в виде плана, который может использоваться как образец при написании SRS.
Хотя SRS не обязана в точности следовать этому плану или использовать такие же заголовки частей, хорошая SRS должна включать в себя всю приведенную информацию.
Содержание SRS:
- Введение
- Назначение
- Область применения
- Определения, акронимы и сокращения
- Обзор
- Общее описание
- Позиционирование продукта
- Функции продукта
- Пользовательские характеристики
- Ограничения
- Предположения и зависимости
- Специфические требования (см. пункты с 5.3.1 по 5.3.8 с пояснением возможных специфических требований. См. также в Приложении А различные способы организации этого раздела SRS).
- Приложения
- Индекс
Введение должно представлять обзор SRS В целом. Оно должно включать следующие подразделы:
- Назначение.
- Область применения.
- Определения, акронимы и сокращения.
- Ссылки.
- Обзор.
В этом подразделе следует:
- Определить назначение SRS;
- Задать целевую аудиторию SRS.
Этот подраздел должен:
- Идентифицировать производимый продукт по имени (например, Host DBMS, Report Generator и т.д.);
- Пояснять, что должен делать программный продукт, а также, при необходимости, чего он не должен делать;
- Описать применение программного обеспечения, включая выгоды, намерения и цели;
- Согласовываться со сходными положениями спецификаций верхнего уровня (например, спецификацией требований к системе), если они существуют.
Этот подраздел должен представлять определения всех терминов, акронимов и сокращений, необходимых для правильной интерпретации SRS. Эта информация может быть представлена в виде ссылок на одно или более приложений к SRS либо на другие документы.
Данный подраздел должен:
- Представлять полный перечень документов, на которые есть ссылки где-либо в SRS;
- Идентифицировать каждый документ по названию, отчетному номеру (если применимо), дате и опубликовавшей организации;
- Задавать источники, из которых могут быть получены документы, на которые имеются ссылки.
Эта информация может быть представлена в виде ссылки на приложение или другой документ.
Данный подраздел должен:
- Описывать содержимое остальной части SRS;
- Пояснять организацию SRS.
Этот раздел SRS должен описывать общие факторы, оказывающие влияние на продукт и требования к нему. В этом разделе не приводятся специфические требования. В нем подготавливается основа для требований, которые детально определяются в
Разделе 3 SRS, и приводится информация, облегчающая их понимание.
Этот раздел обычно состоит из шести подразделов:
- Позиционирование продукта;
- Функции продукта;
- Пользовательские характеристики;
- Ограничения;
- Предположения и зависимости;
- Распределение требований.
Этот подраздел позиционирует продукт среди других связанных продуктов. Если продукт является независимым и полностью самодостаточным, это следует отразить здесь. Если SRS определяет продукт, который является компонентом большей системы, как это часто бывает, то данный подраздел должен связать требования к большей системе с функциональностью программного обеспечения и определить интерфейсы между системой и программным обеспечением.
Могут быть полезными блок-схемы, показывающие основные компоненты большей системы, связи между ними и внешние интерфейсы.
Этот подраздел должен также описывать, как программное обеспечение работает под действием различных ограничений. Например, эти ограничения могут включать:
- Системные интерфейсы;
- Пользовательские интерфейсы;
- Аппаратные интерфейсы;
- Программные интерфейсы;
- Коммуникационные интерфейсы;
- Память;
- Операции;
- Требования к адаптируемости на месте.
Следует перечислить все системные интерфейсы и идентифицировать функциональность программного обеспечения для выполнения требований к системе, а также описание интерфейса для соответствия системе.
Следует задать:
- Логические характеристики каждого интерфейса между программным продуктом и его пользователями. Сюда входят конфигурационные характеристики (например, требуемые экранные формы, страницы или раскладки окон, содержимое всех отчетов или меню, а также доступность программируемых функциональных клавиш), необходимые для выполнения программных требований.
- Все аспекты оптимизации интерфейса с персоналом, который должен использовать систему. Они могут просто включать список, как система должна выглядеть с точки зрения пользователя, а как не должна. Например, может быть требование наличия опции полных или кратких сообщений об ошибках. Подобно всем остальным, эти требования должны быть верифицируемыми, например: «оператор 4-го разряда должен научиться выполнять действие X за Z минут после часового обучения», а не «оператор должен выполнять действие X». (Это также можно задать в «Системных атрибутах программного обеспечения» в разделе под названием «Простота использования»).
Здесь следует задать логические характеристики каждого интерфейса между программным продуктом и аппаратными компонентами системы. Сюда входят конфигурационные характеристики (число портов, набор инструкций и т.д.). Также освещаются такие моменты, как: какие устройства поддерживаются, как они поддерживаются, а также протоколы. Например, поддержка терминала может задавать поддержку полноэкранного интерфейса, в противоположность построчному вводу.
Следует задать использование прочих необходимых программных продуктов (например, система управления данными, операционная система или математический пакет), а также интерфейсы с другими прикладными системами (например, связь между системой приема оплаты счетов и общей бухгалтерской системой). Для каждого необходимого программного продукта следует предоставить следующую информацию:
- Название;
- Мнемоника;
- Номер спецификации;
- Номер версии;
- Источник.
Для каждого интерфейса следует предоставить следующую информацию:
- Обсуждение назначения интерфейсного программного обеспечения с точки зрения программного продукта.
- Определение интерфейса в терминах содержания и формата сообщений. Не обязательно детально описывать хорошо документированные интерфейсы, но требуется ссылка на документ, определяющий требуемый интерфейс.
Следует задать различные интерфейсы коммуникаций: протоколы локальных сетей и т.д.
Следует задать все значимые характеристики и ограничения, касающиеся первичной и вторичной памяти.
Следует задать обычные и специфические операции, которые требуются пользователю, например:
- Различные модели операций в организации пользователя (например, операции, инициируемые пользователем);
- Периоды интерактивных операций и периоды операций, не требующих ручного вмешательства;
- Функции поддержки обработки данных;
- Операции резервного копирования и восстановления.
Следует:
- Определить требования ко всем данным или последовательностям инициализации, специфичным для данного места, задачи или режима работы (например, таблицы значений, безопасные пределы и т.д.);
- Задать особенности, относящиеся к месту или задаче, которые следует модифицировать с целью адаптации программного обеспечения к конкретной инсталляции.
В этом подразделе SRS следует представить сводку основных функций, выполняемых системой. Например, SRS для бухгалтерской программы может посвятить эту часть работе со счетами, обслуживанию клиентов и подготовке платежных поручений, не вдаваясь в обширную детализацию этих функций.
Иногда сводка функций, необходимых для данной части, берется прямо из соответствующего раздела спецификации верхнего уровня (если она есть), которая размещает некоторые функции в программном продукте. Заметим для ясности, что:
- Функции должны быть организованы таким образом, чтобы сделать перечень функций понятным потребителю или другим читателям при первом прочтении документа.
- Можно использовать текстовые или графические методики для представления различных функций и отношений между ними. Подобные диаграммы не должны представлять реализацию продукта, а лишь показывать логические взаимосвязи между переменными.
Этот подраздел SRS должен описывать общие характеристики предполагаемых пользователей, включая уровень образования, опыт и техническую грамотность. В нем не следует устанавливать специфические требования, но следует привести причины, по которым некоторые специфические требования заданы далее в
Разделе 3 SRS.
В этом подразделе должны быть приведены общие описания всего того, что может ограничить действия разработчика. Они включают:
- Правовые вопросы;
- Аппаратные ограничения (например, требования к длительности сигналов);
- Интерфейсы с другими приложениями;
- Параллельные операции;
- Функции аудита;
- Функции управления;
- Языковые ограничения высшего порядка;
- Протоколы синхронизации сигналов (например, XON-XOFF, ACK-NACK);
- Требования к надежности;
- Критичность приложения;
- Соображения безопасности и секретности.
В этом подразделе следует перечислить все факторы, которые влияют на требования, устанавливаемые SRS. Эти факторы не являются проектными ограничениями, а скорее относятся к их изменениям, которые могут повлиять на требования SRS. Например, может быть сделано предположение, что некоторая операционная система будет доступна для оборудования, на которое ориентирован программный продукт. Если в действительности операционная система недоступна, потребуется соответствующее изменение SRS.
Этот подраздел должен представлять требования, которые могут быть отложены до будущих версий системы.
Этот раздел SRS должен содержать все требования к программному обеспечению на уровне детализации, достаточном, чтобы позволить разработчикам создать систему, удовлетворяющую этим ограничениям, а тестерам – проверить, удовлетворяет ли система этим ограничениям. В данном разделе каждое требование должно быть ориентировано на пользователей, операторов или другие системы, внешние по отношению к данной. Эти требования должны включать минимальное описание для каждого ввода в систему, каждого ответа системы, а также всех функций, выполняемых системой в ответ на ввод или для поддержки вывода. Поскольку зачастую эта часть SRS является самой большой и наиболее важной, применяются следующие принципы:
- Специфические требования должны соответствовать характеристикам, описанным в 4.3.
- Специфические требования должны снабжаться перекрестными ссылками на ранние документы.
- Все требования должны быть уникально идентифицируемыми.
- Следует уделить особое внимание организации требований с целью достижения максимальной читабельности.
Перед изучением способов организации требований полезно рассмотреть различные элементы, включающие в себя требования, которые описаны в подразделах с
5.3.1 по
5.3.7.
Здесь должно быть детальное описание всех входных и выходных данных программной системы. Оно должно дополнять описания интерфейсов из
5.2 и не содержать повторяющейся информации.
Оно должно иметь формат и содержание, как указано ниже:
- Имя элемента;
- Описание назначения;
- Источник входных данных или получатель выходных;
- допустимый диапазон, точность и отклонения;
- Единицы измерения;
- Временные диаграммы;
- Взаимосвязи с другими входами/выходами;
- Форматы и организация экранов;
- Форматы и организация окон;
- Форматы данных;
- Форматы команд;
- Завершающие сообщения.
Функциональные требования должны определять фундаментальные действия, которые должны выполняться программным обеспечением для приема и обработки входных данных, а также обработки и вывода выходных данных. Они обычно перечисляются в виде предложений, начинающихся со слов «Система должна…».
Они включают:
- Проверку допустимости входных значений;
- Точный порядок действий;
- Реакцию на нештатные ситуации, включающие:
- Переполнение;
- Коммуникационные проблемы;
- Обработку ошибок и восстановление;
- Влияние параметров;
- Взаимосвязь между входными и выходными данными, включая:
- Порядок ввода/вывода;
- Формулы преобразования входных данных в выходные
Может оказаться удобным разделение функциональных требований на подфункции или подпроцессы. Это не значит, что программный проект будет разделен таким же образом.
Этот подраздел должен задавать как статические, так и динамические численные требования, предъявляемые в целом к программному обеспечению или к взаимодействию человека с программой. Статические численные требования могут включать следующие:
- Число поддерживаемых терминалов;
- Число одновременно поддерживаемых пользователей;
- Объем и тип обрабатываемой информации.
Статические численные требования иногда оформляются в виде отдельного раздела.
Динамические численные требования могут включать, например, число транзакций и задач, или объем данных, обрабатываемых в некоторый период данных в условиях как нормальной, так и пиковой нагрузки.
Все эти требования следует формулировать в терминах измеримых величин.
Например:
95% транзакций должны обрабатываться менее чем за 1 секунду
вместо:
Оператор не должен ждать, пока завершится транзакция.
Примечание. Численные границы, применимые к отдельной функции, обычно задаются в описании данной функции, в подразделе обработки.
Здесь следует задать логические требования к информации, которая должна размещаться в базе данных. Они могут включать следующие:
- Типы информации, используемой различными функциями;
- Частоту использования;
- Возможность доступа;
- Сущности и отношения между ними;
- Ограничения целостности;
- Требования к хранению данных.
Здесь задаются ограничения проектирования, налагаемые другими стандартами, аппаратурой и т.д.
Этот подраздел должен задавать ограничения, вытекающие из существующих стандартов и правил. Они могут включать следующее:
- Форматы отчетов;
- Именование данных;
- Бухгалтерские процедуры;
- Протоколирование работы.
Например, требования к программному обеспечению по трассировке вычислительных действий. Подобные трассировки необходимы для некоторых приложений для выполнения требований правовых или финансовых стандартов. Требование протоколирования работы может, например, устанавливать, что при изменениях в платежной ведомости прежнее и новое значения должны записываться в файл трассировки.
Некоторые атрибуты программного обеспечения могут служить требованиями. Важно, чтобы требуемые атрибуты были заданы таким образом, чтобы можно было объективно проверить выполнение данного требования. В подразделах с
5.3.6.1 по
5.3.6.5 приведен список примеров.
Следует перечислить факторы, необходимые для установления требуемого уровня надежности программного обеспечения.
Следует перечислить факторы, призванные гарантировать определенный уровень доступности системы, такие как контрольные точки, восстановление и перезапуск.
Следует перечислить факторы, защищающие программное обеспечение от случайного или злонамеренного доступа, использования, модификации, разрушения или разглашения. Специфические требования в этой области включают необходимость:
- Использования криптографии;
- Хранение логов или истории;
- Назначать некоторые функции различным модулям;
- Ограничивать коммуникации между некоторыми областями программы;
- Проверять целостность данных для критических переменных.
Следует перечислить атрибуты программного обеспечения, относящиеся к легкости поддержки самого программного обеспечения. Это могут быть некоторые требования, относящиеся к модульности, интерфейсам, сложности и т.д. Не следует помещать здесь требования лишь потому, что принято считать их хорошим тоном разработки.
Следует перечислить атрибуты программного обеспечения, касающиеся легкости переноса программного обеспечения на другие компьютеры и/или операционные системы. Они могут включать следующее:
- Доля компонентов с машинно-зависимым кодом;
- Доля машинно-зависимого кода;
- Использование испытанного переносимого языка;
- Использование особенного компилятора или подмножества языка;
- Использование особенной операционной системы.
Для любой нетривиальной системы детальные требования обширно разрастаются. Поэтому рекомендуется тщательный подход к их организации в виде, оптимальном для понимания. Не существует единой организации, оптимальной для всех систем. Различные классы систем придерживаются различной организации требований в
Разделе 3 SRS. Некоторые способы организации описаны в подразделах с
5.3.7.1 по
5.3.7.7.
Поведение некоторых систем кардинально различается в зависимости от режима системы. Например, система управления может иметь различные наборы функций для разных режимов: обучение, нормальный или аварийный. При организации этого раздела по режимам, можно использовать планы
A.1 или
A.2. Выбор определяется тем, зависят ли от режима интерфейсы и производительность.
Некоторые системы обеспечивают различные наборы функций для разных классов пользователей. Например, система управления лифтом предоставляет различные возможности пассажирам, обслуживающему персоналу и пожарным. При организации этого раздела по классам пользователей следует использовать план
A.3.
Объекты – это сущности реального мира, которые имеют соответствие в системе. Например, в системе мониторинга пациентов в число объектов входят пациенты, датчики, медсестры, кабинеты, врачи, медикаменты и т.д. С каждым объектом связаны наборы атрибутов (данного объекта) и функций (выполняемых данным объектом). Эти функции называются также сервисами, методами или процессами. При организации этого раздела по объектам следует использовать план
A.4. Заметим, что наборы объектов могут иметь общие атрибуты и сервисы. Они группируются вместе как классы.
Функциональная возможность – это внешний сервис системы, который может потребовать последовательность ввода данных для достижения желаемого результата. Например, в телефонной системе функциональные возможности включают местный вызов, переадресацию звонка и конференцию. Обычно функциональные возможности описывают в виде последовательности пар запрос-ответ. При организации этого раздела в соответствии с функциональными возможностями следует использовать план
A.5.
Некоторые системы могут быть лучше организованы путем описания их функций в терминах внешних воздействий. Например, функции системы автоматического приземления самолета могут быть разбиты на секции для потери тяги, порывов ветра, неожиданной смены курса, избыточной вертикальной скорости и т.д. При организации этого раздела в соответствии с внешними воздействиями следует использовать план
A.6.
Некоторые системы могут быть лучше организованы путем описания всех функций, поддерживающих генерацию откликов. Например, функции системы управления персоналом могут быть разбиты на секции, соответствующие всем функциям, связанным с генерацией чеков оплаты, всем функциям, связанным с генерацией текущего списка сотрудников, и т.д. Следует использовать план
A.6, в котором все внешние воздействия заменены откликами.
Если ни одна из вышеперечисленных организационных схем не подходит, общая функциональность может быть организована в виде иерархии функций, организованных в соответствии с входными данными, выходными данными или внутренними данными. Могут быть использованы диаграммы потоков данных и словари данных, чтобы показать взаимосвязи между функциями и данными. При организации этого раздела в соответствии с функциональной иерархией следует использовать план
A.7.
В процессе работы над SRS могут оказаться применимыми более одной организационной схемы из перечисленных в
5.3.7.7. В таких случаях организуйте специфические требования по нескольким иерархиям, приспособленным под специфические нужды системы, для которой разрабатываются спецификации. Например, см.
A.8 как пример организации, комбинирующей классы пользователей и функциональные возможности. Все дополнительные требования могут быть размещены в отдельном разделе в конце SRS.
Имеется множество нотаций, методик и автоматизированных инструментов для поддержки документирования требований. В основном они полезны в части организационной функции. Например, при организации по режимам могут оказаться полезными конечные автоматы диаграммы состояний; при организации по объектам может оказаться полезным объектно-ориентированный анализ; при организации по функциональным возможностям могут оказаться полезными последовательности запрос-ответ, а при организации по функциональной иерархии могут пригодиться диаграммы потоков данных и словари данных.
В любом из планов, описанных с
A.1 по
A.8, разделы с именем «Функциональное требование i» могут быть описаны на естественном языке, на псевдокоде, на языке описания систем либо в виде четырех подразделов с именами «Введение», «Входные данные», «Обработка» и «Выходные данные».
Вспомогательная информация делает SRS более удобочитаемой. Она включает следующее:
- Оглавление;
- Индекс;
- Приложения.
Оглавление и индекс крайне важны и должны следовать общим принципам композиции.
Приложения не всегда рассматриваются как часть SRS и не всегда необходимы. Они могут включать:
- Примеры форматов входных и выходных данных, описания примеров ценового анализа или результаты пользовательских обзоров;
- Вспомогательная и дополнительная информация, которая может помочь читателю SRS;
- Описание проблемы, решаемой программным обеспечением;
- Специальные инструкции по упаковке для кода и носителей для соответствия требованиям по безопасности, экспорту начальной загрузке и т.д.
Если приложения включены в состав SRS, следует явно указать, являются ли они частью требований.