Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Лабораторная работа №1.doc
Скачиваний:
23
Добавлен:
14.03.2015
Размер:
755.2 Кб
Скачать

Лабораторная работа №1

Описание тестируемой системы и ее окружения

(4 Часа)

Теоретическая часть

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

«Документа Бизнес-Требований» представляет требования к системе с точки зрения бизнеса. На основании «Документа Бизнес-Требований» аналитик должен сформировать «Спецификацию Требований к ПО» или ее упрощенный вариант «Функциональную Спецификацию».

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

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

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

Структура Спецификации может быть следующей:

  1. Название документа и его версия;

  2. Название проекта и код;

  3. История Изменения Документа: дата, автор, краткое описание изменения, измененные разделы;

  4. Список Согласования: ФИО, роль в проекте, подпись, дата (в случае использования системы электронного документооборота и системы электронной подписи последние два атрибута могут быть опущены);

  5. Оглавление;

  6. Перечень Рисунков;

  7. Перечень Таблиц;

  8. Введение: краткое описание целей создания документа и его содержания. Необходимо дать ссылку на «Документ Бизнес-Требований» и его версию, который использовался при создании Спецификации;

  9. Функциональные Требования:

1) Код и название требования;

2) Описание;

3) Входные/Выходные Данные;

4) Интерфейс Пользователя: описание требований к интерфейсу пользователя с макетами экранов;

5) Системный Интерфейс: описание требований к интерфейсу системы, который будет использоваться внешними системами;

6) Зависимости: ссылки на функциональные требования, которые зависят от данного требования. Можно создать «Матрицу Трассировки Функциональных Требований», подобную описанной в статье «Управление Требованиями». В этом случае данную секцию можно опустить;

  1. Нефункциональные Требования:

1) Код и название требования;

2) Описание;

  1. Предположения и Ограничения: результаты уточнения деталей реализации требований, которые по явным причинам не были покрыты в «Документе Бизнес-Требований», должны быть указаны в этом разделе;

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

  3. Ссылки на дополнительные материалы (функциональные модели, модели данных и т.п.).

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

  1. Название документа и его версия;

  2. Название проекта и код;

  3. История Изменения Документа: дата, автор, краткое описание изменения, измененные разделы;

  4. Список Согласования: ФИО, роль в проекте, подпись, дата (в случае использования системы электронного документооборота и системы электронной подписи последние два атрибута могут быть опущены);

  5. Оглавление;

  6. Перечень Рисунков;

  7. Перечень Таблиц;

  8. Введение: краткое описание целей создания документа и его содержания. Необходимо дать ссылку на «Документ Бизнес-Требований» и его версию, который использовался при создании Спецификации;

  9. Функциональные Требования:

1) Код и название требования;

2) Описание;

3) Входные/Выходные Данные;

4) Интерфейс Пользователя: описание требований к интерфейсу пользователя с макетами экранов;

5) Системный Интерфейс: описание требований к интерфейсу системы, который будет использоваться внешними системами;

6) Зависимости: ссылки на функциональные требования, которые зависят от данного требования. Можно создать «Матрицу Трассировки Функциональных Требований»;

  1. Предположения и Ограничения: результаты уточнения деталей реализации требований, которые по явным причинам не были покрыты в «Документе Бизнес-Требований», должны быть указаны в этом разделе;

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

  3. Ссылки на дополнительные материалы (функциональные модели, модели данных и т.п.).

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

  1. Название документа и его версия;

  2. Название проекта и код;

  3. История Изменения Документа: дата, автор, краткое описание изменения, измененные разделы;

  4. Список Согласования: ФИО, роль в проекте, подпись, дата (в случае использования системы электронного документооборота и системы электронной подписи последние два атрибута могут быть опущены);

  5. Оглавление;

  6. Перечень Рисунков;

  7. Перечень Таблиц;

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

  9. Архитектура Системы: техническое описание архитектуры системы;

  10. Системные Интерфейсы: 1) Используемые Интерфейсы: описание интерфейсов с внешними системами, используемых разрабатываемой системой; 2) Предоставляемые Интерфейсы: описание интерфейсов, предоставляемых внешним системам;

  11. Схема Базы Данных;

  12. Предположения и Ограничения: результаты уточнения деталей реализации требований, которые по явным причинам не были покрыты в «Функциональной Спецификации», должны быть указаны в этом разделе;

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

  14. Ссылки на дополнительные материалы (внешние файлы моделей, описание интерфейсов и т.п.).