Обзор практических методик сбора требований Дмитрий Гайдамович, отдел программирования Сообщение для разработчиков Начало

Проблема требований

Первое приближение необходимое пользователю для решения его проблемы при достижении его цели; необходимое для удовлетворения требований документов: договора на разработку ПО; стандартов; спецификаций; и др. Требование (requirement) Это свойство ПО,

Управление требованиями Это систематическая деятельность, включающая в себя: сбор (выявление) требований организацию (структурирование большого количества) требований и их документирование процесс выработки соглашения между заказчиком и командой проекта по поводу изменений требований к системе

Почему систематическая деятельность? чтобы не пропустить важных требований чтобы важные требования не реализовывать на скорую руку, потому что о них забыли или под давлением обстоятельств Идея формализованной, систематической деятельности не нова: SEI-CMM ISO 9000 RUP XP

Навыки, которыми должна обладать команда разработчиков методы анализа проблемной области понимание потребностей пользователей: приемы выявления требований посредством общения с заинтересованными лицами определение системы управление масштабом уточнение определения системы построение правильной системы

Требования Многообразие понятий потребность пользователя требование к ПО постановка задачи способ решения цель системы условие договора функция свойство

Наведем порядок Три уровня понятий: I. потребности или нужды заинтересованных лиц (requisites) II. функции или свойства ПО (features) III. требования к ПО (software requirements)

Проблемная область почему так туманно? проблема не наша находится в головах пользователя сформулирована на языке пользователей Проблемная область почему так туманно? проблема не наша находится в головах пользователя сформулирована на языке пользователей

Потребность заинтересованного лица Это выражение некой личной, рабочей или бизнес- проблемы, решение которой оправдало бы замысел, покупку или использование новой системы ? ? ? ? ? потребности Характеристики потребностей: относятся к проблеме неоднозначны и размыты язык - заинтересованного лица имеют высокий уровень: единицы (1-5)

Функция, свойство ПО Это выражение желаемого сервиса системы для удовлетворения одной или нескольких потребностей заинтересованных лиц Характеристики функций: относятся к решению проблемы (единица дробления решения) определены неточно могут противоречить друг другу язык - заинтересованного лица имеют средний уровень: десятки (10-99) ? ? ? функциипроблемарешение

Для чего используются функции чтобы описывать возможности ПО без лишних подробностей чтобы объяснять поведение системы заинтересованным лицам чтобы управлять сложностью путем выбора уровня абстракции (рекомендуется иметь не более 50 функций) Атрибуты функций Для того, чтобы было легче оперировать этой информацией, используют данные, обеспечивающие дополнительную информацию (см. примеры атрибутов функций)

функциитребования #include "stdafx.h" //$$ // База данны #include "database.h" #include "docs.h" #include "deffld.h" #include "fields.h" #include "lru2hash.h" #include "script.h" #include "lic.h" #include "sdocs.h" #ifdef _MTKODEKS LocksObj dataBaseLockerMutex; class VolumsArray{ код Требование к ПО Это условие или характеристика, которой должна соответствовать система Характеристики требований к ПО: относятся к решению проблемы определены детально (можно запрограммировать) не могут противоречить друг другу язык - разработчика имеют низкий уровень: сотни, тысячи

Распространенные типы требований функциональные, поведенческие требования (functionality) нефункциональные: требования практичности (usability) требования надежности (reliability) требования производительности (performance) требования возможности поддержки (supportability)

Наш маршрут функции нужды программные требования область решения высокий уровень низкий уровень выявление требований область проблемы

Выявление требований

Что хотим сделать Инициатива должна исходить от команды разработчиков Что мешает: Синдром да, но... Синдром неоткрытых руин Синдром пользователя и разработчика понять потребности составить список функций ПО неотъемлемая часть процесса разработки

Синдром да, но... Раз за разом одно и то же: одновременно две противоположные реакции: О, да, это здорово, мы можем это использовать, молодцы, ребята, и т.д. Да, но как насчет...? Нельзя ли было бы... ? А что будет, если... ? день сурка

Синдром неоткрытых руин Сколько еще не выявленных требований ? чем больше собрано, тем лучше понятно, что это еще не все никогда нельзя узнать полностью, что нужно от системы миссия невыполнима Тесно связан с выявлением заинтересованных лиц

Это расхождение взглядов пользователя и разработчика, которые часто говорят на разных языках, имеют различный опыт, мотивацию и цели. пользователи не знают, чего они хотят, а если и знают, то не знают, как это выразить пользователи думают, что знают, чего хотят, до тех пор, пока разработчики не предоставят им то, что они якобы хотели разработчики думают, что понимают проблемы пользователя лучше его самого каждая сторона считает, что другая сторона руководствуется политическими мотивами. тесные контакты третьего рода Синдром пользователя и разработчика Примеры:

Методики выявления требований интервьюирование и анкетирование семинар, посвященный требованиям мозговой штурм и отбор идей раскадровка варианты использования обыгрывание ролей прототипирование пользовательские истории постоянное присутствие заказчика СЕГОДНЯ

Интервьюирование решаем, с кем проводить интервью (выбираем заинтересованное лицо) выбираем время и место задаем вопросы получаем ответы сталкиваемся с синдром пользователя и разработчика убрать препятствия для свободного обмена информацией. Основная задача:

Интервьюирование. Вопросы по поводу и без повода 1. Вопросы, не связанные с возможным решением. Позволяют не оказывать влияния на ответы пользователя, избежать предубеждения пользователя при ответе. Не предлагая решения сразу, нужно выжать максимум понимания самой проблемы Два типа вопросов: 2. Вопросы в контексте предложенного решения Позволяют: выявить наше непонимание проблемной области переработать предложенное решение на ранней стадии

Интервью: момент истины Иметь список вопросов. Не задавать ненужных вопросов. Записывать кратко, не пытаться сохранять ответы в электронном виде. Сверяться с образцом. Не забыть о цели беседы. Советы для успешного проведения интервью

Интервьюирование. Результат Заключение аналитика: По результатам одного интервью записываются три наиболее важных потребности и проблемы Что должны дать несколько интервью более глубокое понимание проблемы представление пользователя об успешном решении

Анкетирование вопросы по делу невозможно придумать заранее предположения, стоящие за вопросами, оказывают влияние на ответ (вы перестали пить коньяк по утрам?) нет обратной связи, чтоб вскрывать новые области трудно интерпретировать неясные ответы пользователя Недостатки: Когда все же можно составить анкету: если мы на 100 % уверены, что некоторые наши предположения соответствуют действительности

Семинар, посвященный требованиям наиболее мощный метод, наиболее сложный для осуществления Цели: Участники: Отводимое время: 1-2 дня Предмет рассмотрения: достижение единства мнений ускорение принятия решения основные заинтересованные лица представители команды разработчиков ведущий (желательно, со стороны) состав высокоуровневых функций приложения.

Семинар, посвященный требованиям. Преимущества перед другими методами помогает создать команду, подчиненную общей цели – успеху проекта эффект очной ставки: все заинтересованные лица имеют возможность высказаться сразу формирует соглашение между командой и заинтересованными лицами позволяет высветить и разрешить политические вопросы, которые влияют на успех результат немедленно становится известным обеим сторонам

Семинар, посвященный требованиям. Подготовка распространение идеи (концепции) достижение гарантии участия основных заинтересованных лиц подготовительные материалы: информация по проекту: первоначальные наброски списка потребностей списки предлагаемых функций копии проделанных интервью прочее (важно не завалить участников документами) информация для подготовки свободного мышления: правила поведения на семинаре статьи и прочее

Семинар, посвященный требованиям. Ключевая роль ведущего задать объективный и профессиональный тон начать и закончить вовремя установить правила и добиваться их выполнения предложить цели и повестку дня управлять течением дискуссии способствовать процессу принятия решений заниматься организационными вопросами удостовериться, что все заинтересованные лица участвуют и их пожелания учтены контролировать поведение, которое мешает продуктивной работе Кого позвать? - Человека со стороны! Чего не делает ведущий: Зачем он нужен: не вносит свои идеи не участвует в обсуждении

Семинар, посвященный требованиям напряженная атмосфера (имеются причины, по которым трудно достичь согласия, и ВСЕ они будут представлены) аудитория настроена враждебно или может иметь политические предубеждения Проблемы? Это нормально! Что обязательно будет на семинаре Ведущий должен: быть морально и психологически готов к этому иметь ряд приемов для выхода из неприятных ситуаций

Семинар, посвященный требованиям. Результат протокол совещания любые другие итоги совещания: списки идей списки функций соглашение о проведении других собраний требуемые дополнительные усилия для понимания потребностей По окончании участникам раздается:

Спасибо за внимание До следующей встречи!