- •Т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.1 Анализ требований
Рациональным приемом, позволяющим снизить затраты на подготовку вариантов решения, а заодно снизить риски, является формирование документа требований (не только ко вновь создаваемому, но и к выбираемому продукту).
Тем самым, часть работы можно переложить на представителей маркетинговых отделов вендоров - пусть они объяснят и продемонстрируют, как на практике реализуются Ваши требования.
Практическое применение методов анализа требований, рассмотренных на протяжении лекционного курса, применительно к задаче выбора покупного решения, требует ответа на следующие вопросы:
-рамки проекта;
-широта анализа требований;
-глубина проработки требований;
-требуемые ресурсы.
3.1.1 Рамки проекта.
Какие бизнес-процессы, подразделения, отделы предприятия необходимо автоматизировать? Практика внедрения АИС показывает, что даже на самых передовых в информационном смысле предприятиях степень охвата бизнеса информационными технологиями редко превышает порог в 90%.
Можно разбить крупномасштабный проект автоматизации на несколько этапов, начав, допустим, с планки в 30%.
Другая стратегия - "все и сразу" предполагает попытку сразу выйти на максимально возможный охват функций.
3.1.2 Широта анализа требований.
Сколько требований вы в состоянии сформулировать в течение разумного промежутка времени? Сколько времени уйдет у вендоров на анализ документа требований, который вы подготовите?
Можно привести следующее соотношение: документ описания требований для предприятия с годовым оборотом в $40 млн., содержит около 1000 позиций (требований).
3.1.3 Глубина проработки требований.
Какую выбрать степень детализации требований?
Уровень документа "Концепция" вряд ли окажется достаточным для серьезного рассмотрения. Необходимо отражать как функциональные, так и нефункциональные требования. Можно остановиться на кратких формулировках функций (лаконично, трудно проверяемо). Можно перейти на язык сценариев (появляется возможность доскональной проверки, но это потребует значительных ресурсов). Хорош вариант с комбинацией этих способов описания: критичный функционал описать в форме сценариев, остальное - в виде функций.
3.1.4 Требуемые ресурсы.
Ключевой ресурс предприятия - человеческий ресурс. Найдут ли топ-менеджеры предприятия время на скрупулезную оценку требований к системе? Насколько хорошо смогут сформировать требования руководители линейных подразделений? Насколько удастся задействовать ресурс поставщиков решений? Стоит ли привлекать внешних консультантов?Какова цена обследования? Как быстро удастся сформировать требования? Какое время следует выделить на получение ответов от вендоров, на анализ этих ответов перед окончательным выбором?
Конкретные ответы соответствуют специфике предприятия.
.