- •Т1 Введение в курс
- •1 Определение Информационной системы.
- •Т2 Понятие требования классификация требований
- •1 Методология и стандарты, регламентирующие работу с требованиями.
- •2 Определение понятия требования
- •3 Классификация требований.
- •3.1 Требования к продукту и процессу
- •3.2 Уровни требований
- •3.3 Системные требования и требования к по
- •3.4 Функциональные, нефункциональные требования и характеристики продукта
- •3.5 Классификация rup
- •Т3 выявление требований
- •1 Источники требований
- •2 Стратегии выявления требований
- •2.4 Самостоятельное описание требований
- •2.5 Совместные семинары
- •Т4 формирование видения
- •Видения продукта и границы проекта.
- •Видение в rup
- •Т5 свойства требований
- •Полнота
- •Ясность (недвусмысленность, определенность, однозначность спецификаций).
- •Корректность и согласованность (непротиворечивость)
- •Верифицируемость (пригодность к проверке).
- •Необходимость и полезность
- •Осуществимость (выполнимость)
- •Упорядоченность по важности и стабильности.
- •Наличие количественной метрики.
- •Каких требований не должно быть.
- •Тема6: Классификация и специфицирование требований
- •1. Глоссарий.
- •2. Актеры и варианты использования.
- •3. Спецификация вариантов использования.
- •3.1 Свободный формат.
- •3.2 Шаблон полного описания вариантов использования.
- •3.3 Табличные представления варианта использования.
- •3.4 Шаблон варианта использования rup.
- •3.5 Выбор формы описания варианта использования.
- •3.6 Спецификация нефункциональных требований.
- •3.7 Атрибуты требований.
- •Тема7: Расширенный анализ требований. Моделирование
- •Цели моделирования
- •Модели uml, поясняющие функциональность системы
- •Диаграмма вариантов использования
- •Диаграмма действий
- •2.3. Диаграмма состояний
- •Диаграммы uml, поясняющие внутреннее устройство системы
- •3.1. Диаграмма классов.
- •Тема8: Расширенный анализ требований. Прототипирование
- •Цели прототипирования.
- •1)Неясные требования.
- •2)Разные варианты решения.
- •3) Анализ осуществимости.
- •Классификация прототипов.
- •Тема9: Документирование требований
- •Документирование требований в соответствие в гост
- •Структура в соответствии с гост 34.602-89
- •Описание требований к системе в соответствии с гост
- •2. Документирование требований на основе ieee Standard 830-1998
- •Тема10: Введение в управление требованиями
- •Определение понятия «управление требованиями»
- •2) Принципы и приемы управления требованиями
- •2.1) Базовая версия требований
- •2.2) Процедуры управления требованиями
- •2.3) Контроль версий
- •2.4) Атрибуты требований
- •2.5) Контроль статуса требований
- •2.6) Измерение трудозатрат, необходимых для управления требованиями
- •3) Управление изменениями
- •3.1) Управление незапланированным ростом объема
- •3.2) Процесс контроля изменений
- •3.3) Анализ влияния изменения
- •3.4) Трассируемость требований
- •Тема11: Проверка требований
- •1)Верификация и валидация
- •2)Некоторые типичные проблемные ситуации процесса формирования и оценки требований
- •2.1 )Двусмысленность требований
- •2.2) "Золочение" продукта
- •2.3) Минимальная спецификация
- •2.4) Пропуск типов пользователей
- •3) Методы и средства проверки требований
- •3.1) Неофициальные просмотры требований
- •3.2) Инспекции
- •3.3) Разработка тестов
- •3.4) Определение критериев приемлемости
- •Тема12 :Анализ требований и управление рисками
- •Тема13: Современные методы совершенствования процессов работы с требованиями
- •1) Требования в гибких методологиях
- •2) Артефакты для работы с требованиями в гибких методологиях
- •3)Планирование на основе требований на примере xp
- •3.1) Оценивание
- •3.2) Планирование версий и итераций
- •Тема14: Применение методов анализа требований при приобретении стандартного программного обеспечения
- •1. Современные тенденции в развитии аис и технологий их создания
- •2. Покупное или заказное по - критерии выбора
- •3. Стратегии выбора решения
- •3.1 Анализ требований
- •3.1.1 Рамки проекта.
- •3.1.2 Широта анализа требований.
- •3.1.3 Глубина проработки требований.
- •3.1.4 Требуемые ресурсы.
3. Спецификация вариантов использования.
Существуют различные способы описания вариантов использования.
-свободный формат;
-полный формат;
- таблица в 3 колонки;
- таблица в 2 колонки;
- стиль RUP.
Кроме того, иногда целесообразно использовать:
- диаграммы активности UML;
- диаграммы графической модели.
3.1 Свободный формат.
Свободный формат предполагает описаний действий системы и пользователя в повествовательном стиле.
Пример: Менеджер запросил у системы список заказов за период. Системы отображает на экран найденные заказы данного менеджера с указанием их основных атрибутов.
Свободный стиль допускает использование конструкций «Если, то».
3.2 Шаблон полного описания вариантов использования.
Название /краткая фраза в виде глагола в неопределенной форме совершенного вида, отражающая цель/
Контекст использования /уточнение цели, при необходимости – условия её нормального завершения/
Область действия /ссылка на рамки проекта/ (Пример: подсистема бухгалтерского учета)
Уровень /один из 3: обобщенный, цели пользователя, подфункции/ (Автор задает предопределенную трехуровневую классификацию требований, в целом соответствующую классификации требований на бизнес-требования, требования пользователя и функциональные требования.)
Участники и интересы /описание других актеров-участников прецедента с указанием их интересов/
Предусловие /то, что ожидается, уже произошло/
Минимальные гарантии /что точно гарантируется актерам-участникам/ (Например, в случае транзакции все данные, имевшиеся в системе до её начала, сохраняются неизменными/
Гарантии успеха /то, что получат актеры в случае успешного достижения целей/ (Пример: то, что запускает вариант использования, обычно – событие во времени.)
Основной сценарий /тут перечисляются шаги основного сценария, начиная от триггера и вплоть до достижения гарантии успеха/ (Формат описания: /№шага/ /описание действия/)
Расширения /тут последовательно описываются все альтернативные сценарии, каждая из которых привязана к шагу основного сценария/ (Формат описания: /№шага/ /№расширения/
/условие/: /действие или ссылка на подчиненный вариант использования/
Любой из шагов основного сценария может иметь более одного ветвления.
Каждое ветвление оформляется в виде расширения. В блоке «Расширения» все расширения описываются последовательностью. В случае, если альтернативный сценарий не удается описать одной строкой, применяется следующий формат: начиная со строки, следующей после описания расширения, идет описание его действий в формате основного сценария:
/№шага/ /№расширения/ /№шага расширения/ /действие/
Описание расширения заканчивается описанием выхода из расширения. Основные варианты выхода из расширения:
- возврат к очередному шагу основного сценария;
- переход к другому шагу основного сценария)
Вспомогательная информация /дополнительная информация, полезная при описании варианта использования/
3.3 Табличные представления варианта использования.
Иногда представляется удобным помещать сценарии вариантов использования в таблицу, как это показано ниже.
Преимущества: информация становится структурированной.
Актер |
Действие |
Пользователь |
Формирует запрос на поиск заказов |
Система |
Отображает список заказов |
Пользователь |
Выбирает требуемый заказ |
Система |
Показывает подробную информацию о заказе |
Второй вариант:
№ шага |
Пользователь |
Система |
1 |
Делает запрос на поиск заказов |
Отображает список заказов |
2 |
Выбирает заказ |
Показ. подробную инф. о заказе |
