l1 requirements

1Software Engineering Professional Program © 2007.

T E K A M A1-1

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


Software Engineering Professional Program © 2007.

T E K A M A1-2


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

Составление требований

Управление требованиями

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

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


T E K A M A1-3


Границы

Требования

Изменения

Проект

Изменения

Пересмотренный вариантТекущий вариант

Рабочая редакция требований

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

Управление требованиями

Маркетинг, менеджмент, потребители

Инфраструктура проекта

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

Анализ, спецификация, уточнение, обсуждение

требования

маркетинг, менеджмент, потребители


T E K A M A1-4


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

Посмотрим клип


T E K A M A1-5


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

Фредерик Брукс

Проблема


T E K A M A1-6


Проблемы, возникающие при определении требований• Разработка требований – самая сложная часть

создания ПО

– Неточность и расплывчатость; в результате:• нельзя или очень сложно программно реализовать;

• применимы только «слабые» методы.

– Нужны высококлассные специалисты, которые

одновременно обладают компетенцией аналитика и

программиста.• Редко встречаемая комбинация профессиональных качеств.

• Сложно выделить функциональную группу с такой

квалификацией.


T E K A M A1-7


Проблемы, возникающие при определении требованийПродолжение

• «Ползущие» требования пользователей

• Неясность и двусмысленность

• Минимальная определенность спецификации

• Категория пользователей не может

представить адекватную информацию

• Неточное планирование

• «Золочение» требований

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


T E K A M A1-8


Наш опыт

• Слушатели курса «Управление ожиданиями

заинтересованных сторон» TEKAMA в более

чем 70% случаях причиной неудачных

проектов в их практике называют неверные,

несогласованные, плохо управляемые

требования!


T E K A M A1-9


Наблюдение №1

Ось «шаманства» в цикле разработки ПО

Шаманство

Инженерия

ТребованияАрхитектура Детализированн

ая архитектура

Программная реализация


T E K A M A1-10


Наблюдение №2• Считается, что разработка требований – это

мало увлекательное занятие:

– Много «слов» для «технарей»

– Скучно для «гуманитариев»

– Требует упорства и кропотливости

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

– Не интересно для исследователей


T E K A M A1-11


Совершенная команда разработки требований• Менеджмент и поддержка

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

по IT поддержке

• Техническая компетенция

– системный архитектор, модульный архитектор, операционная

деятельность, отраслевая команда

• Представители заказчика

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

И каждый в процессе разработки требований сделает все как

надо от самого начала и до самого конца...


T E K A M A1-12


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

проектной командой.

• Реорганизация команды: старые участники ушли, а у новых - другие идеи.

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

• Менеджмент не подключен.

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

И есть ли здесь техническая проблема?!


T E K A M A1-13


Требования


T E K A M A1-14


Что такое требование*

• Обычное определение

– Что-то, что должен уметь делать продукт или

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

• Дополняющие определения

– Нечто, что вы должны определить перед началом

разработки продукта.

– Соглашение, которое должны выработать заказчик

и исполнитель, по поводу того, что система

должна делать.

* Charlene Gross, SEI


T E K A M A1-15


Определение требованийIEEE 1990

1. Условие или возможность необходимые пользователю

для решение его задачи или достижение цели.

2. Условие или возможность, которым должна отвечать или

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

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

или иной формальный документ.

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

возможности, указанное в (1) или (2).


T E K A M A1-16


Требование

• Требование – это четкое описание– цели и назначения программного обеспечения;

– и того, что должно делать ПО для реализации своего назначения.

• Первичные требования обычно представляют позицию пользователя ПО– Они функционально ориентированы.

– Неформализованные и неполные.

– Должны быть переработаны.


T E K A M A1-17


Ограничение

• Архитекторы и разработчики не имеют достаточной

свободы действовать по собственному усмотрению:– предопределенное архитектурное решение;

– правила и стандарты;

– бюджет и сроки сдачи.

• Это ограничение на то, как архитекторы и

разработчики будут удовлетворять требования. – Ограничение сужает варианты выбора.


T E K A M A1-18


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

• Очень давно разработчики осознали важность архитектуры ПО

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

– производительности,

– работоспособности,

– модифицируемости и многим другим.

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


T E K A M A1-19


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

СкоростьКол-во выполненных транзакций в секунду;Время реакции на действие пользователя;Время обновления экрана

РазмерКилобайты;Кол-во модулей памяти

Простота

эксплуатации

Время обучения персонала;Кол-во статей в справочной системе

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

ОтказоустойчивостьВремя восстановления после сбоя;Процент событий, приводящих к сбоям;Вероятность порчи данных при сбоях

ПереносимостьПроцент машинно-зависимых операторов;Кол-во машинно-зависимых подсистем


T E K A M A1-20


Типы нефункциональных требованийНефункциональные

требования

Организационные требования

Выходные требования

Требования на

реализацию

Требования на стандарты

Внешние требования

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

Этические требования

Юридические требования

Требования о сохранении

конфиденциальности

Требования по технике

безопасности

Требования к надежности

Требования к продукту

Требования к эксплуатации

Требования к переносимости

Требования к эффективности

Требования к производительности

Требования к памяти


T E K A M A1-21


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

реакции на запросы, поведения в определенных ситуациях; а

также, что система не должна делать.

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

окружения, а не поведение; плюс ограничения.

• Требования предметной области: характеризуют предметную

область, где будет эксплуатироваться система. Могут быть

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

• Не всегда можно разделить функциональные и

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


T E K A M A1-22


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

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

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

• Системные требования – более

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

пользовательских требований. Обычно, это

основа для заключения контракта на

разработку системы.

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


T E K A M A1-24


Нет смысла вдаваться в детали, если

неизвестно о чем идет речь.

Джон Фон Нейман


T E K A M A1-25


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

Пользователю должны быть предоставлены

следующие возможности:

– Скорость передачи данных – не менее 2Мб/с;

– Пользовательский интерфейс совместим с Win98;

– При потери связи, восстанавливается ранее

сохраненное состояние.


T E K A M A1-26


Что не является требованием

• Детали архитектуры

• Детали реализации

• Сведения о планировании

• Сведения о тестировании

• Любые указания по проектной информации

– Бюджет

– Время

– Инфраструктура разработки


T E K A M A1-27


Стоимость требований


T E K A M A1-28


Стоимость «хороших» и «плохих» требований• Плохие требования

– Переделывание может обойтись в 30-50% от общей стоимости разработки (Боэм).

– На устранение ошибок в требованиях приходится 70-85% бюджета переделок (Леффингуэлл).

• Хорошие требования– Последние исследования показали, что успешные компании

тратят на разработку требований 28% своих ресурсов и 38,5% человеко-часов (Хофман).

– Европейское исследование показало, что компании, которые тратят вдвое больше усилий на разработку требований, чем остальные (а среднее значение по индустрии - 14%), разрабатывают продукт быстрее.


T E K A M A1-29


Распределение ошибок в разработке ПО

Источник дефектов

Вероятность возникновения*

Эффективность устранения

«Поставляемые» дефекты*

Требования 1,00 77% 0,23

Дизайн 1,25 85% 0,19

Кодирование 1,75 95% 0,09

Документация 0,60 80% 0,12

Исправление ошибок

0,40 70% 0,12

Итого 5.00 85% 0,75

Jones, Capers. 1994. "Revitalizing Software Project Management." American Programmer 6(7), pp. 3–12.


T E K A M A1-30


Распределение ошибок в разработке ПО

Источник дефектов «Поставляемые» дефекты

% к числу «поставляемых»

дефектов

Требования 4,6% 30,67%

Дизайн 3,8% 25,33%

Кодирование 1,8% 12,00%

Документация 2,4% 16,00%

Исправление ошибок 2,4% 16,00%

Итого 15% 100%


T E K A M A1-31


Цена ошибки

Приемка

Поддержка

Тестовые сценарии

Программный код

Архитектура

Требования.1-.2

.5

1

2

5

20

200:1 Масштаб


T E K A M A1-32


Пример переделыванияЛеффингуэлл 1996-7

Представьте приложение, в котором 50,000 строк кода. Он

разрабатывается командой из шести программистов, одного менеджера

проекта, двух тестировщиков и одного аудитора качества. Для

определения сроков разработки предположим, что написание кода – это

критический путь (и это, вероятно, справедливо для большинства

компаний!). Исходя из продуктивности в 350 строк отлаженного кода в

месяц, расчетное время разработки составит 24 месяца: т.е. 50,000 строк,

350 строк/месяц, 6 человек. При затратах в $10,000 на каждого участника

разработки в месяц, общий бюджет проекта составит порядка 2.4

миллионов долларов. При такой стоимости, даже если в лучшем случае

30% всего бюджета проекта будет потрачено на переписывание кода, то

цена переделывания – $720,000. Если 70% от этой суммы тратится на

устранение ошибок, возникших при составлении требований, то их

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


T E K A M A1-33


Пример переделыванияЛеффингуэлл 1996-7

Количество строк кода 50,000

Число разработчиков 6

Человеко-месяцы написания кода 142.9

Время готовности продукта 24 месяца

Затраты на работника в месяц $10,000

Общая стоимость разработки $2,400,000

Общая стоимость переделывания (30%) $720,000

Общая стоимость устранения ошибок ТЗ

»70%)

$504,000


T E K A M A1-34


ROI при снижении ошибок в требованиях

Снижение кол-ва ошибок в требованиях (%)

Экономия средств в типовом проекте Сокращение сроков готовности (месяцы) Время возврата инвестиций (месяцы)

Окупаемость инвестиций в Первом проекте (%)

10%

$50,400

1.0

9.5

153%

20%

$100,800

1.7

4.7

407%

40%

$201,600

2.5

2.4

913%

Вариант 1 Вариант 2 Вариант 3

Коэффициент возврата инвестиций при различной эффективности управления требованиями


T E K A M A1-35


Характеристики хороших требований

Достаточность

Корректность

Осуществимость

Необходимость

Ранжируемость

Однозначность

Проверяемость


T E K A M A1-36


СамоконтрольПроверим как вы усвоили материал


T E K A M A1-37


Вопросы ?


T E K A M A1-38


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

требованиями– http://www.processimpact.com/– http://www.rspa.com/spi/reqmengr.html– http://www.ida.liu.se/labs/aslab/people/joaka/re_bib.html– http://interactive.sei.cmu.edu/Features/1999/March/Links/

Links.Mar99.htm– http://www.complianceautomation.com/

• Вигерс К.И. Разработка требований к программному

обеспечению. Перевод с англ. – М.: Русская редакция,

2004.

l1 requirements

Education

software project management

charlene gross

american programmer