Презентации / Lecture04p

Оформление требований

•В итоге требования оформляются в документе, называемом техническое задание (ТЗ)

requirements specification

•К сожалению, обычно в ТЗ попадают формулировки C-требований (функций)

•Но чем более ответственная система описывается (чем выше ожидания ее надежности и корректности работы), тем точнее формулировки и больше D- требований

•В большинстве случаев ТЗ приходится создавать (уточнять и дорабатывать) разработчикам, даже точнее, специалистам по обеспечению качества

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

Графическое моделирование требований

•Диаграммы потоков данных (Data Flow Diagrams, DFD)

•Диаграммы сущностей и связей (Entity Relationship Diagrams, ERD)

•Диаграммы Unified Modeling Language, UML

•Диаграммы и описания вариантов использования (Use Case Diagrams)

•др.

Диаграммы потоков данных (DFD)

•Служат для представления функциональных компонентов

•Элементы

•Потоки данных

•Процессы

•Внешние сущности

•Хранилища

•Процессы могут быть детализированы и образуют иерархию

Диаграммы сущностей и связей (ERD)

Диаграммы вариантов использования

•Служат для представления основных решаемых системой задач

•Элементы

Необходимые свойства требований

При их нарушении разработка наверняка столкнется с проблемами, переработаны из стандартов

IEEE 830 и IEEE 1233

• Адекватность, корректность

Соответствие реальным потребностям пользователей и заказчиков

• Полнота

Отражение в требованиях всех существенных характеристик и всех возможных ситуаций

• Однозначность, точность

Отсутствие двусмысленностей и возможностей разного толкования описаний ожидаемого поведения

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

• Непротиворечивость, согласованность

Отсутствие противоречий в формулировках и в ожидаемом поведении в одинаковых ситуациях

• Систематичность

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

-Важно для расстановки приоритетов и облегчения анализа и внесения изменений

•Прослеживаемость, проверяемость, модифицируемость

Необходимые свойства требований

•Адекватность, полнота, однозначность, непротиворечивость, систематичность

•Прослеживаемость

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

- Важно при отслеживании забытых требований или, наоборот, непонятно откуда взявшихся элементов проекта, кода, тестов и пр.

• Проверяемость

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

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

• Модифицируемость

Возможность внесения изменений с максимально легким отслеживанием их последствий и влияния

Классификация по связи с задачами

•Функциональные

•Относящиеся прямо к формулировке решаемых задач, т.е., к функциональности

•Составляют обычно от 80 до 95% всех описанных требований по объему

•Нефункциональные

•Относящиеся к другим характеристикам качества

Характеристики качества ПО

•Функциональность

•Формулировка задач, решаемых с помощью данного ПО

•Описание входных данных и условий

•Описание выполняемых преобразований и действий

•Описание результатов и их характеристик (точность, распределение, пр.)

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

•Расход всех вычислительных ресурсов при решении нужных задач

•Использование процессора

•Использование памяти (оперативной, постоянной, пр.)

•Использование пропускной способности каналов связи

Характеристики качества ПО

•Надежность

•Работоспособность системы в некорректном окружении (слегка за рамками функциональных требований)

•Возможности работы с некорректными входными данными

•Возможности продолжения работы/сохранения данных при сбоях электропитания

•Возможности продолжения работы/сохранения данных при сбоях каналов связи

•Зрелость системы (относительно возможных ошибок и сбоев)

•Среднее ожидаемое количество сбоев разных типов в заданном интервале времени

•Средние время и трудоемкость полного восстановления работоспособности при серьезном сбое

•Переносимость

•Работоспособность в другом окружении (слегка за рамками функциональных требований), без переделки системы (но, возможно, с доработкой каких-то конфигурационных файлов) – на других платформах, с другими форматами данных

•Возможность замены другого ПО этим при решении определенных задач