Тема 15. Функциональные спецификации

План лекции

1. Понятие функциональной спецификации

2. Стандарт IEEE 830

 

Понятие функциональной спецификации

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

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

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

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

 

Стандарт IEEE 830

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

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

В стандарте IEEE 830 содержатся рекомендации к структуре и методам описания программных требований. Рекомендуемая структураимеет следующий вид:

1. Введение

1.1. Цели

1.2. Соглашения о терминах

1.3. Предполагаемая аудитория и последовательность восприятия

1.4. Масштаб проекта

1.5. Ссылки на источники

2. Общее описание

2.1. Видение продукта

2.2. Функциональность продукта

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

2.4. Среда функционирования продукта (ОС)

2.5. Рамки, ограничения, правила и стандарты

2.6. Документация для пользователей

2.7. Допущения и зависимости

3. Функциональность системы

3.1. Функциональный блок N (блоков может быть несколько)

3.1.1. Описание и приоритет

3.1.2. Причинно-следственные связи, алгоритмы – движение процессов, Workflows

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

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

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

4.2. Программные интерфейсы

4.3. Интерфейсы оборудования

4.4. Интерфейсы связи и коммуникации

5. Нефункциональные требования

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

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

5.3. Критерии качества программного обеспечения

5.4. Требования к безопасности системы

6. Прочие требования

Приложение А. Глоссарий

Приложение Б. Модели процессов предметной области и другие диаграммы

Приложение В. Список ключевых задач

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

При использовании принципов структурного проектированияв подразд. 3 следует приводить диаграммы IDEF0, DFD, IDEF3 видаTO-BE, если они разрабатывались для отдельных функциональныхблоков. Если такие диаграммы отсутствуют, то подраздел содержиттолько вербальное изложение требований. В Приложении Б приводятся те же диаграммы, созданные для системы в целом.

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