- •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.Опрос (интервью)
Проведение опроса состоит из трех этапов: подготовка опроса, его проведение и определение последующих действий [9, 10].
3.2.1.Подготовка
При подготовке опроса должны быть разработаны вопросы, выбраны опрашиваемые пользователи и спланированы контакты.
При подготовке вопросов нужно использовать документы, которые имеются в наличии. Это может быть запрос на разработку системы, описание концепции, план управления программным проектом, документы, описывающие конкурирующий продукт и т.п. Необходимо сформулировать несколько вопросов, позволяющих выяснить те требования, которые действительно необходимы, а не те, которые желательны.
Обычно имеется несколько заинтересованных в разработке лиц (групп лиц), ценность системы для которых, определяется различными ее характеристиками, например:
повышение производительности;
повышение надежности;
снижение себестоимости;
легкость и простота использования и т.д.
Учитывая этот факт, выбор опрашиваемых пользователей превращается в достаточно сложную задачу. При подготовке опроса рекомендуется перечислить все группы заинтересованных лиц и определить их приоритеты.
Для определения групп заинтересованных лиц нужно понимать, что их можно классифицировать по различным признакам, например:
по правам доступа к системе, например администратор и обычный пользователь;
по частоте использования системы;
по опыту в предметной области;
по опыту работы с компьютерными системами и т.д.
Можно выбрать одно или, возможно, два основных заинтересованных лица, опросить их, а затем уже собрать комментарии остальных основных заинтересованных лиц.
При планировании контактов желательно иметь сведения о том человеке, с которым будет происходить встреча: его взгляд на проект, его личный вклад как заказчика, или организатора проекта и т.д. Время начала и конца опроса должно быть определено, согласовано и зафиксировано. Если первый контакт происходит по телефону или электронной почте нужно:
объяснить цель встречи, каким образом данный человек попал в перечень участников опроса;
подчеркнуть, что он является тем человеком, который может дать правильные ответы на вопросы;
указать продолжительность интервью;
согласовать способ записи опроса и т.д.
3.2.2.Проведение опроса
Опрос можно провести по телефону, при помощи Internet, но наиболее эффективный способ – это личная встреча, которая позволяет создать правильную атмосферу, обеспечивающую комфорт участников.
Для создания атмосферы доверия и взаимопонимания, которая позволит задавать как общие, так и более глубокие вопросы в [10] рекомендуется:
демонстрировать искренний интерес относительно вклада данного человека в дело разработки программного обеспечения;
слушать, т.к. самая лучшая мотивация для опрашиваемого – полное внимание спрашивающего;
быть откровенным и честным;
предложить помощь в составлении отчета о проекте и т.д.
Там же при проведении опроса рекомендуется использовать вопросы, которые должны быть простыми краткими, не задавать более одного вопроса одновременно. Те вопросы, которые были подготовлены заранее, являются только планом для направления хода беседы, поэтому нужно импровизировать, не быть пассивным, показать, что вы исследуете сами (и побуждать делать это собеседника), показывать, что вы понимаете желания и нужды собеседника.
Хотя очень важно внимательно слушать опрашиваемого во время интервью, обычно бывает трудно сформулировать требования, слушая его в одиночку. Часто опрашиваемый формулирует требования по ходу разговора, и нуждается при этом в помощи, поэтому, хотя в основном концепция формируется со слов опрашиваемого, интервьюер и опрашиваемый разрабатывают концепцию до некоторой степени совместно. Значит лучше иметь на встрече двух интервьюеров, особенно если в опросе участвуют представители нескольких групп заинтересованных лиц, поскольку считается, что один интервьюер имеет тенденцию пропускать некоторые важные вопросы.
Рекомендуется [10] задавать не только вопросы, непосредственно относящиеся к бизнесу, процессу или программному продукту. Например, некоторые из таких вопросов:
Может ли эта система причинять какие-либо проблемы?
Существует ли необходимость решения тех проблем, которые могут быть неочевидными?
Может ли кто-то еще решить поставленную задачу?
Что будет делать новая система из того, что в данный момент недостижимо при помощи существующих систем?