Инжиниринг требований

®

IBM Software Group

© 2008 IBM Corporation

Превращая создание продукта в конкурентное

преимущество:

Инжиниринг требований

Анатолий Волохов,Software Group, Rational-Telelogic Solutions,

[email protected]

IBM Software Group | Rational software

22


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

Are we solving the right problem ?

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

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

с технологическим экспертам

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

Осмысление

Анализ

Are we solving the problem right ?Систематизировать и структурироватьтребования, строить взаимоотношения между ними, используя атрибутику, линкование и трассировку. Контролировать и анализировать изменения иуправлять ими

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

Приоритезация

Реализация

Анализ

Инициализация

Инжиниринг требований = Формирование требований + Управление требованиями


23


Потреб-ности рынка

Требованиявысокого уровня

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

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

требования

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

Спецификация изделия Спецификация изделия

Структурныетребования

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

� Требование - есть единичнаязадокументированная необходимость

� Требование - описание того, какимдолжен быть определенный продукт(или сервис)

�Функциональные требования описываютточное поведение (функционирование) системы, т.е. - «что система должнаделать»

�Нефункциональные требования описываютнасколько хорошо это поведение должноисполняться (но избегайте слова – как)

� Требования ведут нас через весьпроцесс разработки продукта

Что такое “требование” ...


24


Что такое «требования» ...

� Список фактических задач группы, работающейнад проектом (TO-DO list)

� Список того, ЧТО хочет получить заказчик

� Описание того, ЧТО должна делать система,чтобы удовлетворить пользователей ибизнес-потребности

� Перечень того, КАКИЕ компоненты должны бытьреализованы:

�hardware & software

�процедуры и регламенты

� Описание того, ЧТО каждый компонент ДОЛЖЕН ДЕЛАТЬ иКАК компоненты будут ВЗАИМОДЕЙСТВОВАТЬ

Требования – это :

� Список фактических задач группы, работающейнад проектом (TO-DO list)

� Список того, ЧТО хочет получить заказчик

� Описание того, ЧТО должна делать система,чтобы удовлетворить пользователей ибизнес-потребности

� Перечень того, КАКИЕ компоненты должны бытьреализованы:

�hardware & software

�процедуры и регламенты

� Описание того, ЧТО каждый компонент ДОЛЖЕН ДЕЛАТЬ иКАК компоненты будут ВЗАИМОДЕЙСТВОВАТЬ


25


Как «распилить»систему на подсистемы

и компоненты?

Что хочетполучитьзаказчик ?

Кто и что будетразрабатывать ?

Кто будетпользователем

системы ?

Следствие:

За последующие исправлениявсе равно придется расплачиваться

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

Как бы не забыть проинтерфейсы сопряжения...

Решения, принимаемые на ходу, не могут быть оптимальными


26


Признаки хорошего требования

� Корректное с технической и юридической точек зрения

� Полное выражать утверждение или законченную идею

� Четкое, однозначное недвусмысленное и не сбивающее с толку

� Совместимое согласующееся и не конфликтующее с другимитребованиями

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

� Трассируемое уникально идентифицированное и отслеживаемое

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

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

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

� Позитивное сформулировано в утвердительной форме

Каждое индивидуальное требование должно быть:


27


Как создавать хорошие требования...

� Каждое требование должно выглядеть как законченное предложение, содержащееподлежащее и сказуемое, и при этом отражать:�предметную принадлежность (требование относится к пользователю или к системе)

�содержать утверждение (логическое условие, действие, предполагаемый результат)

� Необходимо использовать :�либо глагол должен, когда требование является обязательным,

�либо глагол может, когда требование является дополнительным или факультативным

�возможны и вариации этих глаголов, но при соблюдении смысловых мер предосторожности

� Законченное требование должно точно формулировать конечную цель

или определять желаемый результат

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

невозможно контролировать то, что нельзя измерить


28


r572

Наибольшая проблема – суметь прописать ВСЕэти составляющие для КАЖДОГО требования,

которое вы формулируете

Анатомия хорошего требования пользователя

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

Неподготовленный пользователь должен иметьвозможность создать отчет менее, чем за 3 минуты

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

Используетсяопределенный глагол

Декларируется позитивныйконечный результат

Измеряемый критерийпроизводительности


29


Почему требования должны быть структурированы?

� Контекст - общие характеристики среды, к которой относятся требования

�Позволяет охватить взглядом всю картину целиком

Требования должны быть структурированы, чтобы можно было увидеть:

Помните эффект домино??Это начинается здесь!!!

� Дублирование требований�Одна и та же работа может выполняться дважды

�Возможно возникновение конфликтных ситуаций на стадии разработки

�Значительное удорожание стоимости поддержки продукта в последующем

� Пропуск требования�Отсутствие требования ведут к потере функциональности

�Может привести к изъянам в области реализации нефункциональных требований (напр., производительность, надежность, простота использования и т.д. – которые практическиуже не поддаются исправлению, если проект завершен и система создана.


30


Возможности:

• Что заказчик хочет от системы

– “Мне нужно устройство, которое обеспечивало бы полив моих посевов”

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

– “ежедневно... и все поля...”

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

• Все, что связано с запретами, лимитами и сдерживающими факторами

• Налагаемые извне – обычно обязательные (стандарты, правила, законы)

– “Но скважина не может выдавать больше 1000 литров воды в час”

• Налагаемые заказчиком – часто не очень обязательные

– “Поэтому хотелось бы использовать мощности имеющихся

оросительных каналов”

«Хочу» против «могу»...


31


Пользователь #1. Оглавление документа с требованиями

1.0. Общее описание

1.1. Характеристики продукта

1.2. Контекстные или системныедиаграммы и схемы

1.3. Условия эксплуатации

1.4. Характеристики пользователя

2.0. Допущения и зависимости

3.0. Специфические требования

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

3.2. Нефункциональные требования(в порядке важности)

4.0. Верификационные замерыи проверки

5.0. Заметки(информация, не имеющая

отношения к требованиям)

3.0. Специфические требования


32


Пользователь #2. Типы документов с требованиями

� Business Requirements Document (BRD)

� Market Requirements Document (MRD)

� User Requirements Document (URD)

� Statement of Work (SOW)

� Operational Concept Document (OCD)

� Interface Control Document (ICD)

� System Requirements Specifications (SRS)

� Technical Requirements Specification (TRS)

� Constrains & Restrictions Document (CRD)

BRD

SRS

TRs

GRs

� Constrains & Restrictions Document (CRD)


33


Эффективное формирование требованийосновывается на совместной работе, объединяющей различные точки зрения

Используйтеграфику и связи

для структуризацииинформации

Используйтедискуссии для

общения

Стройте модели идетализируйте их

Фиксируйте предлагаемыерешения для будущих

проработок

Устранитенепонимание -используйте

общий глоссарий

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

Координация

совместной

деятельности


34


r572

Пользователи ЗаказчикиБизнес

Эксплуатация Обучение

Источники требований.Сложные системы получают требования из многих источников

Help Desk

Принимайте во внимание мнение ВСЕХ возможных пользователей. Даже ОДНО неучтенное требование может привести к большим

проблемам или печальному результату

Конкуренты

Sales


35


Совет: как создавать требования

� Принимайте во внимание различные источники (внутренние, внешние, Web).Идентифицируйте типы и группы пользователей. Общайтесь с каждым.

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

� Записывайте каждое требование как полное предложение, сформулированное вутвердительное форме

� Не забывайте о прошлых ошибках и старайтесь обойти их хорошими и простымиальтернативными вариантами требований

� Постарайтесь выяснить природу возникновения требования. Не стесняйтесь на некоторые требования заказчика спросить - ПОЧЕМУ?

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

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


36


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

�

� Текущий статус проекта никогда не ясен до тех пор, пока мы не поймем, что ужеопаздываем и не укладываемся в плановый график

� Создается впечатление, что техническое задание всегда изменяется в самоенеподходящее время

� Изменения требуют много внимание и времени и обходятся нам очень дорого

� У нас в компании большие проблемы в общении между подразделениями – труднопонять кто, что хочет и почему

� Довольно часто случается, что нам приходится переделывать наш продукт, чтообходится в немалую копеечку..

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

� У нас нет полной уверенности в том, что наши тесты проверяют все модули иподсистемы продукта

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

� Процесс тестирования требует слишком много времени и денег

� В свои требования наши заказчики зачастую закладывают и решение

� Мы испытываем большие трудности при попытке организовать требования вуправляемую и контролируемую группу


37


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

� Информированность – ясное понимание целей и задач разработки

� Прозрачность – руководство может видеть общую картину и статус проекта

� Тестируемость – известно что тестировать, чтобы сдать продукт заказчику

� Интеграция – все отдельные блоки и модули наконец-то работают вместе

� Трассируемость – прозрачность отношений между требованиями

� Управление изменениями – оценка последствий вносимого изменения

� Оптимизация – разрабатываем и поставляем только то, что заказывалось

� Качество – мы хорошо понимаем, как много это значит для бизнеса

� Удовлетворение - заказчик и бизнес получают то, что хотели

� Соответствие – демонстрация соответствия нормативным документам

� Анализ - возможность оперативного принятия решений


38


Интеграционное

и модульное

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

Архитектурный

дизайн

Приемочные

тесты

Системное


Промышленные

стандарты

Системные


Требования

заказчика

Нормы и

правила

Соответствует

Подчиняется

Тесты

Тесты

Тесты

Реш

ает

Запрос на

изменение

Реш

ает

Анализ влияния (Impact Analysis)


39


Интеграционное

и модульное


Архитектурный

дизайн

Приемочные

тесты

Системное


Промышленные

стандарты

Системные


Требования

заказчика

Нормы и

правила

Соответствует

Подчиняется

Тесты

Тесты

Тесты

Реш

ает

Трассировка (Traceability Analysis)

Тест324 не

пройден ...

Реш

ает


40


Как это выглядит в AIRBUS

С 2003 года System Engineering называется в Airbus - Requirements Based Engineering

Процессы и методыВремяОрганизация Стоимость

Обучение

Подготовкапроизводства Методические

инструкции

Аттестация

Безопа-сность

Специфи-кации ихаракте-ристики

Тех. поддержка

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

Производство

СертификацияПриемочныеиспытания

Эксплуатация

Контроль ипроверкадизайна

Жизненный цикл изделия


41


Как это выглядит в BAE SYSTEMS


42


Использование инжиниринга требований имеет своинеоспоримые преимущества

� Почти 100% проектов стали выполняться точно в срок

� Ушли проблемы с перерасходом бюджета

� Значительно уменьшилось количество исправлений (right first time)

� Заметно увеличилась процессная, методологическая, инструментальная и персональная эффективность в инжиниринге

� Снизился риск появления дефектов

� Инжиниринг требований стал рассматриваться как конкурентноепреимущество

Обычно

Лучшие практики

3%

Требования Анализ \ Дизайн Разработка Ввод в эксплуатацию

27% 55% 15%

20% 13% 22% 5%30-50%

Экономия времени

The US Air Force Academy

Инжиниринг требований


43


� Совершенствование цикла разработки современнойсистемы управления ракетным вооружением Tomahawkпри использовании Requirements Management

При отсутствииImpact Analysis,

большинство измененийпопросту принималось

Теперь проведениеImpact Analysis - вопрослишь нескольких минут

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


44


� Качество:полное соответствие результата

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

• Цель управления требованиями:

- поставка качественного продукта- в соответствии с графиком,

- в рамках выделенного бюджета, - отвечающего исходной спецификации,

с полной уверенностью, что все

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

проконтролированы и выполнены

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

�


45


45

© Copyright IBM Corporation 2008. All rights reserved. The information contained in these materials is provided for informational purposes only, and is provided AS IS without warranty of any kind, express or implied. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, these materials. Nothing contained in these materials is intended to, nor shall have the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM software. References in these materials to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates. Product release dates and/or capabilities referenced in these materials may change at any time at IBM’s sole discretion based on market opportunities or other factors, and are not intended to be a commitment to future product or feature availability in any way. IBM, the IBM logo, Rational, the Rational logo, Telelogic, the Telelogic logo, and other IBM products and services are trademarks of the International Business Machines Corporation, in the United States, other countries or both. Other company, product, or service names may be trademarks or service marks of others.

Анатолий Волохов

[email protected]

Инжиниринг требований

Education