7.7. Спецификация требований к интерфейсам
Определяет требования к интерфейсам между системными компонентами (системами, подсистемами, элементами конфигурации ПО, аппаратурой):
идентификация и диаграммы функционирования интерфейсов,
требования по типам интерфейсов,
характеристики передаваемых элементов данных (идентификация, типы данных, размер, формат, единицы измерений, точность, источники, приемники),
характеристики методов коммуникации и протоколов обмена,
приоритеты и критичность требований,
методы аттестации, которые должны быть использованы для демонстрации выполнения требований.
7.8. Работа с требованиями в проектах гибкой разработки
Гибкая разработка ПО — Agile:
eXtream Programming,
Scrum.
Стратегия разработки:
итеративная + инкрементная.
Терминология: итерация, реализация.
Модели разработки ПО: инкрементная и итеративная
https://habrahabr.ru/company/edison/blog/269789/
Пользовательская история
Концепция:
текстовое описание истории,
устные обсуждения истории, выявляющие ее детали,
тесты, которые отражают и документируют детали истории.
Реализация: бумажная карточка + рукописный текст.
Задача карточки: напомнить о требовании, помочь в планировании разработки.
Примеры историй:
Пользователь может поместить свое резюме на веб-сайте.
Пользователи могут просматривать информацию о каждой вакансии, соответствующей критериям поиска.
Пользователь может запустить систему в Windows и Linux.
Пользователю предоставляется возможность экспортировать данные в формат XML.
Пользователь может добавить, изменить или удалить несколько резюме.
Пример карточки
Лекция 8. Управление требованиями к по
8.1. Управление требованиями
Составляет часть общего управления проектом:
идентификация, организация и документирование требований. Необходимо, чтобы требования были доступны для дальнейшей работы. сокращения - это идентификация того или иного уровня, как обозначать бизнес правила, функциональные требования и тд.
изменение требований. Влечет за собой потенциальную угрозу того, что требование начнет конфликтовать с другими требованиями. необходимо проследить влияние на другие требования. Оценить возможность внесения этого изменения.
тестирование выполнения требований. Процесс уже переносит на этап разработки требований, к тому моменту когда пишется код, тесты уже должны быть готовы. Любое изменение требований, добавляет доп. тесты.
8.1.1. Причины изменений требований
Внешние факторы:
изменения решаемой проблемы,
изменение мнения пользователей о задачах ПО,
изменение внешней среды,
ввод в эксплуатацию первого (предыдущего)выпуска ПО.
Внутренние факторы:
невыявленные требования,
неточно сформулированные требования,
«лишние» требования.
8.1.2. Причины изменений требований
Фиксация базовой версии требований (Baseline):
официальное рецензирование,
утверждение,
передача в систему управления требованиями к ПО (конфигурацией, проектом).
Дальнейшие изменения требований выполняются в соответствии с процедурой изменений.
Допустимый объем изменений в месяц 1-4%.
Изменения официальные и неофициальные.
Анализ последствий изменения требований.
8.1.3. Хранение требований в системе управления требованиями
Атрибуты требований (Вигерс):
дата создания,
номер текущей версии,
автор,
приоритет,
состояние (статус),
источник требования,
логическое обоснование требования,
номер выпуска (итерации), на который назначено требование,
ответственный за изменение требования,
метод проверки или критерий приемки.
8.1.4. Статус требования
Предложено |
Proposed |
В процессе разработки |
In Progress |
Подготовлено |
Drafted |
Одобрено |
Approved |
Реализовано |
Implemented |
Проверено |
Verified |
Отложено |
Deferred |
Удалено |
Deleted |
Отклонено |
Rejected |
8.1.5. Прохождение запроса об изменении
Леффинуэлл, Уидриг «Принципы работы с требованиями к программному обеспечению».
8.1.6. Матрица отслеживания связей требований
8.1.7. Результаты анализа изменения требований
Конфликт с требованиями базовой версии.
Ухудшение производительности и других атрибутов качества продукта.
Изменение невыполнимо из-за ограничений в квалификации специалистов.
Изменение невыполнимо из-за технических ограничений.
Изменение потребует приобретения дополнительных ресурсов (лицензий, оборудования).
Изменение изменит последовательность и сроки выполнения других задач, включенных в план.