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

1.

СПЕЦИФИКАЦИЯ
ТРЕБОВАНИЙ К
ПРОГРАММНОМУ
ОБЕСПЕЧЕНИЮ
Лекция 19

2.

Что такое спецификация
Стандарты спецификации
План
Зачем и для кого создается
Советы и приемы
Шаблон спецификации из Вигерса

3.

ЧТО ТАКОЕ СПЕЦИФИКАЦИЯ
Software Requirements Specification – документ,
содержащий полное описание поведения
разрабатываемой системы, включающее
функциональные и нефункциональные
требования.

4.

КОГДА ПИШЕТСЯ SRS?
SRS начинает писаться
практически в самом начале
проекта, когда появляются
первые требования.
Далее на протяжении всего ЖЦ
проекта по мере
извлечения и уточнения
требований SRS обновляется
Законченная SRS является
венцом стадии анализа
на проекте, т.е. финальным
артефактом аналитика
(но это не означает, что аналитик
завершает свою
работу)

5.

НА ОСНОВАНИИ ЧЕГО ПИШЕТСЯ
SRS?
Протоколы
встреч
Vision &
Scope
Диаграммы
SRS
Таблицы
Эскизы UI

6.

СТАНДАРТЫ
ГОСТ-34 – шаблон на техническое задание
(ТЗ), частное техническое задание (ЧТЗ)
IEEE 830-1998 – IEEE Recommended Practice for
Software Requirements Specifications
Свой / командный / корпоративный гибкий
шаблон

7.

ЗАКАЗЧИК
ДЛЯ КОГО
ПИШЕТСЯ
SRS?
РАЗРАБОТЧИКИ
ТЕСТИРОВЩИКИ
АНАЛИТИКИ
РУКОВОДИТЕЛЬ ПРОЕКТА

8.

Использование подходящего шаблона
СОВЕТЫ И
ПРИЕМЫ
ХОРОШЕЙ
СПЕЦИФИКАЦИИ
Использование единой терминологии (создание
словаря терминов)
Использование ссылок для облегчения навигации
Графическое представление информации (не
всегда!)

9.

ШАБЛОН SRS

10.

COVER
PAGE
1. Название проекта
2. Название документа
3. Текущая версия
4. Дата последнего изменения

11.

REVISION
HISTORY
1. Список модификаций с момента создания
2. Даты модификаций
3. Авторы модификаций
4. Причина / источник модификаций

12.

ВВЕДЕНИЕ
1. Назначение документа.
2. Поддерживаемые соглашения.
3. Предполагаемая аудитория
4. Границы проекта.
5. Ссылки.

13.

1. Общий взгляд на продукт
ОБЩЕЕ
ОПИСАНИЕ
2. Классы и характеристики пользователей
3. Операционная среда
4. Ограничение дизайна и реализации
5. Предположения и зависимости

14.

2. Use Cases
2.1. Actors
2.2. Use Cases Catalog
2.2.1 UC01 – <Use Case Name>
ШАБЛОН
SRS
3. Common Requirements
3.1. Business Rules
3.2. Functional Requirements Catalog
4. <Feature Name>
4.1. User Interface Overview
4.1.1. <Page/Screen Name>
...
4.2. <Functionality Name>

15.

Пользовательские интерфейсы – общие
требования к экранным формам
ТРЕБОВАНИЯ К
ВНЕШНИМ
ИНТЕРФЕЙСАМ
Интерфейсы ПО – описании интеграции с другими
системами и с частями разрабатываемой системы
Интерфейсы оборудования – не всегда
существуют
Коммуникационные интерфейсы – все прочие
внешние взаимодействия системы

16.

ШАБЛОН
SRS
6. Non-functional Requirements
6.1. Performance Requirements
6.2. Security Requirements
…

17.

Требования по интернационализации и
локализации обеспечивают возможность
использовать продукт в других странах
ТРЕБОВАНИЯ К
ЛОКАЛИЗАЦИИ
Примеры:
языки
валюты
измерение/отображение времени
и т.д. все что отличается для разных стран

18.

Словарь терминов
ПРИЛОЖЕНИЯ
Диаграммы (или в тексте спецификации)
Громоздкие таблицы/расчеты

19.

1. Сделайте себе шаблон, отформатированный по
всем правилам, и используйте его.
ОБЩИЕ
СОВЕТЫ
2. Внимательно следите за орфографией и
пунктуацией. Spell checker a must!
3. Для команды разработки выделяйте визуально
изменения в последней версии.
4. Используйте TBD, если какая-либо секция явно
не завершена, выделяйте цветом
5. Используйте гиперссылки. Везде, где возможно.

20.

ОБЩИЕ
СОВЕТЫ
6. Какие бы сокращения и названия вы ни
использовали (Система, Заказчик, Исполнитель,
прочие), пишите их однообразно (либо все со
строчной, либо все с прописной буквы).
7. Тире ≠ дефис
8. Язык богат синонимами, но техническая
документация – не место для демонстрации его
разнообразия.
9. Стройте предложения в активном залоге.

21.

ПРИЛОЖЕНИЯ

22.

SRS IEEE

23.

Шаблон SRS

24.

ТЗ ПО ГОСТ

25.

ГОСТ 34
В серии 34, существует всего 3 основных стандарта по документированию:
ГОСТ 34.602-89 Техническое задание на создание автоматизированной системы
ГОСТ 34.201-89 Виды, комплектность и обозначения документов при создании
автоматизированных систем
Это базовый документ, в котором приводится полный перечень документации ГОСТ 34,
рекомендации по кодированию документов, к каким стадиям проекта относятся документы
(стадии описываются в ГОСТ 34.601-90), а также как их можно объединить между собой.
РД 50-34.698-90 Автоматизированные системы. Требования к содержанию документов
Объемистый стандарт, с различной степенью детальности описывающий содержание проектных
документов. В качестве индекса используется упомянутый выше ГОСТ 34.201-89.

26.

Структура ТЗ в соответствие
с ГОСТ 34.602-89
Общие сведения - в этом разделе, помимо юридических реквизитов сторон и прочей деловой информации ГОСТ рекомендует
указать источники и порядок финансирования работ.
Назначение и цели создания (развития) системы - здесь необходимо указать показатели объекта автоматизации, которые должны
быть достигнуты и критерии оценки достижения этих показателей. Фиксируются высокоуровневые бизнес-требования и
формулируются критерии их достижения.
Характеристика объектов автоматизации - достаточно важный раздел. Его основные "разрезы" - организационная структура,
структура управления, структура расположения предприятия и его филиалов.
Требования к системе
Раздел "Состав и содержание работ по созданию системы» описывает процесс создания системы, включая выбор методологии,
определяющий содержание стадий, этапов и фаз и его конкретизацию для проекта (количество этапов и итераций, их основное
содержание).
Порядок контроля и приемки системы - Он распределяет роли Заказчика и Разработчика в подготовке системы к испытаниям и
проведению испытаний. Здесь уместно оговорить правила проведения испытаний, сформулировать основные тестовые сценарии и
критерии приемки.
Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие, оговаривают
порядок проведения реинжиниринга предприятия, который необходимо осуществить для того, чтобы добиться от внедрения АИС
должного эффекта (подбор и обучение персонала, изменения в организационной структуре и т.п.).
Документ заканчивается разделами "требования к документированию" и "источники разработки", определяющими,
соответственно, перечень и формы документации, подлежащей разработке и перечень уже имеющихся документов, содержащих
предпосылки для разработки.

27.

Требования к системе
ГОСТ разделяет все требования к системе на три класса:
1. требования к системе в целом;
2. требования к функциям (задачам), выполняемым системой;
3. требования к видам обеспечения.
(математическое, информационное, лингвистическое,
программное, техническое, метрологическое,
организационное, методическое)

28.

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