- •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.Вопросы для самоконтроля
- •Список литературы
3.2.3.Определение последующих действий
При завершении встречи договоритесь о способе связи, о времени следующей беседы и ее теме, если остались нерассмотренные вопросы. Составьте черновик требований, используя подходящие средства их записи и определенный стандарт. Затем этот черновик посылается (по электронной почте) заказчикам для рассмотрения и комментирования. Повторные опросы проводятся до полной удовлетворенности заказчиков требованиями.
3.3.Совместные семинары
Для налаживания связей между пользователями и разработчиками могут проводиться совместные семинары.
Основная задача организатора семинара – это создание условий для высокопроизводительного труда и заинтересованности в результатах своей работы участников для достижения согласованных решений.
При организации семинаров, основной целью которых является выявление требований, необходимо пользоваться определенными приемами, например [4]:
Основные правила. Участники семинара должны договориться об основных правилах проведения семинара, например: своевременно начинать и заканчивать семинар, не проводить несколько обсуждений одновременно, следить, чтобы каждый участвовал в работе, критиковать решения, а не людей их предложивших.
Границы проекта. При подготовке к семинару должен быть разработан документ, о видении и границах проекта. Необходимо следить, чтобы предлагаемые требования не выходили за текущие границы проекта и участники не углублялись в обсуждение несущественных на данном этапе деталей.
Темы для дальнейшего обсуждения. Если на семинаре пойдет разговор о случайных, нарушающих текущие рамки, но важных для дальнейшей работы сведениях, то запишите их. Это позволит, с одной стороны, не потерять что-то важное, а с другой – продемонстрировать уважение к участнику семинара. К таким сведениям часто относятся нефункциональные требования: показатели качества, ограничения на продукт, особенности интерфейса и т.п.
Ограничения по времени. Организатор семинара может наложить ограничения по времени на обсуждение каждой темы, что позволит обсудить все темы, вынесенные на семинар.
Отбор участников. В семинаре должны участвовать опытные и имеющие право принимать решения заинтересованные лица, эксперты, аналитики и разработчики. Организатор семинара должен помнить, что небольшие группы работают быстрее и продуктивнее.
Все участвуют в обсуждении. Организатор семинара должен следить за тем, чтобы в обсуждении участвовали все. Может оказаться так, что участник семинара уступает право голоса более активному сотруднику не потому, что у него нет своего (возможно ценного) видения проекта, а из-за неуверенности в себе и своих идеях.
После завершения семинара его участники должны обменяться информацией со своими, не приглашенными на семинар, коллегами и обсудить их комментарии и высказанные идеи на следующей встрече.
3.4.”Мозговой штурм”
Концепция мозгового штурма, позволяющая быстро генерировать идеи, не оценивая и не преобразуя их, в литературе описана достаточно подробно.
Применительно к процессу выявления и сбора требований “мозговой штурм” – это групповой метод быстрого генерирования множества идей, не все из которых, возможно, будут использованы.
Большое количество требований позволяет не только классифицировать их, разбивать по приоритетам, но и выбрасывать ненужные.
Рассмотрим подробно правила проведения сеансов “мозгового штурма” [10].