СТ РК 1090-2002 ЕСПД. Спецификация требований к программному обеспечению

ГОСУДАРСТВЕННЫЙ СТАНДАРТ РЕСПУБЛИКИ КАЗАХСТАН

ЕДИНАЯ СИСТЕМА ПРОГРАММНОЙ ДОКУМЕНТАЦИИ.

Спецификация требований к программному обеспечению.

 

 

СТРК1090-2002

 

Издание официальное

 

Комитет по стандартизации, метрологии и сертификации

Министерства индустрии и торговли Республики Казахстан

 

(Госстандарт)

 

Астана

 

Предисловие

 

1 РАЗРАБОТАН ТОО «АИСТ»

ВНЕСЕН Техническим комитетом № 41 по стандартизации по стандартизации "Автоматизация и информатизация"

2 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ приказом Комитета по стандартизации, метрологии и сертификации Министерства индустрии и торговли Республики Казахстан 19 декабря 2002 г. № 473

3 СРОК ПЕРВОЙ ПРОВЕРКИ                                                      2007 год

ПЕРИОДИЧНОСТЬ ПРОВЕРКИ                                                 5 лет

4 ВВЕДЕН ВПЕРВЫЕ

 

 

Дата введения 2004.01.01

1 Область применения

 

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

Настоящий стандарт распространяется на спецификацию требований к программному обеспечению и относится к основополагающим общетехническим стандартам.

Настоящий стандарт устанавливает необходимое содержание и характеристики СТПО, методы, используемые для описания требований к программному обеспечению.

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

Базовые понятия для разработки СТПО приводятся в Приложении А.

 

2 Нормативные ссылки

 

В настоящем стандарте использованы ссылки на следующие нормативные документы:

СТ РК 1091-2002 Единая система программной документации. Термины и определения.

 

3 Определения

 

В настоящем стандарте применяются термины и определения в соответствии с СТРК 1091.

 

4 Сокращения

 

В настоящем стандарте использовано следующее сокращение: СТПО - спецификация требований программного обеспечения.

 

5 Требования к программному обеспечению

 

5.1 Методы, используемые для описания требований к программному обеспечению

Требования могут быть представлены при помощи:

- входных - выходных спецификаций;

- набора типичных примеров;

- модели спецификации.

5.1.1 Входные - выходные спецификации. Требуемое поведение программного продукта допустимо специфицировать при помощи последовательности входов и выходов.

5.1.1.1 Подходы. В зависимости от типа специфицируемого программного обеспечения существует три подхода:

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

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

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

5.1.1.2 Проблемы. Многие системы имеют на входе бесконечное число входных последовательностей. В этом случае разработка полной спецификации требований к программному обеспечению методом входных - выходных спецификаций становится невозможной, так как необходимо, чтобы СТПО содержала бесконечное множество входных последовательностей и требуемых выходных последовательностей.

5.1.2 Набор типичных примеров. Поведение системы должно быть описано при помощи типичных примеров диалога пользователя и системы.

5.1.3 Модели спецификации. Представление требований в форме модели дает точный и эффективный способ представления сложных требований.

Для реализации данного подхода используются следующие типы моделей:

- математические;

- функциональные;

- временные.

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

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

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

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

5.1.3.5 Если СТПО использует модель спецификации, то это означает, что модель спецификации обеспечивает эффектный и точный способ спецификации  требований к программному обеспечению.

Какой бы тип модели ни использовался, следует учитывать следующее:

- модель спецификации должна быть точно определена или в СТПО, или в документе, на который в СТПО должна быть приведена ссылка. Определение модели спецификации должно включать:

1) требуемый диапазон параметров модели:

2) значения используемых ограничений;'

3) требуемую точность результатов;

4) объем модели;

5) требуемое время выполнения;

6) правила умолчания и реакцию на ошибки; при написании¹'требований к⁴ программному обеспечению необходимо следовать определению модели спецификации.

 

5.2 Аннотация требований к программному обеспечению

 

Не все требования, связанные с программным продуктом, обладают одинаковой важностью. Каждое требование в СТПО должно быть аннотировано, чтобы сделать это различие в важности ясным и четким. Такая аннотация помогает:

- заказчикам более точно проанализировать каждое требование и прояснить неявные предположения, которые за ними стоят;

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

5.2.1 Стабильность. Один из способов аннотации требований использует понятие уровня стабильности. Требование является стабильным, если считается, что оно не будет изменено в течение ожидаемого времени использования программного обеспечения; иначе требование является непостоянным.

5.2.2 Степень важности. Другой способ аннотации связан с разделением требований на классы обязательных, желательных и необязательных.

Обязательность требований означает, что программное обеспечение не может быть принято, если эти требования не выполнены.

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

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

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

 

5.3 Проблемы, возникающие при описании требований

 

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

Основные вопросы, рассматриваемые при разработке требований:

- состав функций, т.е. что должно делать программное обеспечение;

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

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

- атрибуты-мобильность, корректность, управляемость, безопасность и т.п.;

- внешние интерфейсы- взаимодействие с людьми, аппаратным обеспечением, входящим в систему, программным и аппаратным обеспечением, не входящим в систему.

Разработчику требований не допускается указывать в СТПО требования, связанные с проектом или процессом проектирования. Он должен четко разграничивать необходимые ограничения проекта и требования к процессу проектирования.

5.3.1 Включение проекта в СТПО. Включение спецификаций проекта в СТПО необоснованно ограничивает проектирование программного обеспечения и вносит потенциально опасные требования.

СТПО должна определять, какие функции должны быть выполнены и на каких данных, чтобы получить необходимые результаты. В СТПО акцент делается на возможностях, которые должны быть предоставлены. Не специфицируется такие элементы проекта, как:

- разбиение программного обеспечения на модули;

- распределение функций по модулям;

- определение потоков информации или управления между модулями;

- выбор структур данных.

При решении данной проблемы возможны альтернативы:

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

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

только для описания требований, но не рассматривается как фактический проект.

5.3.2 Включение требований к проекту в СТПО. В СТПО рассматривается программный продукт, а не процесс его производства.

Требования к проекту представляют результат согласования заказчиком и поставщиком вопросов, связанных с созданием программного обеспечения и отражаемых в контрактных материалах (поэтому они не должны включаться в СТПО). В требованиях к проекту определяются:

- стоимость;

- планы сдачи;

- методы разработки программного обеспечения;

- гарантия качества;

- критерии аттестации и верификации;

- процедуры приемки.

Требования к проекту специфицируются в иных документах, в техническом задании или техническом проекте, а требования собственно к программному продукту - в СТПО.

 

Приложение А

(справочное)

 

Базовые понятия Для разработки спецификации требований к программному обеспечению

В Данном приложении определяются базовые понятия, необходимые для создания СТПО. Для этого рассматриваются:

- сущность СТПО;

- среда разработки, с которой связана СТПО;

- требования, которым должна удовлетворять СТПО;

- рекомендации по совместной подготовке СТПО;

- вопросы эволюции СТПО.

А.1 Спецификация требований к программному обеспечению (СТПО). СТ ПО разрабатывается для конкретного программного продукта, программы или набора программ, которые предназначены для определенны целей.

СТПО должна удовлетворять двум основным требованиям:

- в СТПО должны формулироваться необходимые положения;

- необходимые положения должны формулироваться в СТПО определенным образом. Например, программное обеспечение, разработанное на основании СТПО, в которой отсутствует формат и содержание сообщений об ошибках, или разработанное на основании неясных и неопределенных требований типа "Все сообщения об ошибках должны быть полезны", скорее всего будет неудовлетворительным. То, что "полезно" для одного лица, может оказаться вредным для другого.

Примерное содержание СТПО приведено в Приложении Б.

А.2 Окружение СТПО. Важно определить роль, которую играет СТПО в общем процессе разработки программного обеспечения.

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

- СТПО должна правильно определять все требования;

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

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

А.3 Характеристики СТПО. В предыдущих разделах описаны типы информации, которая должна содержаться в СТ ПО. Ниже определяются конкретные характеристики. СТПО должна быть:

- однозначной;

- полной;

- верифицируемой;

- непротиворечивой;

- модифицируемой;

- прослеживаемой;

- пригодной для использования на этапах эксплуатации и сопровождения.

А.3.1 Однозначность. СТПО является однозначной тогда и только тогда, когда сформулированное в ней требование имеет только одну интерпретацию.

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

А.3.1.1 Неоднозначности естественного языка. Для записи требований допускается использовать естественный язык (например, казахский, русский или английский). Разработчик СТПО, использующий естественный язык, должен тщательно анализировать формулировки требований с точки зрения однозначности.

А.3.1.2 Формальные языки спецификации требований. Одним из способов устранить неоднозначность, присущую естественным языкам, является применение для записи СТПО формального языка спецификации требований.

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

Главным недостатком использования таких языков является значительное время на их изучение.

А.3.2 Полнота. СТПО является полной, если она обладает следующими качествами:

- в СТПО включены все существенные требования, связанные с функциональностью, производительностью, ограничениями проекта, атрибутами или внешними интерфейсами;

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

- СТПО соответствует какому-либо стандарту. Если определенный раздел стандарта не может быть применен, указывается номер этого раздела и объясняется, почему он не может быть применен;

- помечены или пронумерованы все рисунки, таблицы, схемы, определения терминов и единиц измерения, и имеются ссылки на них.

А.3.2.1 Использование неопределенных понятий. Любая СТПО, использующая понятия, которые пока не определены, является неполной СТПО.

Иногда неопределенные понятия, тем не менее, необходимы. В этом случае их использование должно сопровождаться:

- описанием причин, приводящих к употреблению неопределенных понятий (например, отсутствие ответа), чтобы конкретизировать и прояснить ситуацию;

- описанием действий, которые необходимо предпринять, чтобы исключить неопределенное понятие.

Любой документ проекта, основанный на СТПО с неопределенными понятиями, должен:

- указывать версию или точный номер используемой СТПО;

- обеспечить независимость от тех частей СТПО, которые пока являются неопределенными понятиями.

А.3.3 Верифицируем ость. СТПО является верифицируемой тогда и только тогда, когда каждое сформулированное требование верифицируемо. Требование верифицируемо тогда и только тогда, когда существует конечный, эффективный по стоимости процесс, при помощи которого лицо или машина может проверить, что программный продукт удовлетворяет требованиям.

Ниже приводятся примеры неверифицуруемых и верифицируемых требований.

Примеры не верифицируемых требований:

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

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

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

Пример верифицируемого требования:

"Результат работы программы должен быть получен в течение 20 секунд после события X в 60% случаев, и в течение 30 секунд в 100% случаев". Это требование верифицируемо, поскольку оно использует конкретные понятия и измеримые величины.

Ниже приводятся рекомендации по верифицируем ости требований к ПО:

- если метод для проверки соответствия программного обеспечения определенному требованию не может быть определен, следует исключить это требование или пересмотреть его;

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

А.3.4 Непротиворечивость. СТПО является непротиворечивой тогда и только тогда, когда любой набор отдельных требований, описанных в СТПО, не содержит конфликтов. Типы вероятных конфликтов в СТПО:

- два или более требований могут описывать один и то же реальный объект, но использовать для этого различные термины. Например, программный запрос на ввод информации пользователем может быть назван "приглашение" в одном требовании и "вызов" в другом;

- указанные характеристики реального объекта могут быть противоречивы. Например:

1) формат выводимого сообщения может быть описан в одном требовании как "табличный", а в другом как "текстовый";

2) одно требование может определять цвет как "зеленый", а другое как "синий";

- могут быть временные или логические конфликты между двумя специфицированными действиями. Например:

1) одно требование может задавать операцию сложения двух чисел, а другое - операцию умножения;

2) одно требование может указывать, что событие В должно следовать за событием А, в то время как другое - что А и В должны происходить одновременно.

А.3.5 Модифицируемость. СТПО является модифицируемой, если ее структура и стиль написания допускают при необходимости простое, полное и непротиворечивое изменение в спецификации требований. Модифицируемость требует от СТПО выполнения следующих условий:

- наличия ясной и простой в использовании структуры;

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

Если избыточность необходима, то СТПО должна включать явные перекрестные ссылки, чтобы сделать СТПО модифицируемой.

А.3.6 Прослеживаемость. СТПО является прослеживаемой, если ясно происхождение каждого требования и если облегчаются ссылки на любое требование в дальнейшей разработке или подготавливаемой документации. Рекомендуется, прослеживаемость двух типов:

- прослеживаемость назад (то есть, прослеживаемость на предыдущих стадиях разработки) означает, что для каждого требования необходима явная ссылка на его источник в предыдущем документе;

- прослеживаем ость вперед (то есть прослеживаемость во всех документах, порожденных на основании СТПО) означает, что каждое требование из СТПО должно иметь для ссылок уникальное имя или номер.

Если требование в СТПО представляет собой часть другого требования или является производным от другого требования, должна быть обеспечена, прослеживаем ость и назад, и вперед. В А.3.6.1- А.3.6.3 приводятся примеры таких ситуаций.

А.3.6.1 Определение времени ответа при выполнении функций работы с базой данных на основании всех требований пользователя ко времени ответа.

А.3.6.2 Определение формата сообщения на основании определенного функционала и требований пользователя к интерфейсу.

А.3.6.3 Программный продукт, который поддерживает некоторые законодательные или административные потребности (например, расчет налога, сообщение о накладных расходах). В этом случае должны быть точно указаны законодательные или административные документы.

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

А.3,7 Пригодность на этапах эксплуатации и сопровождения. СТПО должна учитывать потребности, возникающие на этапах эксплуатации и сопровождения, включая периодическую замену программного обеспечения.

А.4 Совместная подготовка СТ ПО. Процесс разработки программного обеспечения начинается с заключения между заказчиком и поставщиком соглашения, на основании которого должно быть создано программное обеспечение. Это соглашение, в виде СТ ПО, должно подготавливаться совместно:

А.5 Эволюция СТПО. В процессе разработки продукта СТПО может развиваться. Это вызвано следующими причинами:

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

- дополнительные изменения могут потребоваться при обнаружении в СТПО пропусков, дефектов, неточностей.

При разработке СТПО рекомендуется учесть два момента процесса эволюции.

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

А.5.2 С самого начала для идентификации, анализа, слежения и сообщения; о  предлагаемых изменениях необходимо использовать формальный процесс изменений. Предлагаемые изменения в требованиях должны вноситься. В СТПО таким образом, чтобы обеспечивались возможности;

- тщательной и полной проверки последствий этих изменений;

- анализа текущего и замененного вариантов спецификаций в СТ ПО.

 

Приложение Б

(справочное)

 

Прототип спецификаций требований к программному обеспечению

В данном приложении приводятся примеры разделов СТПО. Названия этих разделов приведены ниже в форме, которая может рассматриваться как прототип любого СТПО.

Содержание

1 Вводная часть;

1.1 Цель

1.2 Назначение

1.3 Определения, сокращения, аббревиатуры,

1.4 Ссылки/

1.5 Обзор

2 Общая часть

2.1 Перспективы использования продукта,

2.2 Функции продукта

2.3 Характеристики пользователя

2.4 Общие ограничения

2.5 Предположения и зависимости

3 Конкретные требования

(Различные способы организации этого раздела приведены в Б.3.2)

Приложения

Библиографические данные

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

Б.1 Вводная часть (Раздел 1 СТПО)

Б. 1.1 Цель (Пункт 1.1 СТПО). В этом пункте излагаются цели создания конкретной СТПО, определяется аудитория, для которой предназначена СТПО.

Б.1.2 Назначение (Пункт 1.2 СТПО). В этом пункте:

- по названиям перечисляются программные продукты, которые должны быть разработаны, например, "Инструментальная СУБД", "Генератор отчетов" и т.п.;

- область применения программного продукта;

- описывается область приложений специфицируемого программного обеспечения, при этом:

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

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

Б. 1.3 Определения, сокращения, аббревиатуры (Пункт 1.3 СТПО).

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

Б. 1.4 Ссылки (Пункт 1.4 СТПО). В этом пункте необходимо:

- привести полный список всех документов, на которые есть ссылки в СТПО или в отдельных указанных документах;

- указать для каждого документа название, номер, дату и издательство;

- указать источники, из которых могут быть получены документы.

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

Б. 1.5 Обзор (Пункт 1.5 СТПО). В этом пункте необходимо:

- описать, какие части содержит СТПО;

- объяснить, как организована СТПО.

Б.2 Общая часть (Раздел 2 СТ ПО). В этом разделе должны быть описаны общие факторы, влияющие на продукт и его спецификацию. Этот раздел должен состоять из подразделов:

- перспективы использования продукта;

- функции продукта;

- характеристики пользователя;

- общие ограничения;

- предположения и зависимости.

В этом разделе не определяются конкретные требования, а приводится информация, облегчающая их понимание.

Б.2.1 Перспективы использования продукта (Пункт 2.1 СТПО). В этом пункте описываются перспективы использования продукта по отношению к другим продуктам и проектам.

Если продукт является независимым и самостоятельным, то это должно быть указано.

Если в СТПО определяется продукт, который является компонентом системы или проекта, то необходимо:

- описать функции каждого компонента всей системы или проекта;

- определить принципиальные внешние интерфейсы описываемого продукта.

В этом пункте не должны указываться конкретные проектные решения или конкретные ограничения на проектные решения.

Б.2.2 Функции продукта (Пункт 2.2 СТПО). В этом пункте приводится краткое описание всех функций, которые должно выполнять программное обеспечение. Например, в СТПО для программы бухгалтерского учета в данном пункте могут быть указаны "поддержка расчетов с заказчиками", "учет заявок заказчиков", "подготовка платежных поручений" без детальной конкретизации, что эти функции означают.

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

- изложение функций таким образом, чтобы заказчику (или другому лицу) смысл излагаемого становился понятным после первого чтения;

- блок-схема, показывающая различные функции и их взаимосвязи.

Б.2.3 Характеристики пользователя (Пункт 2.3 СТПО). В этом пункте должны быть описаны общие характеристики возможных пользователей продукта, которые должны учитываться при формулировке конкретных требований.

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

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

Б.2.4 Общие ограничения (Пункт 2.4 СТПО). В этом пункте должно быть приведено общее описание любого ограничения, влияющего на возможности разработчика системы. К ним могут относиться:

- принятые инструкции и предписания;

- ограничения аппаратного обеспечения, например, требования ко времени обработки сигналов;

- связь с другими приложениями;

- параллельное выполнение;

- функции проверки;

- функции управления;

- требования языков высокого уровня;

- протоколы обмена сигналами.

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

Б.3 Конкретные требования (Раздел 3 СТПО). В этом разделе должна быть детально определена вся информация, необходимая разработчику для проектирования. Это самая большая и наиболее важная часть СТПО.

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

Должны быть указаны при помощи перекрестных ссылок на соответствующие обсуждения во Введении, Общем описании, Приложениях происхождение и взаимосвязи каждого требования.

Один из способов классификации конкретных требований являются:

а) функциональные требования;

б) требования к производительности;

в) ограничения проекта;

г) атрибуты;

д) требования к внешним интерфейсам.

При описании требований должны учитываться следующие моменты:

- конкретные требования должны быть представлены в логичной и удобной для чтения форме;

- каждое требование должно быть сформулировано таким образом, чтобы его выполнение можно было объективно проверить при помощи указанного метода.

Б.3.1 Необходимая информация, включаемая в конкретные требования.

Б.3.1.1 Функциональные требования. В этом пункте СТПО должны быть специфицированы правила преобразования входной информации в выходную. В нем описываются базисные действия, которые должно реализовывать программное обеспечение.

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

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

- входная информация. Этот подпункт должен содержать:

1) детальное описание всех возможных входных данных, включая: источники данных, значения, единицы измерения, временные параметры, диапазоны допустимых входных данных для анализа правильности и устойчивости;

2) детальное описание требований к действиям оператора должно включать названия действий оператора, описания действий, описание операторской консоли или рабочего места оператора, например, это, могут быть такие действия оператора, как выравнивание листа бумаги при контроле печати;

3) ссылки на спецификацию интерфейсов или документы по управлению интерфейсами;

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

1) способы контроля правильности входных данных;

2) точные последовательности операций для временной обработки событий;

3) реакции на аварийные ситуации;

4) требования к прерываемым или незавершенным операциям;

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

6) способы контроля правильности выходных данных;

- выходная информация. Этот подпункт должен содержать:

1) детальное описание всех возможных выходных данных, включая:

- назначение данных, значения, единицы измерения, временные параметры, диапазоны допустимых выходных данных для анализа правильности и устойчивости, обработка неправильных значений, сообщения об ошибках;

2) ссылки на спецификацию интерфейсов или документы по управлению интерфейсами.

Б.3.1.2 Требования к производительности. В этом пункте должны быть специфицированы статические и динамические количественные характеристики программного обеспечения или процесса взаимодействия человека и программного обеспечения.

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

Статические количественные требования могут быть определены в отдельном разделе "Возможности".

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

Все эти требования должны быть сформулированы в измеримых терминах, например, "95% транзакций должны быть обработаны менее чем за 1 секунду", а не в форме "оператор не должен ожидать завершения обработки транзакций".

Количественные ограничения, относящиеся к какой-либо одной конкретной функции, указываются в подпункте "Обработка" этой функции.

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

Б.3.1.3.1 Соответствие стандартам. В этом пункте должны быть определены ограничения, которые являются следствием применяемых стандартов или предписаний.

Б.3.1.3.2 Ограничения на аппаратное обеспечение. В этом пункте должны быть определены требования, связанные с функционированием программного обеспечения в различном аппаратном окружении.

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

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

Б.3.1.5 Требования к внешним интерфейсам.

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

1) требуемые форматы вывода на экран;

2) вид страницы и содержание каждого сообщения или пункта меню;

3) относительное время ввода и вывода;

4) управление программируемыми функциональными клавишами;

Б.3.1.5.2 Интерфейс с аппаратным обеспечением. В этом пункте должны быть специфицированы все логические характеристики каждого интерфейса между программным продуктом и аппаратным компонентом системы. Указываются также, какие типы устройств должны поддерживаться, и каким образом, и необходимые протоколы.

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

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

Для каждого интерфейса:

- должно объясняться назначение системы, с которой связан специфицируемый программный продукт;

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

Б.3.1.5.4 Коммуникационные интерфейсы. В этом пункте должны быть специфицированы различные коммуникационные интерфейсы типа протоколов локальных сетей и т.п.

Б.3.1.6 Другие требования. Определенные требования, в зависимости от типа программного обеспечения, интересов пользователя и т.п., могут быть вынесены в отдельную категорию.

Б.3.1.6.1 База данных. Могут быть описаны требования к любой базе данных, входящей в качестве составной части в программный продукт. Указываются:

- информация, определенная в Б.3.1.1;

- частота использования;

- возможности доступа;

- элементы данных и дескрипторы файлов;

- взаимосвязи элементов данных записей и файлов;

- статическая и динамическая организация;

- требования по хранению данных.

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

Б.3.1.6.2 Функционирование. В этом пункте могут быть специфицированы режимы функционирования. Можно эту спецификацию приводить в пункте "Интерфейс с пользователем".

Б.3.1.6.3 Требования по адаптации к месторасположению. В этом пункте могут быть:

- определены требования к данным или способам инициализации, зависящим от месторасположения, условий, режима эксплуатации, например, параметры энергетических сетей, параметры безопасной эксплуатации и т.п.;

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

Б.3.2 Организация раздела «Конкретные требования». Раздел «Конкретные требования» является наиболее важной частью СТПО.

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

Цель такой иерархической организации - облегчение восприятия СТПО, а не иерархическая спецификация проекта программного обеспечения.

Организация раздела 3 "Конкретные требования" в СТПО зависит от предметной области и природы специфицируемого программного продукта, В Приложениях В, Г, Д, Е приведены четыре возможных типа организации данного раздела.

В Прототипе 1 (Приложение В) специфицированы все функциональные требования, затем специфицированы четыре типа требований к интерфейсам, после чего остальные требования.

В Прототипе 2 (Приложение Г) четыре типа требований к интерфейсам связаны с каждым из функциональных требований, после чего специфицированы остальные требования.

В Прототипе 3 (Приложение Д) для каждого функционального требования определены все необходимые элементы. По этой же схеме далее определены требования к каждому типу внешних интерфейсов.

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

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

Б.4 Дополнительная информация. К дополнительной информации относятся приложения и библиографические данные.

Приложения могут включать:

- примеры входных - выходных форматов, описания расчетов стоимости, результаты ознакомления пользователей;

- дополнительную информацию, облегчающую восприятие СТПО;

- описание задач, для решения которых предназначено программное обеспечение;

- исторические справки, предпосылки, эксперименты, эксплуатационные характеристики из области, в которой ведется разработка;

- список перекрестных ссылок на неполные спецификации требований, которые должны быть специфицированы на определенных этапах разработки, с указанием этих этапов;

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

 

Приложение В

(рекомендуемое)

 

Прототип 1 для Раздела 3 СТПО

 

3 Конкретные требования,

3.1 Функциональные требования

3.1.1 Функциональное требование 1

3.1.1.1 Введение

ЗА.1.2 Входная информация

3.1.1.3 Обработка

3.1.1.4 Выходная информация

3.1.2 Функциональное требование 2

3.1 п Функциональное требование п

3.2 Требования к внешним интерфейсам

3.2.1 Интерфейсы с пользователем

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

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

3.2.4 Коммуникационные интерфейсы

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

3.4 Ограничения проекта

3.4.1 Соответствие стандартам

3.4.2 Ограничения на аппаратное обеспечение

3.5 Атрибуты

3.5.1 Безопасность

3.5.2 Управляемость

3.6 Другие требования

3.6.1 База данных

3.6.2 Функционирование

3.6.3 Требования по адаптации к местоположению

 

Приложение Г

(рекомендуемое)

 

Прототип 2 для Раздела 3 СТПО

 

3 Конкретные требования.

3.1 Функциональные требования

3.1.1 Функциональное требование 1

3.1.1.1 Спецификация

3.1.1.1.1 Введение

3.1.1.1.2 Входная информация

3.1.1.1.3 Обработка

3. .1.1.4 Выходная информация

3. .1.2 Внешние интерфейсы

3. .1.2.1 Интерфейсы с пользователем

3. .1.2.2 Интерфейсы с аппаратным обеспечением

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

3.1.1.2.4 Коммуникационные интерфейсы

3.1.2 Функциональное требование 2

3.1 п Функциональное требование п

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

3.3 Ограничения проекта

3.4 Атрибуты

3.4.1 Безопасность

3.4.2 Управляемость

3.5 Другие требования

3.5.1 База данных

3.5.2 Функционирование

3.5.3 Требования по адаптации к местоположению

 

Приложение Д

(рекомендуемое)

 

Прототип 3 для Раздела 3 СТ ПО

 

3 Конкретные требования.

3.1 Функциональные требования -

3.1.1 Функциональное требование 1

3.1.1.1 Введение

3.1.1.2 Входная информация

3.1.1.3 Обработка

3.1.1.4 Выходная информация

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

3.1.1.6 Ограничения проекта

3.1.1.6.1 Соответствие стандартам

3.1.1.6.2 Ограничения на аппаратное обеспечение

3.1.1.7 Атрибуты

3.1.1.7.1 Безопасность

3.1.1.7.2 Управляемость

3.1.1.8 Другие требования

3.1.1.8.1 База данных

3.1.1.8.2 Функционирование:

3.1.1.8.3 Требования по адаптации к местоположению

3.1.2 Функциональное требование 2

3.1 п Функциональное требование п

3.2 Требования к внешним интерфейсам

3.2.1 Интерфейсы с пользователем

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

3.2.1.2 Ограничения проекта

3.2.1.2.1 Соответствие стандартам

3.2.1.2.2 Ограничения, на аппаратное обеспечение

3.2.1.3 Атрибуты

3.2.1.3.1 Безопасность

3.2.1.3.2 Управляемость

3.2.1.4 Другие требования

 

 

Приложение Е

(рекомендуемое)

 

Прототип 4 для Раздела 3 СТПО

 

3. Конкретные требования.

3.1.1 Функциональное требование 1

3.1.1 Введение

3.1.2 Входная информация

3.1.3 Обработка

3.1.4 Выходная информация

3.1.5 Требования к внешним интерфейсам

3.1.5.1 Интерфейсы с пользователем

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

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

3.1.5.4 Коммуникационные интерфейсы

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

3.1.7 Ограничения проекта

3.1.8 Атрибуты

3.1.8.1 Безопасность

3.1.8.2 Управляемость

3.1.9 Другие требования

3.1.9.1 База данных

3.1.9.2 Функционирование

3.1.9.3 Требования по адаптации к местоположению

3.2 Функциональное требование 2

3.п Функциональное требование п

 

 

Содержание

 

1      Область применения

2      Нормативные ссылки

3      Определения

4      Сокращения

5      Требования к программному обеспечению

Приложение А

Приложение Б

Приложение В

Приложение Г

Приложение Д

Приложение В