Сбор требований Цели сбора требований Достижение

Сбор требований

Цели сбора требований • Достижение соглашения между разработчиками, заказчиками и пользователями о том, что должна делать система • Достижение лучшего понимания разработчиками того, что должна делать система • Определения системной функциональности • Создание базиса для планирования разработки проекта

Роли участников процесса • Аналитики • Заинтересованные лица • Эксперты

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

3 фазы сбора требований • Выявление требований ▫ ▫ ▫ входные документы опросы наблюдения анализ нормативов анализ конкурентных продуктов статистика использования предыдущих версий • Анализ ▫ проверка целостности ▫ проверка законченности ▫ выявление случаев использования (use case) • Создание спецификации

Функциональные требования • Бизнес-требования ▫ goals ▫ vision ▫ scope • Пользовательские требования ▫ use case ▫ user story ▫ scenario • Функциональные требования ▫ SRS (system requirement specification)

Нефункциональные требования • • • Бизнес-правила предприятия Системные требования Требования к качеству Сопряжение с унаследованным кодом Следование стандартам (внутренним и внешним) • Лицензионные ограничения

Требования к требованиям • Единичность Описывает только одну сущность • Завершенность Полностью определено и вся информация собрана в одном месте • Непротиворечивость Не противоречит другим требованиям и соответствует входным документам • Атомарность Не может быть разбито на более мелкие требования без потери завершенности

Требования к требованиям • Отслеживаемость Документировано согласно принятым стандартам • Актуальность Ещё не устарело • Выполнимость Может быть реализовано в рамках проекта • Обязательность Описывает характеристику, отсутствие которой приведет к неполноценности решения

Требования к требованиям • Недвусмысленность ▫ Определение дано кратко, без использования жаргона и скрытых формулировок. ▫ Основано на фактах, а не на субъективных мнениях. ▫ Возможна только одна интерпретация. ▫ Определение не содержит нечетких фраз. ▫ Не содержит отрицательных утверждений. • Проверяемость Реализация может быть проверена одним из 4 доступных способов: ▫ ▫ Осмотр Тест Анализ Демонстрация

Анализ требований Цели анализа: • Устранение двусмысленности • Устранение неполноты • Устранение несогласованности • Выделение случаев использования

Анализ требований • Классификация требований (Requirements Classification) • Концептуальное моделирование (Conceptual Modeling) • Архитектурное проектирование и распределение требований (Architectural Design and Requirements Allocation)

Документирование требований • Концепция системы (Vision) Текстовый документ, который описывает, что будет включено в систему и что решено исключить. В нем отражаются пожелания заинтересованных лиц, а также указываются основные нефункциональные требования например, описывается платформа реализации и архитектура системы. • Модель требований Графические схемы UML. Служат для достижения соглашения между заказчиком и разработчиками, давая возможность заказчику убедиться в том, что система будет делать то, что они ожидают, а разработчикам создать то, что требуется.