Download - L2 requirements

2Software Engineering Professional Program © 2007.

T E K A M A2-1

Разработка требований

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

По материалам книги Карла Вигерса «Разработка

требований к программному обеспечению»

T E K A M A2-2Software Engineering Professional Program © 2007.


Цели и задачи

• Процесс разработки требований

• Определение заинтересованных сторон и их интересов

• Процесс выявления требований

– Проблемы и решения

– Специальные подходы к выявлению требований• Варианты использования

• Создание прототипов

• Характеристики качества

• Понимание бизнес-правил

• Уточнение, количественная оценка, задание приоритетов

• Поиск недостающих требований



Вопросы для размышления• Какие группы участников вовлечены в процесс разработки требований?

• Как методы выявления требований используются для эффективного

сбора требований?

• Какие проблемы возникают при выявлении требований и как их можно

разрешить?

• Как можно измерить характеристики качества?

• Какие существуют бизнес правила и как они соотносятся с процессом

разработки технических требований?

• Почему уточнение, количественная оценка и задание приоритетов так

важны как для разработчиков, так и для заказчиков?

• Как определить, что все требования учтены?



Процесс разработки требований

• Повторяющийся• Многошаговый• Необязательно последовательный

Выявление Анализ Спецификация Проверка

повторная оценка

переработкауточнение

исправление и устранение недостатков



Процесс разработки требований и рабочие документы

Анализ осуществимост

и

Формирование и анализ

требований

Отчет об осуществимости

создания системы

Спецификация требований

Проверка требований

Модели системы

Пользовательские и системные

требования

Спецификация требований



Анализ осуществимости

• Основные вопросы:

– Отвечает ли система общим и бизнес-целям

организации заказчика и организации-

разработчика?

– Можно ли реализовать систему в рамках заданной

стоимости и с использованием имеющихся

технологий?

– Можно ли объединить систему с другими уже

эксплуатирующимися системами?



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

Анализ предметной области

Сбор требованийКлассификация

требований

Специфицирование требований

Проверка требований

Определение приоритетов

Разрешение противоречий

Документация системных требований

Начало процесса



Преимущества хорошего процессаразработки технических требований• Сокращение объема переработки (кода)

• Улучшение коммуникации

• Уменьшение расползания границ проекта

• Сокращение количества дефектов в требованиях и

ненужных свойств

• Ускорение разработки

• Повышение удовлетворенности заказчиков и

разработчиков



Рабочая среда продукта

Руководство проекта

Разработка

ТестированиеДругие заинтересованные лица

Представители пользователей

Спонсоры проекта

информации о размере и сложности

Функциональные и нефункциональные


Бизнес требования

Функциональные и нефункциональные


требования пользователей

Ожидания и ограничения

Аналитик требований



Источники требований• Источники требований очень сильно зависят от специфики проекта.

• Какие существуют потенциальные источники требований?

– Беседы/обсуждения с потенциальными пользователями

– Документы, описывающие существующие или конкурирующие

продукты

– Спецификации требований к системе

– Отчеты об ошибках/запросы по совершенствованию претензии к

возможностям работающей системы

– Маркетинговые исследования/опросы пользователей

– Наблюдение за пользователями на рабочих местах

– Анализ сценариев задач пользователей



Ключевые игроки

• Основное контактное лицо между классом пользователей и аналитиком по требованиям проекта

• «Чемпион» или «Чемпионы»?• Есть или нет? Зависит от размера проекта• Кто подходит?

– Энтузиаст– С четким представлением о системе– Умеет хорошо общаться– Имеет авторитет среди коллег– Хорошо понимает предметную область и рабочую среду

приложения– Уполномочен к принятию решений

• Помните, что они не единственные заказчики системы



Заинтересованные лица, заказчики и пользователи Иерархия

Заинтересованные лица – это те, кто каким-либо образом вовлечен в процесс разработки.

Заинтересованные лица

Другие лицаЗаказчики

ПользователиПоставщики,Менеджеры

Операторы РазработчикиМенеджеры Служба поддержки



Заинтересованные стороны

Определение: индивидуумы или организации, которые активно вовлечены в проект, или чьи интересы могут быть затронуты в процессе или результате выполнения проекта. Они могут также оказывать влияние на цели и результаты проекта.

Цели проектной команды: должна идентифицировать Заинтересованные стороны, определить их требования и ожидания, и до возможной степени управлять их влиянием на проект для обеспечения его успешности

2-14

Взаимосвязь Заинтересованных сторон

Ключевые польз-ли

Конечные польз-

ли

Владельцы БП

СпонсорУправл.Партнер

Заинтересованные стороны

РП

Коорди-натор

проекта

Управляющий комитет

Исполнитель

Заказчик

Постав-щик



Заинтересованные стороны Заказчика• Спонсор

• Координатор проекта (Менеджер проекта со стороны

Заказчика)

• Владелец процессов

• Ключевой пользователь

• Конечный пользователь

• Руководитель проектной группы

• Представитель руководства

• Инвестор



Заинтересованные стороны Исполнителя• Управляющий партнер

• Менеджер проекта

• Руководитель проектной группы

– За функциональный блок

– За блок проектных работ (Тестирование, Обучение,

Подготовка данных)

• Член команды (разработчик, тестировщик, консультант)

• Представитель руководства

• Инвестор



Технический Комитет• Кто: эксперты в различных IT областях

• Интересы: работа такая, освоение новых знаний, углубление имеющихся

• Влияние: от правильного выбора методик, технологий, инструментария, оценки сложности продукта, алгоритмов зависит ход проекта

• Обязательства: помогает Менеджеру оценить техническую сложность проекта, оказывает консультации по всем тех. вопросам в ходе проекта, участвует в разработке архитектуры продукта.



Спонсор• Кто: Представитель руководства заказчика• Интересы: Получить запланированный эффект от

проекта• Влияние: принимает окончательное решения при

спорных ситуациях; утверждает изменения основных параметров проекта (бюджеты, сроки), определяет цели и идентифицирует выгоды проекта

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



Координатор проекта

• Кто: Менеджер Заказчика, назначенный долго набивать

шишки, за призрачную надежду кратковременного

почивания на лаврах

• Интересы: Оправдать оказанное доверие, обеспечить

получение максимально функционального и удобного

продукта за минимально возможный бюджет в

определенные сроки

• Влияние: управляет проектом совместно с Менеджером

проекта (Исполнитель); Организует работы Заказчика,

контролирует работы Исполнителя

• Обязательства: отвечает за достижение основных

параметров проекта



Владелец бизнес-процесса• Кто: руководитель функционального подразделения, эксперт

своей предметной области, детально понимающий БП предприятия в этой области и отвечающий за них

• Интересы: получить ПРОДУКТ, решающий необходимый круг задач

• Влияние: формирует требования к продукту, принимает результаты в своей функциональной области

• Обязательства: координирует работы по своему бизнес-процессу, формулирует требования к продукту, участвует в сборе и анализе и детализации требований, контролирует реализацию требований в ходе проекта, участвует в тестировании



Ключевой Пользователь• Кто: специалист своей предметной области, детально

понимающий БП предприятия в этой области, будущий ключевой пользователь продукта

• Интересы: получить УДОБНЫЙ В ИСПОЛЬЗОВАНИИ продукт, решающий необходимый круг задач

• Влияние: формирует требования к продукту

• Обязательства: формулирует требования к продукту, участвует в сборе и анализе и детализации требований, контролирует реализацию требований в ходе проекта, участвует в тестировании



Конечный пользователь

• Кто: будущий непосредственный пользователь продукта

• Интересы: получить УДОБНЫЙ ПРОДУКТ, максимально

упрощающий каждодневную работу

• Влияние: обеспечивает успешность функционирования новой

системы за счет корректного использования продукта

• Обязательства: обучается новому продукту



Управляющий комитет

• Кто: «Могучая кучка»: Спонсор проекта, Управляющий

партнер, Координатор проекта, Менеджер проекта, другие

ЗС, обладающие властью

• Интересы: Обеспечить нормальный ход проекта

• Влияние: Принятие, либо утверждение, всех ключевых

проектных решений

• Обязательства: Инициирование старта проекта и

фиксация его завершения



Заинтересованные лица

• Заказчики ≠ Пользователи

– Заказчик • платит за продукт

• должен быть убежден в ценности продукта, которая

определяется стоимостью и пользой для организации

– Пользователь• использует продукт

• должен воспринимать полезность продукта,

определяемую общей выгодой



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



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

Первый шаг в любом проекте – это

определение потребностей клиента, и,

зачастую, это делается небрежно. Теоретики

часто игнорируют тему выявления требований,

а практики покрываются холодным потом при

мысли о ней.



Выявление требований: Задача #1• Если не будут удовлетворены потребности реальных

пользователей, то продукт провалится.

• Первая задача при выявлении требований -

определить пользователей.

• Если у вас нет доступа к реальным пользователем,

то вы не сможете определить их потребности.

• Очень рискованно выявлять требования

пользователей, общаясь с ними на расстоянии или

через посредников.



Определение пользователей – 1

• Пользователем является тот, кто:

– будет регулярно взаимодействовать с продуктом;

– изменит подход к своей работе в связи с

использованием продукта;

– должен будет вводить данные или использовать

выходные данные продукта.



Определение пользователей – 2

• Определите приоритеты ВСЕХ заинтересованных лиц проекта и их потребности.

• Пользователи тем более важны, если– их много;– они используют систему очень интенсивно;– создают основную нагрузку на систему;– их ошибки стоят дорого.



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

• Выявление требований со стороны пользователей – это первый и самый сложный шаг, так как ошибки– распространяются неопределенно долго,– их очень сложно найти– и их очень сложно исправлять.

• Критически важные вопросы– что нужно делать пользователям (функция)– как бы они хотели это делать (характеристика качества)



Планирование процессавыявления требований• Создайте план выявления требований, чтобы

повысить шансы на успех и задать более

реалистичные цели.

• План должен содержать:

– цели выявления требований;

– стратегии и процессы выявления требований;

– результаты усилий по выявлению требований;

– оценки календарного плана и ресурсов;

– риски, связанные с выявлением требований.



Методы выявления требований Исследования

Фокус-группы – совместная разработка приложений

Ролевые игры

Интервью

Семинары

Прототипы

Варианты использования



Методы выявления требованийИнтервью• Ищите реальные причины («Зри в корень»)

• Сосредоточьтесь на проблеме

• Задавайте открытые вопросы (предполагают

развернутый ответ)– Ищите бизнес-контекст, процессы и системный контекст

• Задавайте вопросы, независимые от контекста

(Вайнберг, 1989)

• Записывайте, но также предлагайте идеи

• Что, если / Ожидания пользователей



Методы выявления требованийСеминары (рабочие группы)• Определите основные правила:

– Принципы работы группы.• Придерживайтесь границ проекта:

– Используйте правильный уровень абстракции;– Придерживайтесь темы обсуждения.

• Фиксируйте все на бумаге для дальнейшего использования.• Ограничивайте обсуждения по времени:

– обеспечьте равноценное обсуждение каждого вопроса.• Не увеличивайте размер команды и тщательно отбирайте участников:

– небольшие группы работают быстрее;– используйте несколько рабочих групп для различных групп пользователей.

• Вовлекайте в обсуждение каждого.– Будьте внимательны и следите за реакциями людей, жестикуляцией и

сигналами.



Создание прототипов • Что такое прототип?

• Для чего он используется?

– Для ответа на определенный вопрос...

• Какой вопрос?

– Для уточнения и завершение формулировки требований

– Для определения ожиданий и повышения

удовлетворенности заинтересованных лиц

– Для исследования альтернативных решений

– Для создания конечного продукта

– Для сокращение графика разработки

• Проверка правильности прототипов



Процесс разработки прототипа

План прототипировани

я

Структура прототипа

Действующий прототип

Отчет

Определение назначения прототипа

Разработка прототипа

Определение функ. возмож.

прототипа

Оценивание прототипа



Различные прототипы• Горизонтальные

– Поведенческие

– Макеты

– Исследуют поведение системы в тех или иных ситуациях

– Демонстрируют внешний вид пользовательского интерфейса и методы работы с системой

• Вертикальные

– Структурные прототипы или проверка концепции

– Исследование критически важных требований к интерфейсу, времени исполнения, а также для сокращения рисков на стадии проектирования системы

– Действует как настоящая система



Эволюционное и экспериментальное прототипирование

Первоначальные требования

Эволюционное прототипирование

Экспериментальное прототипирование

Готовая система

Прототип + системная

спецификация



Факторы успеха прототипированияКак сделать его эффективным?

• Включите создание прототипов в план проекта. Выделите время и ресурсы на разработку и прототипов.

• Формулируйте цель каждого прототипа до начала его создания• Планируйте разработку нескольких прототипов (ничего не

получается сразу с первой попытки – как блины).• Одноразовые прототипы создавайте как можно быстрее и

дешевле.• Не создавайте прототипы для требований, которые уже

понимаете (за исключением альтернативных вариантов)• При создании вывода на экран -- используйте правдоподобные

данные, чтобы не отвлекать пользователей, выполняющих оценку прототипа.

• Не используйте прототипы вместо документированной спецификации требований к ПО.



Создание прототиповРиски и их смягчение • Давление с целью выпустить одноразовый прототип как окончательный

продукт

– Используйте инструменты, отличные от производственной среды.

– Используйте бумажные прототипы, а не электронные.

• Фиксация пользователей на «как» вместо «что».

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

• Пользователи начинают делать выводы о производительности конечного продукта по производительности прототипа.

– Подумайте о реализации временных задержек, что будет более реалистично моделировать поведение конечного продукта.

• Создание прототипов отнимает слишком много времени

– Возможности прототипа должны обеспечивать только проверку понимания, отвечать на вопросы и уточнять требования.



Подход на основе вариантов использования (use case)• Вариант использования описывает набор взаимодействий

системы и внешнего действующего лица.

• Действующим лицом может быть человек, другая программная

система или аппаратное устройство.

• Понятие «вариант использования» возникло в ООП, но может

использоваться и в других проектах. Почему?

• Варианты использования изменяют подход разработки

требований: вместо того, «что должна делать система» на

подход «что должны делать пользователи».

• Диаграммы вариантов использования создают

высокоуровневое представление требований пользователей.



Преимущества вариантов использования

Помогает аналитикам и разработчикам понять как деятельность пользователей, так и предметную область.

Позволяет обнаружить неточности и неясности требований на раннем этапе.

Предотвращает появление «функций-сирот», которые никогда не используются, хотя и были реализованы.

Помогают задать приоритеты требований.

Если проследить варианты использования до уровня функциональных требований, то при изменении бизнес-процессов легче управлять каскадными изменениями.

Выявляют важные объекты предметной области и их взаимоотношения.



Основы вариантов использования

К важным элементам варианта использования относятся:

– Уникальный идентификатор

– Имя, явно описывающее задачу пользователя в формате «глагол + объект», например, «вставить файл»

– Краткое текстовое описание на обычном языке.

– Список предварительных условий, которые должны быть выполнены, прежде чем сможет начаться вариант использования.

– Выходные условия, описывающие состояние системы после успешного завершения варианта использования.

– Пронумерованный список действий, описывающий последовательность этапов взаимодействия пользователя и системы.



Определение вариантов использованияГ.Хэм и К.Ларман, 1998

Сначала определите действующих лиц, а затем – бизнес-

процессы, в которых они участвуют.

Определите внешние события, на которые реагирует

система, а потом свяжите эти события с определенными

действующими лицами и вариантами использования.

Опишите бизнес-процессы в терминах сценариев,

обобщите сценарии в варианты использования, и

определите действующие лица для каждого варианта.

Определите варианты использования на основе

существующих функциональных требований. Если какие-

либо требования невозможно проследить до какого-либо

варианта использования, подумайте - нужны ли они.



Вариант использованияГрафическое представление

Диаграмма UMLБанкомат

«Расширяет»

Сохраняет информациюоб остатке на счете

Проверяет баланссчета

Переводсо счета на счет

Обновление остаткана счете

Снимает наличные

Клиент

База данныхBank Teller

«Включает»

Банковский служащий



Вариант использованияДругое графическое представление

Выходные условия

Обычный ход выполнения

Диаграмма состояний KW135

Этап 1

Этап 2

Этап 3 Этап 2c

Этап 2b

Этап 2aУсловие

Предварительные условия

Альтернативный ход выполнения



От вариантов использования к функциональным требованиям• Варианты использования не являются функциональными требованиями

– Они описывают поведение систем с точки зрения пользователя.

– В них не отражается множество важных для разработки деталей.

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

связанных с вариантами использования:

– Только варианты использования

• Включает все необходимые функциональные требования в описание

каждого варианта использования.

– Варианты использования и спецификация требований ПО

• Необходимо только установить прослеживаемость между вариантами

использования и функциональными требованиями спецификации

требований ПО.

– Только спецификация требований ПО

• Необходимо выявлять дублирующиеся функциональные требования.



Варианты использования: ловушки применения Слишком много вариантов использования

Крайне сложные варианты использования

Включение интерфейса пользователя в варианты использования

Включение определения данных в варианты использования

Варианты использования, которые не могут понять пользователи

Новые бизнес процессы

Чрезмерное использование отношений «расширяет» и «включает»



Задание по вариантам использования



Классификация ввода пользователя



Как классифицироватьПросто слушайте…• Бизнес-требования

– Любая информация, описывающая рынок или какие-

либо бизнес-интересы

• Варианты использования или сценарии

– Мне нужно <сделать что-то>

• Бизнес-правила

– Должны соответствовать <некоторому правилу или

стандарту>

• Функциональные требования

– Поведенческие характеристики системы



Как классифицироватьПросто слушайте…• Характеристики качества

– Необходимые характеристики системы, насколько хорошо работает система.

• Требования к внешнему интерфейсу

– Связь между системой и всем остальным (оборудование/другое программное обеспечение/пользователи и т.д.)

• Ограничения

– Предопределенный дизайн и реализация, ограничивают возможности разработчика.

– <нужно использовать>, <должно быть написано с использованием>

• Определения данных

– Формат, типы данных, допустимые значение, и т.д. (собирайте их в словаре данных)

• Идеи по поводу решений

– Пароли, раскрывающиеся меню, и т.д.



Если услышанное не попадает ни в одну из категорий…

• Тогда это может быть…

– Требование, не относящиеся к разработке ПО

– Предположение

– Ограничение проекта

– Дополнительная информация (историческая,

описательная и т.д.)

– Требование к срокам



Характеристики качества



Кроме функциональных требованийХарактеристики качества

• Клиентам трудно их определить... и потому они обычно не

упоминаются

– У разных классов пользователей свои предпочтения.

• Подразумеваются заказчиками

• Существенны и значимы при выборе архитектурного

решения.

• Должны быть исследованы во время процесса выявления

требований при участии всех заинтересованных сторон (а

не только пользователей).

• Должны быть измеряемы и проверяемы



Рабочая группа по характеристикам качества – 1 • Создание такой группы – это дополнительный способ

выявления основных характеристик систем ПО, смысл которого в привлечении заинтересованных лиц (владельцы проекта).

• Основные особенности рабочей группы по характеристикам качества:– системно-ориентирована– сфокусирована на заинтересованных лицах– созывается до того, как завершено проектирование архитектуры

ПО



Рабочая группа по характеристикам качества – 2

1. Знакомство и представление рабочей группы

2. Представление бизнес-целей и задач

3. Представление плана архитектуры ПО

4. Определение ведущих элементов архитектуры

5. Сценарий «мозговой штурм»

6. Сценарий «консолидация»

7. Сценарий «задание приоритетов»

8. Сценарий «уточнение»

Повторите в случае необходимости с более широким кругом заинтересованных лиц



Рабочая группа по характеристикам качества – 3• Результат включает в себя:

– исходные сценарии

– сценарии характеристик качества с приоритетами

– уточненные сценарии

• Может использоваться для:

– уточнения требований

– планирования прототипов для уменьшения рисков

– проектирования архитектуры



“Не все, что можно сосчитать, учитывают, и не все, что учитывают, можно сосчитать."

Альберт Эйнштейн

Неверно для характеристик качества



“Если считаете, что знаете что-то о предмете, попробуйте описать его количественно. Если сможете, то, вероятно, вы что-то и знаете о нем. Но если нет, то, возможно, следует признаться себе, что знания ваши недостаточны и неудовлетворительны ..."

Лорд Кельвин, 1893



Характеристики качестваПреодоление проблем количественной оценки• Попробуйте использовать язык Planguage

• Используйте метрики, шкалы, значения min/max

• Определите приоритеты и предпочтения заказчиков

• Используйте известные стандарты (Методология метрик

качества программных средств IEEE 1061-1998)

• Стоит спросить у пользователей, что они считают неприемлемым.

• Плохая количественная оценка лучше чем никакая!!!



Характеристики качестваКакие они?

• Два основных метода классификации:– Воспринимаемые в период выполнения или нет

– Важные в первую очередь для пользователей или для разработчиков

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

Доступность ПоддерживаемостьЭффективность Легкость перемещения (портируемость)Гибкость Возможность повторного использованияЦелостность ТестируемостьСпособность к взаимодействию ПроизводительностьНадежностьУдобство использованияУстойчивость



Характеристики качества Матрица компромиссов

Положительные и отрицательные взаимосвязи характеристик качества



Характеристики качестваУпражнение



Бизнес правилаПочему мы об этом беспокоимся?

• У любого бизнеса есть правила:

– Корпоративная политика

– Промышленные стандарты

– Государственное регулирование• Большинство правил берут свое начало вне контекста какого-либо

определенного приложения

• Программные приложения часто должны обеспечивать выполнение

этих правил

• Бизнес правила – один из основных источников функциональных

требований к ПО, поскольку они определяют возможности, которыми

должна обладать система для выполнения правил

• Подумайте о возможности обслуживания ... когда правила изменятся



Классификация бизнес правил

http://www.businessrulesgroup.org/brglink.htm

ВыводыВычисленияАктиваторы операцийОграниченияФакты

Бизнес правила

Простые верные

утверждения о бизнесе

Ограничение действий

системы или пользователей

Правило, при определенных

условиях приводящее к выполнению каких-либо действий

Правило, устанавливающееновые знания на

основе достоверности определенных

условий

Выполняются с использованием математических

формул и алгоритмов



БизнесПравила

СистемныеРешения

СобытияЖизненные циклы объектов

Политики

МоделиДанных

Постановления

ФормулыРешения

Действующих лиц

Почему это необходимо делать таким

образом?

Как система узнает, что делать

дальше?

Что может произойти, а что – нет?

Что может пользователь предпринять

дальше ?

В результате чего меняется состояние

объекта?

Что требует правительство?

Как взаимосвязаны эти данных?

Как вычисляется это значение?



Бизнес правилаУпражнение



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



Основные виды

• К основным проблемам, которые встречаются

на стадии выявления требований, относятся

такие:

– проблема формулировки

– терминология

– неявные допущения

– предвзятые решения



Проблема формулировки – 1

• Многие заинтересованные лица (особенно

пользователи) не могут объяснить, что они

делают, или что им необходимо. Они

– помнят исключения и забывают порядок

действий

– не придают значения простым задачам

– сосредотачиваются на том, что не работает, а

не над тем, что работает

• Сформулированное мнение одного

пользователя может ввести в заблуждение

других и создать ложное единое мнение.



Проблема формулировки – 2

• Сложнее всего заинтересованным лицам

сформулировать требования к характеристикам

качества.

– Односложные описания, например, «изменяемый», не

несут никакого смысла• Как измерять изменяемость?

• Насколько важна изменяемость в отношении других

характеристик качества?

– «Изменяемость» одного участника – это

«масштабируемость» для другого.



Возможные решения – 1

• Наблюдение

– смотрите как работают пользователи

• Документирование

– требуйте от пользователей записывать свои действия

по мере их выполнения;

– требуйте от них записывать время, затрачиваемое на

выполнение задач.

• Разработайте вариант использования и сценарий

характеристики качества

– один описывает функцию, а другой описывает свойства

характеристики качества .



Возможные решения – 2

• Варианты использования описывают требуемую

функциональность.

• Сценарии характеристик качества описывают

требуемые свойства характеристики качества.

• Какое требование изменяемости имеет наибольший

смысл?

– «Система должна быть изменяемой.»

– «Модификация системы для использования другого

коммерческого пакета генерации дискретных

событий должна занимать 12 человеко-месяцев.»

2-77

Терминология

Заинтересованные лица (особенно пользователи) и разработчики говорят «на разных языках».

– При использовании специальных терминов специальным образом возникает особая культура.

– Разработчики должны понимать терминологию в контексте заинтересованных лиц и их работы.

• важно для понимания потребностей заинтересованных сторон



Возможные решения

• Специалист в прикладной области

– Привлеките специалиста в прикладной области, который

также обладает знаниями в программировании.

• Словарь прикладной области

– Создайте словарь ключевых технических терминов и их

определений перед выявлением требований.

• Тренинг по прикладной области

– Обучите программистов понятиям прикладной области

или наоборот.



Неявные допущения

• Вещи, которые «все знают», как правило, остаются

неупомянутыми.

– Очевидное может быть совсем не очевидным для

тех, кто не знаком со специальными знаниями

прикладной области.

– Систему, нарушающую важные допущения, ждет

провал.

• Все важные допущения должны быть явно

сформулированы и записаны, вне зависимости от

их очевидности.



Возможные решения

• Наблюдение за пользователями на рабочем месте

• Варианты использования

• Ролевые игры

– предложите не-экспертам просмотреть варианты

использования и проверить их полноту

• Прототипы

• Формальный анализ

– выделите требования в формальную спецификацию,

которую можно строго проверить на полноту



Предвзятые решения

• Некоторые заинтересованные лица считают, что

знают решения своих проблем.

• Иногда они описывают идею решения проблемы,

а не саму проблему• “Просто напишите код, в конце концов это лишь картинки,...”

• “Мне нужен процессор Pentium,...”

• Иногда они действительно знают ответы на свои

проблемы, но эти ответы могут быть не самыми

лучшими. – Их идеи могут быть незаконченными, устаревшими или вообще

неверными.



Возможные решения• Мозговой штурм

– просто выложите все на стол; очистите исходные данные – отделите проблемы от решений.

• Анализ причин– определите, почему пользователи хотят иметь каждую

функцию и свойство характеристики качества. • Фантазия

– предложите заинтересованным лицам описать идеальный продукт

• Прототипы



Анализ



Взаимосвязь видов требований



Роль анализа – 1

• Начальные требования имеют тенденцию описывать продукт очень расплывчато, например:

– кто будет использовать

– что пользователь хотел бы иметь

– в каком контексте это будет использоваться

– необходимость определенных функций и характеристик качества

• Расплывчатые желания и потребности должны быть уточнены в спецификации требований.




• Выявление требований – это расходящийся

процесс, который собирает все больше и

больше данных.

• Анализ требований – это сходящийся

процесс, который

– уточняет данные, а не собирает их

– структурирует информацию

– задает приоритеты потребностей




• Все функциональные требования,

характеристики качества и ограничения

должны быть

– прояснены – понятны всем заинтересованным

лицам

– количественно определены – измеряемы

– упорядочены – сгруппированы в соответствии с

важностью



Уточнение требований – 1

• Каждое исходное требование должно быть уточнено,

чтобы ясно выражать потребности и зафиксировать

все, что важно для дизайнеров и разработчиков

– Что требуется?

– Когда это требуется?

– Сколько требуется?

– Насколько сильно это требуется?

– На какое время это требуется?

– Какова вероятность изменения потребности со

временем?



Уточнение требований – 2

• Уточнение и прояснение требований может показаться

немного похожим на процесс выявления. Уточнение

требований:

– требует повторных встреч с заинтересованными лицами

– может быть медленным, но должно сойтись в одну точку

• Если вы генерируете много новых требований, то возможно

необходимо вернуться к этапу выявлению требований

– К работе привлечены нужные/прежние заинтересованные

лица?

– Произошли ли какие либо технологические,

организационные, кадровые или операционные изменения?



Количественное описание

• Исходные требования имеют тенденцию быть

неточными и некачественными

– Необходимо иметь возможность установить,

соответствует ли продукт требованиям

• Спецификации требований должны отвечать на

вопросы «насколько большой», «насколько

быстрый», «насколько часто» и т.д.

– Если это не так, то вы создаете предпосылки для

провала проекта и разочарования заинтересованных

лиц



Пример: УточнениеКоличественное описание

• Исходное требование: “Система должна быть

интуитивно понятна в использовании.”

– Данное требование невозможно проверить.

• Интерфейс системы должен обеспечивать:

– изучение пользователями до уровня 90% опытности

за 2 недели

– средний уровень ошибок пользователя менее 2%

– уровень не менее 85% при тестировании на степень

удовлетворения пользователей



Приоритеты• Некоторые требования важнее других

– срочно требуется некая функциональность

– некие характеристики качества крайне важны

– некоторые требования трудно исполнимы

• Задание приоритетов в спецификации

существенно важно для– задания ожиданий, обсуждения технических

компромиссов, планирования разработки



Шкалы приоритетовВсе это о классификации• Категории

– высокая, средняя, низкая– обязан, должен бы, мог бы– основной, полезный, желаемый– необсуждаемый, обсуждаемый, гибкий– прямо сейчас, чуть позже, когда-нибудь

• Два измерения– Важность / Срочность

Важно Не важно

Срочно

Не срочно

Высший приоритет

Средний приоритет

Не тратьте время

Минимальный приоритет



Определение приоритетов

• Должны участвовать все заинтересованные

лица проекта

• Все требования не могут быть основными

• Попробуйте получить неформальное

соглашение о приоритетах

• Пересматривайте и изменяйте приоритеты по

мере развития анализа и дизайна



Неучтенные требования

Посмотрим видео-клип



Как понять, что сбор требований завершен?• Выявить требования полностью невозможно, однако

следующие признаки подскажут, что источники сведений почти иссякли:– пользователи не могут придумать какие-либо еще варианты

использования

– пользователи повторно описывают уже обсуждавшиеся проблемы

– предлагаемые новые функции, пользовательские или функциональные требования выходят за рамки проекта

– вновь предлагаемые требования имеют низкий приоритет

– предлагают новые возможности, которые должны быть реализованы «когда-либо позже» в ходе жизненного цикла продукта



Поиск неучтенных требований

• Самый распространенный недостаток

требований (Jones 97’)

• Обнаружить их очень трудно, поскольку они

просто невидимы!

• Остерегайтесь аналитического паралича: не

тратьте слишком много времени на

выявление требований, пытаясь не упустить

ни одно из них.



Поиск неучтенных требованийПрактические методы

Разбейте требования высокого уровня на составляющие, чтобы точно

определить, что же именно просят пользователи.

Собирайте информацию у ВСЕХ классов пользователей.

Проверьте, что КАЖДЫЙ вариант использования имеет как минимум

одно действующее лицо.

Проследите системные требования, варианты использования и бизнес

правила до их подробных функциональных требований, чтобы

убедиться, что все необходимые функции были определены.

Для выявления недостающих требований проверяйте граничные

значения.

Представляйте информацию о требованиях несколькими способами.

Представляйте сложную логику (например, булеву логику) с помощью

таблиц и деревьев решений.



Все требования собраны?



Выводы• Двумя ключевыми участниками процесса выявления требований

являются сторонник продукта и аналитик требований

• Варианты использования не являются функциональными требования, но они помогают описать поведение системы с точки зрения пользователя.

• характеристики качества могут и должны быть измерены (вопреки расхожему мнению)

• Бизнес-требования влияют на функциональные требования и должны быть определены во время процесса выявления требований

• Задание приоритетов предназначено для ответа на определенные вопросы или доказательства концепции

• Задание приоритетов можно сделать разными способами, но каким бы способом вы не делали это, не делайте это в одиночку.



Литература

• Exploring Requirements: Quality

Before Design, Gerald Weinberg

and Donald Gause, 1989

• Вигерс К.И. Разработка

требований к программному

обеспечению. Перевод с англ. –

М.: Русская редакция, 2004.



Вопросы?

Download - L2 requirements

Top Related