- •1.Виды, взаимосвязь и свойства требований
- •1.1.Что такое «требование»?
- •1.2.Виды требований
- •1.2.1.Функциональные требования
- •1.2.2.Нефункциональные требования
- •1.2.2.1.Нефункциональные требования к продукту
- •1.2.2.2.Нефункциональные требования к процессу
- •1.2.2.3.Внешние нефункциональные требования
- •1.5.Вопросы для самоконтроля
- •2.Определение образа и границ проекта
- •2.1.Анализ предметной области
- •2.2.Анализ осуществимости
- •2.3.Определение целей и области действия
- •2.4.Документирование образа и границ проекта
- •2.5.Вопросы для самоконтроля
- •3.Выявление требований
- •3.1.Определение способа сбора и анализа требований
- •3.1.1.Источники возникновения требований
- •3.1.2.Заинтересованные в проекте лица
- •3.2.Опрос (интервью)
- •3.2.1.Подготовка
- •3.2.2.Проведение опроса
- •3.2.3.Определение последующих действий
- •3.3.Совместные семинары
- •3.4.”Мозговой штурм”
- •3.4.1.Роли во время сеансов
- •3.4.2.Правила проведения сеанса
- •3.4.3.Подготовка к сеансу
- •3.4.4.Проведение сеанса
- •3.4.5.Обработка результатов сеанса
- •3.5.Сценарии
- •3.5.1.Сценарии событий
- •3.5.2.Варианты использования
- •3.5.3.Применение модели msc uml
- •3.6.Выявление требований на основе различных точек зрения. Метод vord
- •3.6.1.Идентификация точек зрения
- •3.6.2.Структурирование точек зрения
- •3.6.3.Документирование и отображение системы точек зрения
- •3.7.Этнографический подход
- •3.8.Вопросы для самоконтроля
- •4.Разработка системных требований
- •4.1.Детализация требований пользователей
- •4.2.Системные модели
- •4.2.1. Модели потоков данных
- •4.2.2.Модели конечных автоматов
- •4.2.3.Модели данных
- •4.3.Прототипы
- •4.3.1.Роль прототипов при разработке требований
- •4.3.2.Виды прототипов
- •4.4.Разработка прототипов
- •4.4.1.Экспериментальное прототипирование
- •4.4.2.Эволюционное прототипирование
- •4.4.3.Риски прототипирования
- •4.5.Системные требования
- •4.5.1.Структурированный естественный язык
- •4.5.2.Языки описания программ
- •4.5.3.Графические нотации
- •4.6.Документирование системных требований
- •4.7.Вопросы для самоконтроля
- •5.Документирование требований
- •5.1.Спецификация требований
- •5.2.Состав спецификации требований
- •5.3.Рекомендации по разработке требований
- •5.4.Стандартные шаблоны спецификации
- •5.5.Вопросы для самоконтроля
- •6.Анализ спецификации требований
- •6.1.Оценка качества спецификации требований
- •6.1.1.Характеристики качества спецификации
- •6.1.2.Аттестация требований
- •6.2.Экспертиза спецификации
- •6.3.Прототипирование
- •6.4.Автоматизированный анализ
- •6.5.Тестирование требований
- •6.6.Вопросы для самоконтроля
- •7.Управление требованиями
- •7.1.Причины изменений требований
- •7.2.Принципы управления требованиями
- •7.3.Управление изменениями
- •7.4.Управление версиями
- •7.5.Управление связями требований
- •7.6.Риски, связанные с требованиями
- •7.6.1.Риски этапа выявления требований
- •7.6.2.Риски этапа анализа и спецификации требований
- •7.6.3.Риски управления требованиями
- •7.7.Вопросы для самоконтроля
- •8.Case-средства для управления требованиями
- •8.1.Выбор case-средств для управления требованиями
- •8.2.Уровень зрелости и используемые инструменты
- •8.2.1.Моделирование требований
- •8.2.2.Трассировка требований
- •8.2.3.Управление версиями
- •8.3.Возможности case-средств управления требованиями
- •8.3.1. Средства idf-моделирования
- •8.3.2.Средства uml
- •8.4.Вопросы для самоконтроля
- •Список литературы
2.3.Определение целей и области действия
Бизнес-требования определяются целями и политикой организации их, как правило, высказывают те, кто финансирует проект разработки программной системы. Бизнес-требования определяют цели, которые организация намерена достичь с помощью этой системы. Пользовательские и функциональные требования должны соответствовать бизнес-требованиям в противном случае их не следует включать в проект.
Участники проекта, лица в нем заинтересованные должны иметь четкие и согласованные бизнес-цели и приоритеты в противном случае, решая разные противоположные задачи, они приведет проект к неминуемому краху.
Бизнес-требования – это вся та информация, которая описывает финансовые, рыночные и другие коммерческие преимущества, которые пользователи (и разработчики) хотят получить от использования продукта.
Бизнес-правила – это множество корпоративных политик, законов и стандартов, которые контролируют бизнес организации.
Такие правила не связаны, с какой либо конкретной программной системой, но являются одним из основных источников функциональных требований, т.к. определяют возможности, которыми должна обладать программная система для выполнения бизнес-правил. Некоторые бизнес-требования также могут определяться бизнес-правилами (например, законами государства).
Образ продукта (product vision) описывает продукт во времени. В нем указывается, как продукт будет изменяться (эволюционировать) от текущего состояния при развитии или изменении бизнес-целей. Границы проекта (project scope) относятся к определенной итерации проекта или версии продукта.
Образ, или концепция продукта – это определение стратегического образа системы, позволяющей выполнять бизнес-задачи. Образ будет основой принятия решений в течение всего жизненного цикла продукта, т.к. содержит описание долгосрочных целей и назначения продукта, которое удовлетворяет различных заинтересованных лиц, основано на существующих (или прогнозируемых) рыночных факторах, учитывает структуру и стратегию развития организации.
2.4.Документирование образа и границ проекта
Сведения об образе и границах проекта могут быть оформлены в виде отдельного документа [4], владельцами которого являются лица, финансирующие проект. Этот документ должен содержать следующую информацию.
Бизнес-требования.
Обоснование и содержание нового продукта, причины, по которым было принято решение о создании продукта. Описание ситуации на рынке, где продукту придется конкурировать с другими продуктами. Для корпоративной системы приводится описание бизнес-проблемы, которую решает продукт, среды, в которой он будет использован, сравнительная оценка продукта и его конкурентов, преимущества продукта. Описание бизнес-целей и критерии оценки их достижения в количественном и измеряемом виде, рисков, возможных потерь от них и способов минимизации рисков.
Положение об образе проекта.
Положение об образе проекта должно содержать описание:
целевой аудитории пользователей, их потребности или возможности;
имени, категории и ключевого преимущества – основы для использования;
отличий от конкурентов или текущего бизнес-процесса, описание основного отличия и преимущества продукта.
основных функций и возможностей продукта, предоставляемых пользователю. Функции и возможности должны быть идентифицированы, а те из них, которые отличают продукт от конкурентов – подчеркнуты.
предположений и зависимостей. Перечисляются зависимости проекта от внешних факторов, документируются все предположение сделанные заинтересованными лицами при разработке данного документа.
Масштабы и ограничения проекта.
Описывается объем первоначальной версии, куда включают наиболее важные для широкой аудитории функции, которые можно реализовать как можно раньше и объемы последующих версий продукта. Здесь же перечисляются те возможности и характеристики продукта, которых могут ожидать заинтересованные лица, но включение, которых не предусмотрено в продукт или определенную версию не предусмотрено.
Бизнес-контекст.
Описываются профили заинтересованных лиц, которые (профили) включают данные об основной ценности или преимуществе, которое принесет продукт, о вероятном отношении к продукту, наиболее интересные функции и характеристики и т.д.
Приоритеты проекта.
Перечисляются приоритеты факторов, которыми может оперировать менеджер проекта для достижения успеха. Например, каждый проект имеет пять измеряемых параметров [4, 10]: объем (функции), качество, график, затраты и кадры. Каждый из параметров может относиться к одной из категорий: ограничение (лимитирующий фактор, в рамках которого должен оперировать менеджер), ключевой фактор (важный фактор успеха, ограниченно гибкий при изменениях) и степень свободы (фактор, который можно в некоторой степени изменять). Тогда расстановка приоритетов – это соотнесение параметров и категорий параметров.
Операционная среда.
Приводится описание среды, в которой будет использоваться система, и определяются требования к доступности, надежности, производительности и целостности.
Документ об образе и границе проекта определяет границу и связи системы с остальным миром. Использование в документе контекстной диаграммы позволяет графически иллюстрировать эту границу, описывая внешние сущности (расположенные вне системы), а также потоки данных, управляющие и материальные потоки, протекающие между системой и внешним миром. Диаграммы могут помочь уточнить взаимодействие между заинтересованными в проекте лицами.