Требования-возможности

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

• получение изображения;

• обработка изображения;

• вывод обработанного изображения;

• ручная корректировка некачественных участков обработанного изображения.

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

Требования-ограничения

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

• коммуникационные интерфейсы;

• интерфейсы с аппаратными компонентами;

• интерфейсы с программными компонентами;

• пользовательские интерфейсы (интерфейсы пользователь-компьютер).

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

• адаптивность;

• готовность;

• переносимость;

• безопасность;

• надежность;

• соответствие стандартам.

4. Специфицирование требований пользователей согласно ieee-Std-830-1998

Согласно стандарту IEEE-Std-830-1998 типовая структура СТП является следующей:

1. Введение

1.1. Цель создания продукта.

1.2. Область применения продукта.

1.3. Определения и сокращения.

1.4. Ссылки.

1.5. Сведения о структуре спецификации.

2. Общие сведения

2.1. Ожидаемые результаты.

2.2. Функциональность программной системы.

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

2.4. Ограничения.

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

2.6. Разделение требований.

3. Специальные требования

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

3.2. Реализуемые программной системой функции.

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

3.4. Требования к логическим моделям данных.

3.5. Проектные ограничения.

3.6. Атрибуты программной системы.

3.7. Требования к организации специальных требований.

Ниже приводится подробное описание содержания разделов приведенной структуры.

1. Введение

1.1. Цель создания продукта.

• определение цели разработки продукта;

• предполагаемые пользователи продукта.

1.2. Область применения продукта.

• присвоение наименования продукта (например, «генератор отчетов»);

• описание того, что программная система будет делать и, если это возможно, описание того, что она делать не будет;

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

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

1.3. Определения и сокращения.

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

1.4. Ссылки.

В этом разделе:

• приводится список всех документов, на которые где-либо ссылаются в СТП;

• каждый из упоминаемых документов представлен названием; номером отчета (если таковой имеется); наименованием выпустившей его организации и датой издания;

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

1.5. Сведения о структуре спецификации.

В этом разделе:

• приводится описание содержания последующих разделов документа;

• приводится описание организации спецификации требований к программному продукту.

2. Общие сведения

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

2.1. Ожидаемые результаты

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

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

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

• Интерфейсы пользователей. Предполагает наличие следующих описаний:

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

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

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

– Интерфейсы с внешними программами. В этом разделе приводится описание способов взаимодействия создаваемого программного продукта с «коробочными» программными продуктами (например, СУБД; операционными системами; пакетами, реализующими математические методы), а также описания интерфейсов с другими, «некоробочными» прикладными программными системами. Каждая из внешних программных систем должны представляться следующим образом:

– полное название системы;

– сокращенное название системы;

– номер версии системы;

– физическое местоположение системы.

Каждому из интерфейсов должна соответствовать следующая сопроводительная информации:

– обоснование необходимости организации взаимодействия вновь создаваемого программного продукта с существующими программными системами;

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

– Коммуникационные интерфейсы (протоколы). В этом разделе приводятся сведения о коммуникационных интерфейсах, таких, например, как протоколы сетевого обмена.

– Память. В этом разделе приводятся сведения о всех ограничениях, связанных с внешней и внутренней памятью.

– Операции. В этом разделе приводятся сведения о типовых и специальных операциях, таких как:

– различные режимы выполнения операции (имеются в виду режимы, инициируемые пользователями);

– длительность операции в интерактивном и автоматическом режимах;

– операции, связанные с реализацией поддерживающих функций;

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

– Адаптация программного продукта к вычислительной установке. В этом разделе:

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

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

2.2. Функциональность программной системы.

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

– обеспечивалось правильное понимание содержания требования Заказчиком и любым другим субъектом, впервые читающим документ;

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

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

В этом разделе описываются основные характеристики предполагаемых пользователей программного продукта. К таким характеристикам относятся образовательный уровень; опыт работы. В этом разделе не следует приводить специальных требований, обусловленных спецификой программного продукта. Эти сведения следует привести в разделе «Специальные требования» (см. ниже).

2.4. Ограничения.

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

• причины политического характера;

• ограничения, обусловленные аппаратной частью (например, характеристики сигнала);

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

• параллельные операции;

• результаты аудитов;

• контрольные функции;

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

• протоколы взаимодействия;

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

• критичность приложений;

• соображения целостности и безопасности.

2.5. Предположения и влияния.

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

2.6. Разделение требований.

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

3. Специальные требования

Требования, представленные в этом разделе, должны быть детализированы до такой степени, которая позволяет:

• проектировщикам – спроектировать систему, удовлетворяющую этим требованиям;

• тестировщикам – спроектировать тесты, подтверждающие соответствие системы требованиям.

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

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

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

– каждое требование должно иметь уникальный идентификатор.

– требования должны быть читаемыми, иметь понятное содержание.

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

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

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

1. Имя компонента программной системы.

2. Назначение компонента программной системы.

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

4. Допустимые диапазон, точность и/или допуски входных и выходных данных.

5. Единицы измерений параметров.

6. Соотношения по времени возникновения данных.

7. Взаимоотношения с другими входами и выходами.

8. Форматы/организация экранов.

9. Форматы/организация окон.

10. Форматы данных.

11. Форматы команд.

12. Сообщения о завершении обмена.

3.2. Реализуемые программной системой функции.

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

1. Контроль входных данных.

2. Выполнение определенной последовательности действий.

3. Реакцию на нештатные ситуации, обусловленные свойствами данных; состоянием каналов передачи данных; ошибками оператора и действиями по восстановлению работоспособности программного продукта.

4. Описание взаимосвязи входных данных и выходных результатов, включая:

(*). Описание входных/выходных последовательностей.

(*). Описание правил преобразования входных данных в выходные.

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

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

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

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

2. Ограничение на число одновременно поддерживаемых пользователей.

3. Ограничения на объем и тип обрабатываемой информации.

Примерами измеримых динамических характеристик являются:

1. Число обращений и решаемых задач.

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

Например, формулировка «...95% транзакций должны обрабатываться за время, не превышающее 1 сек...» более предпочтительна, нежели «...оператор не должен ожидать завершения транзакции...».

Замечание. Числовые характеристики ограничений, накладываемых на специальные функции, относятся лишь к отдельным компонентам в общей структуре конструкции, именуемой «требования».

3.4. Требования к логическим моделям данных.

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

1. Типы данных, используемых разными функциями.

2. Частота использования разных данных.

3. Сущности и связи между ними.

4. Ограничения целостности.

5. Требования к сохранности данных.

3.5. Проектные ограничения.

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

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

– форма представления отчетов;

– выбор имен данных;

– процедуры докладов о ходе реализации процесса;

– порядок отслеживания результатов проверки отчетности.

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

3.6. Атрибуты программной системы.

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

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

2. Готовность. Контроль значения этого атрибута возможен лишь если определены факторы, определяющие заявленный уровень готовности: контрольные точки; восстанавливаемость; рестарт.

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

(*) использования специальных криптографических технологий;

(*) ведения специальной регистрации, либо истории последовательностей входных данных;

(*) назначения определенных функций различным модулям;

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

(*) проверки целостности критических данных.

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

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

(*) доля программных компонентов, код которых привязан к определенной платформе;

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

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

(*) использование какой-либо особенной операционной системы

3.7. Организация специальных требований.

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

1. Организация требований при разных режимах работы системы. Некоторые системы обладают разной функциональностью при различных режимах работы. Например, контролирующая система реализует различные наборы функций при разных режимах работы: тренировочном; штатном, и в случае возникновения опасности. В случае, если требования к программной системе зависят от режима ее работы, рекомендуется придерживаться одной из типовых структур представления специальных требований, описанных ниже. Критерием выбора структуры является зависимость /независимость интерфейсов и производительности системы от режима её работы.

Вариант 1. Типовая структура представления специальных требований.

3. Специальные требования

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

3.1.1. Интерфейсы пользователя

3.1.2. Интерфейсы с аппаратными компонентами

3.1.3. Интерфейсы с прикладными программными системами.

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

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

3.2.1. Режим 1

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

.

.

.

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

3.2.2. Режим 2

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

.

.

.

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

3.2.2. Режим k

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

.

.

.

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

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

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

3.5. Атрибуты программной системы

3.6. Иные требования

Вариант 2. Типовая структура представления специальных требований

3. Специальные требования

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

3.1.1. Режим 1

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

(*) Интерфейсы пользователя

(*) Интерфейсы с аппаратными компонентами

(*) Интерфейсы с прикладными программными системами.

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

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

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

.

.

.

(*) Функциональное требование n.

3.1.1.3. Производительность

3.1.2. Режим 2

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

(*) Интерфейсы пользователя

(*) Интерфейсы с аппаратными компонентами

(*) Интерфейсы с прикладными программными системами.

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

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

(*) функциональное требование 1

.

.

.

(*) функциональное требование m.

3.1.2.3. Производительность

.

.

.

3.1.k. Режим k

3.1.k.1. Требования к внешним интерфейсам.

(*) Интерфейсы пользователя

(*) Интерфейсы с аппаратными компонентами

(*) Интерфейсы с прикладными программными системами.

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

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

(*) функциональное требование 1

.

.

.

(*) функциональное требование m.

3.1.k.3. Производительность

3.2. Ограничения на проектные решения

3.3. Атрибуты программной системы

3.4. Иные требования

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

3. Специальные требования

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

3.1.1. Интерфейсы пользователя

3.1.2. Интерфейсы с аппаратными компонентами

3.1.3. Интерфейсы с прикладными программными системами.

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

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

3.2.1. Пользователь класса 1

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

.

.

.

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

3.2.2. Пользователь класса 2

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

.

.

.

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

3.2.k. Пользователь класса k

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

.

.

.

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

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

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

3.5. Атрибуты программной системы

3.6. Иные требования

3) Объекты – это сущности реального мира, которым ставится в соответствие аналог в программной системе. Например, система наблюдения за пациентами включает в себя такие объекты как пациенты; сенсоры; сиделки; помещения; врачи; лекарства и т.д. Каждому объекту ставится в соответствие множество атрибутов и реализуемых им функций. Эти функции иначе называются сервисами/ методами/процессами. В случае, если в качестве подхода к реализации специальных требований выбирается объектно-ориентированный подход, для описания специальных требований рекомендуется использовать структуру, представленную ниже.

3. Специальные требования

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

3.1.1. Интерфейсы пользователя

3.1.2. Интерфейсы с аппаратными компонентами

3.1.3. Интерфейсы с прикладными программными системами.

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

3.2. Классы/объекты

3.2.1. Класс/объект1

3.2.1.1. Атрибуты (прямые либо наследуемые)

(*) атрибут 1

.

.

.

(*) атрибут n

3.2.1.2. Функции (сервисы/методы прямые и наследуемые)

(*) функциональное требование 1.1

.

.

.

(*) функциональное требование 1.m

3.2.1.3. Сообщения (получаемые или отправляемые)

3.2.2. Класс/объект 2

.

.

.

3.2.р. Класс/объект р

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

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

3.5. Атрибуты программной системы

3.6. Иные требования

4) Характерный признак является сервисом, поставляющим определенный выходной результат. Для реализации сервиса на входе компоненты должна возникнуть определенная комбинация входных воздействий. Например, в случае телекоммуникационной системы к характерным признакам относятся: локальные вызовы; звонки в другие регионы; конференции. Каждому характерному признаку ставится в соответствие пара «воздействие-отклик». Если при описании специальных требований в качестве основы выбраны характерные признаки, рекомендуется придерживаться нижеприведенной типовой структуры.

3. Специальные требования

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

3.1.1. Интерфейсы пользователя

3.1.2. Интерфейсы с аппаратными компонентами

3.1.3. Интерфейсы с прикладными программными системами.

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

3.2. Характерные признаки системы

3.2.1. Характерный признак 1

3.2.1.1. Введение/назначение признаки

3.2.1.2. Последовательность «воздействие-отклик»

3.2.1.3. Ассоциированные требования к функциям

(*) функциональное требование 1

.

.

.

(*) функциональное требование n

3.2.2. Характерный признак 2

3.2.2.1. Введение/назначение признаки

3.2.2.2. Последовательность «воздействие-отклик»

3.2.2.3. Ассоциированные требования к функциям

(*) функциональное требование 1

.

.

.

(*) функциональное требование m

.

.

.

3.2.m. Характерный признак m

3.2.m.1. Введение/назначение признаки

3.2.m.2. Последовательность «воздействие-отклик»

3.2.m.3. Ассоциированные требования к функциям

(*) функциональное требование 1

.

.

.

(*) функциональное требование r

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

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

3.5. Атрибуты программной системы

3.6. Иные требования

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

3. Специальные требования

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

3.1.1. Интерфейсы пользователя

3.1.2. Интерфейсы с аппаратными компонентами

3.1.3. Интерфейсы с прикладными программными системами.

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

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

3.2.1. Воздействие 1

(*) функциональное требование 1

.

.

.

(*) функциональное требование n

3.2.2. Воздействие 2

(*) функциональное требование 1

.

.

.

(*) функциональное требование m

.

.

.

3.2.m. Воздействие m

(*) функциональное требование 1

.

.

.

(*) функциональное требование r

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

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

3.5. Атрибуты программной системы

3.6. Иные требования

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

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

3. Специальные требования

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

3.1.1. Интерфейсы пользователя

3.1.2. Интерфейсы с аппаратными компонентами

3.1.3. Интерфейсы с прикладными программными системами.

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

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

3.2.1. потоки информации

3.2.1.1. DFD 1

(*) сущности данных

(*) релевантные процессы

(*) топология

3.2.1.2. DFD 2

(*) сущности данных

(*) релевантные процессы

(*) топология

.

.

.

3.2.1.n. DFD n

(*) сущности данных

(*) релевантные процессы

(*) топология

3.2.2. Описание процессов

3.2.2.1. Процесс 1

(*) сущности входных данных

(*) алгоритм (формула) процесса

(*) сущности выходных данных

3.2.2.2. Процесс 2

(*) сущности входных данных

(*) алгоритм (формула) процесса

(*) сущности выходных данных

.

.

.

3.2.2.n. Процесс n

(*) сущности входных данных

(*) алгоритм (формула) процесса

(*) сущности выходных данных

3.2.3. Описание логической структуры данных

3.2.3.1. Структура 1

(*) тип записи

(*) поля данных записи

3.2.3.2. Структура 2

(*) тип записи

(*) поля данных записи

.

.

.

3.2.3.n. Структура n

(*) тип записи

(*) поля данных записи

3.2.4. Словарь данных

3.2.4.1. Элемент данных 1

(*) имя

(*) представление

(*) единицы измерения /формат

(*) точность /погрешность

(*) диапазон изменения

3.2.4.1. Элемент данных 2

(*) имя

(*) представление

(*) единицы измерения /формат

(*) точность /погрешность

(*) диапазон изменения

.

.

.

3.2.4.n. Элемент данных n

(*) имя

(*) представление

(*) единицы измерения /формат

(*) точность /погрешность

(*) диапазон изменения

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

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

3.5. Атрибуты программной системы

3.6. Иные требования

Возможно, что при подготовке СТП, окажется целесообразным одновременное использование комбинации из описанных выше способов представления специальных требований. В качестве примера ниже приведена структура, в основе которой лежит совместное использование подходов, основанных на выделении классов пользователей и характерных признаков (свойств). Если какие-либо дополнительные требования не могут быть описаны за счет комбинации упомянутых подходов, их следует выделить в отдельный подраздел раздела «Специальные требования».

Пример совместное использование подходов, основанных на выделении классов пользователей и характерных признаков (свойств).

3. Специальные требования

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

3.1.1. Интерфейсы пользователя

3.1.2. Интерфейсы с аппаратными компонентами

3.1.3. Интерфейсы с прикладными программными системами.

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

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

3.2.1. Пользователь класса 1

3.2.1.1. Характерные признаки (свойства) 1.1

(*) введение/назначение характерного признака

(*) последовательность «воздействие – отклик»

(*) ассоциированные требования к функциям

3.2.1.2. Характерные признаки (свойства) 1.2

(*) введение/назначение характерного признака

(*) последовательность «воздействие – отклик»

(*) ассоциированные требования к функциям

.

.

.

3.2.1.n. Характерные признаки (свойства) 1.n

(*) введение/назначение характерного признака

(*) последовательность «воздействие – отклик»

(*) ассоциированные требования к функциям

3.2.2. Пользователь класса 2

3.2.2.1. Характерные признаки (свойства) 2.1

(*) введение/назначение характерного признака

(*) последовательность «воздействие – отклик»

(*) ассоциированные требования к функциям

3.2.2.2. Характерные признаки (свойства) 2.2

(*) введение/назначение характерного признака

(*) последовательность «воздействие – отклик»

(*) ассоциированные требования к функциям

.

.

.

3.2.2.n. Характерные признаки (свойства) 2.n

(*) введение/назначение характерного признака

(*) последовательность «воздействие – отклик»

(*) ассоциированные требования к функциям

.

.

.

3.2.r. Пользователь класса r

3.2.r.1. Характерные признаки (свойства) r.1

(*) введение/назначение характерного признака

(*) последовательность «воздействие – отклик»

(*) ассоциированные требования к функциям

3.2.r.2. Характерные признаки (свойства) r.2

(*) введение/назначение характерного признака

(*) последовательность «воздействие – отклик»

(*) ассоциированные требования к функциям

.

.

.

3.2.r.n. Характерные признаки (свойства) r.n

(*) введение/назначение характерного признака

(*) последовательность «воздействие – отклик»

(*) ассоциированные требования к функциям

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

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

3.5. Атрибуты программной системы

3.6. Иные требования

Существует множество нотаций, методов, инструментальных средств, способствующих документированию требований. В разных случаях бывает полезным использовать разные подходы. Например, в случае использования подхода «режим функционирования системы» может оказаться полезной диаграммы состояний. В случае использования подхода «объекты», могут оказаться полезными результаты объектно-ориентированного моделирования. В случае использования подхода «характерные признаки (свойства)» может оказаться полезным подход, основанный на формировании совокупности «воздействия – отклики». В случае использования подхода «иерархия функций» могут оказаться полезными DFD – диаграммы и словари данных. Во всех рассмотренных выше вариантах специфицирования требований раздел, именуемый «функциональные требования», может быть описан на естественном языке; посредством псевдокода; на каком-либо специальном языке описания систем; посредством конструкции «Введение -> Вход -> Преобразование -> Выход».