1 УПРАВЛЕНИЕ ТРЕБОВАНИЯМИ Корнипаев И.А.

2 Зачем нужны требования? Требования это то что необходимо сделать Требования нужны чтобы получить «правильный» продукт для выхода с ним на рынок в подходящее для этого время

3 ЦЕЛЬ КУРСА Помочь вам делать успешные проекты! … с помощью требований!

4 Программа курса Введение в требования Общий процесс разработки требований Требования и моделирование Практические аспекты разработки требований Аспекты управления разработкой требований Управление требованиями в различных проектных методологиях Средства управления требованиями

5 Введение в требования Когда человек не знает, к какой пристани он держит путь, для него ни один ветер не будет попутным. Сенека (Seneca) Луций Анней (3 до н.э. - 65)

6 Ключевые факторы появления новых продуктов Теоретическая возможность построения сколь угодно сложных систем Быстрое распространение Готовые модули

7 В чем проблема? Процент успешных проектов Запланировано гораздо больше чем удалось сделать Превышения бюджета Выполнена ненужная работа Источник: The Standish Group % Успешных 46% Частично успешных 28% Неудачны (провалы) 69% Превышение бюджета 79% Превышение сроков $75bn Стоимость провальных проектов $22bn Стоимость превышения бюджета 45% Функций систем никогда не используется !!!

8 Причины провалов Неполные или неоднозначные требования Низкое вовлечение пользователей в проект Недостаточно ресурсов Нереалистичные ожидания Недостаточная поддержка руководства Постоянно изменяющиеся, нестабильные требования Плохое планирование Проект перестает быть нужным Размер и сложность проекта Часть причин провалов проектов связаны с управлением проектом, часть причин связано с требованиями, но ни одна из причин не является технической

9 Области применения требований Планирование Управление рисками Приемочное тестирование Управление объемом проекта Управление изменениями

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

11 Требования и качество Качество – есть соответствие цели или соответствие требованиям – это обеспечение того, что удовлетворяет потребителя и в тоже время гарантирует, что нужды всех заинтересованных сторон учтены.

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

13 Роль требований на каждом уровне реализации проекта

14 Требования и моделирование Моделирование необходимо аналитику: Как средство для обсуждения требований и их реализации с заинтересованными сторонами Для анализа разрабатываемой системы, чтобы убедиться в наличии требуемых системных свойств Для перехода между различными уровнями требований

15 Требования и тестирование Тестирование системы: –Приемочное тестирование –Функциональное тестирование –Нагрузочное тестирование и измерение производительности –Модульное тестирование Тестирование требований: –Проверки (review) –Формальные инспекции –Анализ требований с помощью моделирования –Согласования

16 Область проблем и область решения Уровень требований Область Точка зрения Цель Требования заинтересованных сторон Область проблем Представитель заинтересован ной стороны Определяет что различные заинтересованные стороны желают достичь. Следует избегать конкретных решений. Системные требования Область решения Аналитик Абстрактно определяет как система будет удовлетворять пользовательским требованиям. Следует избегать точных описаний реализаций предлагаемых решений. Системные спецификации (архитектура системы) Область решения Архитектор Определяет как конкретная архитектура системы будет удовлетворять системным требованиям.

17 Когда нет описания проблем недостаточное понимание настоящих проблем; невозможность определить рамки системы, и понять, что нужно включать, а что нет; преобладание разработчиков и исполнителей в дискуссиях о системе, поскольку единственное описание, существующее для системы, описывает ее в терминах реализации; невозможность нахождения наилучшего решения, из-за ограничений свободы в выборе решения.

18 Заключение Требования – это и компас и карта

19 Общий процесс разработки требований Если вы не можете описать то, что вы делаете в виде процесса, значит, вы не знаете что вы делаете. Уильям Эдвардс Деминг, консультант по управлению, 1900–93

20 Обобщенный процесс разработки системы

21 Общий процесс разработки требований

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

23 Анализ и моделирование

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

25 Общий процесс для «идеального мира»

26 Общий процесс для «реального мира»

27 Информационная модель общего процесса

28 Статус согласования

29 Статус проверки

30 Статус удовлетворения

31 Запрос на изменение Запрос на изменение меняет все три статуса Необходимо учитывать «волновой» характер изменений Статус удовлетворения исходных требований должен находиться в соответствии со статусом согласования производных требований

32 Оценка требований Является ли требование полным? Является ли требование ясным? Является ли требование выполнимым? Является ли план проверки понятным и приемлемым?

33 Причины отклонения требований Отсутствует часть информации – документах встречаются места оставленные для заполнения в дальнейшем (в документах на английском языке встречаются пометки типа TBA (to be agreed) – необходимо согласовать, TBC (to be complete) – необходимо завершить, TBD (to be decided) – необходимо принять решение). Недостаточно ясности – неоднозначность, противоречивость, путаница и т.д. Невозможно реализовать – никто не знает то, как это сделать. План проверки неприемлем.

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

35 Анализ и моделирование

36 Получение требований и стратегии проверки

37 Действия характерные для каждого уровня согласование исходных требований с заказчиком; анализ исходных требований для определения рисков и потенциальных проблем, связанных с удовлетворением требований; создание одной или нескольких моделей для исследования возможных стратегий получения производных требований; Формирование производных требований при помощи результатов моделирования и анализа; разработка стратегии проверки производных требований; согласование производных требований с командой (командами) ответственными за их реализацию; установление связей типа «удовлетворяет» между входными и производными требованиями; установление связей типа «проверяет» между производными требованиями и соответствующей стратегией проверки.

38 Атрибуты требований Требования характеризируются его тремя атрибутами (свойствами): –согласованность; –удовлетворенность; –проверяемость. Идеальное состояние любого требования в любой системе заключается в том, что это требование: –согласованно между заказчиком и исполнителем; –имеет согласованную стратегию его проверки; –удовлетворяется требованиями более низкого уровня (или спецификацией системы).

39 Требования и моделирование Метод это перекресток, на котором встречаются искусство и наука. Эдуард Булвер-Литтон, поэт, 1803–73

40 Моделирование Можно смело утверждать, что моделирование это самая творческая часть работы аналитика или системного инженера. На практике не существует единственного «правильного» решения, поэтому модели меняются и развиваются на протяжении этапов разработки. Хорошая модель, это модель, помогающая общению. Модель может описывать структуру целой организации, или всего лишь одно определенное системное требование.

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

42 Наиболее распространенные нотации Диаграммы потоков данных Диаграммы сущность-связь Диаграммы состояний Объектно-ориентированные нотации

43 Методы основанные на перспективах Контролируемое формулирование требований (Controlled Requirements Expression (CORE)) Техника структурного анализа и проектирования (Structured Analysis and Design Technique (SADT)) Определение требований основанное на перспективах (Viewpoint-oriented Requirement Definition (VORD))

44 Объектно-ориентированные методы ООА ОМТ Objectory Booch RUP

45 Формальные методы обеспечивают более строгое представление, основанное на математике обеспечивают возможность строгой проверки позволяющей избавиться от ошибок определенных видов используются при разработки больших и сложных систем (атомная и военная промышленность, управление потоками транспорта) наиболее распространенными формальными методами являются Z (Spivey, 1989), VDM (Jones, 1896), LOTOS (Bjorner, 1987) и B (Abrial, 1996)

46 Практические аспекты разработки требований Писать просто и ясно так же трудно, как быть искренним и добрым. Уильям Сомерсет Моэм, писатель, 1874–1965

47 Как соблюсти баланс? Два очень важных аспекта должны находиться в постоянном балансе в процессе написания требований: –требования должны быть удобными для чтения –требования должны быть удобными для работы с ними

48 Требования к набору требований Набор требований должен позволять: –однозначно идентифицировать каждое требование –классифицировать каждое требование (по важности, по типу, по срочности) –отслеживать статусы каждого требования –определять атрибуты требованиям –рассматривать каждое требование в контексте всего набора –находить в наборе определенные требования по контексту, классификации или другим признакам –устанавливать связи между требованиями и легкого переходить по этим связям от одного требования к другому

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

50 Моделирование и структура требований Иерархические структуры моделей могут определять часть структуры набора требований: –декомпозиция целей и возможностей в пользовательских сценариях –функциональная декомпозиция в диаграммах потоков данных –декомпозиция состояний системы в диаграммах состояний

51 Дополнительная информация Документ с требованиями может также содержать следующую дополнительную информацию: –Историческая информация, которая помогает представить требования в правильном контексте; –Внешнее окружение, описывающее включающую систему, или как его часто называют «знания о предметной области»; –Определение объема требований (что включено, а что нет, т.е. рамок проекта); –Определение терминологии используемой в документе; –Описательный текст, который служит для связи разделов документа между собой; –Описание заинтересованных сторон; –Краткое описание моделей используемых для получения требований; –Ссылки на другие документы.

52 Атрибуты требований Идентификация –Идентификатор –Название Внутренние характеристики –Основной тип –Качественный подтип –Тип продукта/процесса –Количественный/качественный тип –Фаза жизненного цикла Приоритет и важность –Приоритет –Важность Источник и владелец –Способ получения –Источник –Владелец –Согласовано Контекст –Набор требований/документ –Тема –Границы (рамки) Проверка и утверждение (Verification and Validation, V&V) –V&V метод –V&V стадия –V&V статус –Критерий успешности проверки –Критерий утверждения –Поддержка процесса –Статус согласования –Статус проверки –Статус удовлетворения –Статус рецензирования Уточнение –Необходимость –Комментарии –Вопросы –Ответы Прочее –Зрелось (стабильность) –Уровень риска –Оценочная стоимость –Фактическая стоимость –Релиз продукта

53 Ключевые требования KURs (key user requirements – ключевые пользовательские требования) или KPIs (key performance indicators – ключевые показатели производительности)

54 Важность требований

55 Язык требований Типы требований заинтересованных сторон: Возможности Ограничения должен иметь возможность. должен иметь возможность с(в) с находясь в. не должен попадать под действие.

56 Язык требований Типы системных требований: Системные функции Ограничения должна не менее чем (с) функционируя в. должна каждые.

57 Использование шаблонов

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

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

60 Критерии законченного набора требований полнота: все необходимые требования записаны; непротиворечивость: не существует требований противоречащих друг другу; отсутствие избыточности: каждое требование сформулировано только один раз (нет повторов); модульность: требования близкие друг другу содержаться в одном разделе; структурированность: наличие ясной четкой структуры документа с требованиями; удовлетворенность: достигнут необходимый уровень покрытия требований связями типа «удовлетворяет» тестируемость: достигнут необходимый уровень покрытия требований тестами.

61 Дополнительные аспекты работки требований Проблема использования естественного языка Словарь бизнес области Согласованная терминология в области решений Многоязычные проекты Однозначность различных распространенных естественных языков

62 Два примера жутких требований Система должна обеспечивать максимальный уровень все время работы, за исключением аварийных ситуаций, при которых она должна обеспечивать уровень до 125%, только если аварийная ситуации не длиться более чем 15 минут, в этом случае система должна уменьшить уровень до 105%, но в случае если удается достигнуть только 95%, система должна активировать сообщении об исключении «уменьшение уровня» и поддерживать уровень в пределах 10% от начального значения в течение, как минимум, 30 минут. Система должна обеспечивать основные функции текстового редактора, удобные для использования необученным персоналом и должна работать в условиях «тонкой» локальной компьютерной сети проложенной по верней системе кабельных каналов с интегрированными сетевыми адаптерами, поставляемыми с дополнительными модулями памяти, при необходимости.

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

64 Источники требований –Интервью заинтересованных сторон –Групповые интервью –Workshops –Опросы –Аналогичные или существующие (legacy) системы –Работа в роли пользователя –Наблюдения за работой пользователей –Запросы на изменения, жалобы в службу поддержки –Предложения по улучшению, новые идеи –Обзоры и исследования –Прототипы –Новые технологии

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

66 Роль проверок Проверка документов (требований, моделей, спецификаций) позволяют избежать эффекта «падающего домино» Формальные инспекции документов и кода, по проверенным данным, позволяют снизить количество ошибок на 80%. Чем раньше удается устранить ошибки, тем больше удается сэкономить затраты на реализацию проекта.

67 Стоимость ошибок

68 Надежный путь разработки требований Определите структуру требований, и постоянно улучшайте ее в процессе работы с требованиями. Записывайте требования как можно раньше, даже если они далеки от совершенства. Как можно раньше определите атрибуты требований. Как можно быстрее подготовьте первую версию требований, для того чтобы получить отзывы. Улучшайте требования в процессе работы удаляя повторения, преждевременные технические решения и несогласованность. Постоянно обсуждайте требования и собирайте замечания, делайте как можно быстрее новые версии требований. Демонстрация пользователям гораздо лучше, чем «экспертный» анализ. Основные правила для написания требований: Используйте простой прямой язык; Пишите требования, которые можно проверить; Используйте определенную и согласованную терминологию; В одном требовании пишите только одно требование.

69 Заключение Требования имеют огромное влияние на успех проекта Проверенные методы и высокая дисциплина при разработке требований позволяет получить надежную основу для разработки системы Знания, аккуратность, опыт и командная работа позволят вам «почувствовать разницу»

70 Аспекты управления разработкой требований Теория утверждает, что разницы между теорией и практикой не существует. Практика утверждает обратное. Ёги Берра (Yogi Berra), бейсболист, 1925…

71 Три ключевых фактора

72 Управление разработкой требований – сложное дело В отсутствии должного опыта люди, не понимают какой объем работы нужно выполнить, чтобы разработать требования Люди не понимают различия между пользовательскими и системными требованиями Процесс управления требованиями зависит от типа организации Сложно оценить какой объем работы из запланированного выполнен Наличие большого количества изменений

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

74 Основные этапы управления разработкой требований Планирование Контроль хода выполнение работы Управление изменениями

75 Заказчик - планирование Концепция, Спонсор Определение полного списка заинтересованных сторон Сбор требований заинтересованных сторон (возможности и ограничения), способы сбора требований Атрибуты требований Проверки и согласования

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

77 Заказчик – контроль изменений Разная степень формализации подхода к изменениям в зависимости от этапа реализации проекта: –Внесение изменений без контроля –Предупреждение о внесении изменений коллег –Формальный процесс предложения, утверждения и внесения изменений

78 Тендер глазами заказчика Причины проведения тендера: –нехватка внутренних ресурсов –нехватка экспертизы (скалируемости) –преимущества продукта Определение участников конкурса: –внутренние ресурсы –внешние ресурсы –поставщики продуктов Этапы тендера: –Исследование рынка –RFI (Request for Information – Запрос на предоставление информации) –RFP (Request for Proposal – Запрос на коммерческое предложение) –принятие решения

79 Пример структуры RFI/RFP Конфиденциальность Введение –Цель проекта –Объем и рамки проекта –Зависимости, связи и ссылки на другие документы Представление компании Заказчика Инструкции участникам тендера: –Основные условия проведения тендера –Бюджет проекта и принципы оплаты работы –Право Заказчика вносить изменения в RFI/RFP –Право Заказчика на отклонения предложения –Требования к участникам тендера –Требования к ответам –Стоимость предлагаемого решения

80 Пример структуры RFI/RFP График проведения тендера: –Отправка RFI/RFP –Подтверждение намерения участвовать в тендере –Вопросы и ответы на них –Ответы на RFI/RFP –Презентации ответов на RFI/RFP участниками тендера –Выбор Поставщика (короткого листа Поставщиков) –Заключение контракта (в случае выбора Поставщика) Критерии выбора Поставщика: –Экспертиза команды –Техническая сторона предложения –Стоимость Приложения: –Требования и вопросы к участникам тендера (о самой компании) –Требования (заинтересованных сторон или системные)

81 Поставщик - Планирование Анализ полученных от Заказчика требований Вопросы и предложения Заказчику Оценка требований Заказчика Подготовка Предложения Ваши вопросы и предложения могут попасть к вашим конкурентам! В этой ситуации вы можете: –полностью проигнорировать проблему; –сделать какое-то предположение (допущение), позволяющее устранить проблему, и, зафиксировав его документально, двигаться дальше; –принять решение, что, независимо от последствий, необходимо задать вопрос Заказчику.

82 Поставщик - Планирование Необходимо сохранять все тендерные материалы, включая все, вопросы которые были не заданы, предположения, которые были сделаны, и т.п. Большой срок между проведением тендера и заключением контракта Разные команды на тендере и на реальном проекте Субподрядчики После заключение контракта: –Уточнение вопросов и проблемных требований –Планирование разработки детальных требований –Определение приоритетов и распределение по фазам

83 Поставщик – контроль выполнения работ Анализ и оценка исходных требований Моделирование предлагаемого решения После заключения контракта: –Контроль в соответствии с планом проекта –Контроль субподрядчиков

84 Поставщик – контроль изменений Источники изменений: –заказчик; –поставщики (субподрядчики); –внутренние источники. Объекты контроля изменений: –входящие требования; –требования для поставщиков и субподрядчиков (исходящие требования); –допущения, предположения и интерпретации, сделанные командой, разрабатывающей коммерческое предложение.

85 Продуктовая компания Заказчик и Поставщик в рамках одной организации (характерно так же для In-House разработки) Несколько модификаций продукта –Локализации –По полноте функционала Несколько версий одного продукта

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

87 Заключение Планирование –Структура требований помогает получить план работ Контроль за ходом выполнения –Наполнение структуры –Статусы и атрибуты требований –Наличие связей определенного типа Изменения –Связи играют ключевую роль в анализе воздействия изменений –Процедуры внесения изменений

88 Управление требованиями в различных проектных методологиях Что не может дать вам CMM: хорошее программное обеспечение Ивар Якобсон, ученый, 1939…

89 CMM/CMMI - Уровни

90 CMM/CMMI Метрики –Статус для каждого требования –Изменения требований и их количество –Количество изменений сделанных между версиями (метками) Процедуры –Процессы связанные с изменениями требований –Определение влияния изменения –Согласование изменений –Контроль за изменениями

91 ISO 9000:2000

92 CMM/CMMI и ISO 9000 Ни CMM/CMMI ни ISO 9000 не определяет то как необходимо разрабатывать и управлять требованиями. Они обязывают вашу организацию определить, внедрить эффективный процесс управления требованиями и неукоснительно его придерживаться.

93 Водопадная модель

94 Спиральная модель

95 RUP – итеративная модель

96 Гибкие (agile) методологии eXtreme Programming Scrum DSDM Crystal … Nokia 888 гибкий телефон будущего

97 Гибкие (agile) методологии – 12 практик Игра в планирование Быстрое определение объема следующего релиза путем сопоставления приоритета со стороны бизнеса и оценок со стороны разработки. В случае если работа не соответствует плану, меняется план. Маленькие релизы В эксплуатацию сначала выводится очень простая система с небольшим количеством функционала, через короткий промежутков времени выходит следующий релиз с дополнительным функционалом и т.д. Метафора Позволяет всем разработчикам и участникам проекта понять как работает вся система с помощью небольшого предложения (истории). Простая архитектура Система должна быть очень простой. Вся излишня сложность должна устраняться как только находится. Тестирование Программисты постоянно пишут модульные тесты (unit tests), до того как напишут код, тесты поддерживаются всегда в актуальном состоянии. Заказчик пишет приемочные тесты, которые помогают разработчикам лучше его понять. Refactoring Программисты переписывают системный код, для того чтобы сделать архитектуру системы проще, гибче, эффективнее не изменяя при этом функционал системы.

98 Гибкие (agile) методологии – 12 практик Парное программирование Весь код системы пишется парами программистов, каждая из которых работает за одной машиной вместе(одновременно – только один человек имеет доступ к клавиатуре, другой помогает идеями и выявляет ошибки). Совместное владение кодом Любой разработчик может изменить любую часть системы в любое время. Постоянная интеграция Успешные сборка и построение системы несколько раз в день. 40 часовая рабочая неделя Правилом является работать не более 40 часов в неделю. Никогда переработки не повторяются две недели подряд. Доступный заказчик представитель заказчика – реальный будущий пользователь системы сидит в одной комнате с командой разработчиков чтобы отвечать на вопросы, писать приемочные тесты, участвовать в планирование и т.д. Стандарты программирования Программисты пишут код в соответствии с принятыми стандартами, чтобы он был проще и понятнее для всех членов команды.

99 Сравнение формальных и гибких проектных подходов Аспекты ФормальныеГибкие Корректность (целесообразность)хх Непротиворечивостьхх Приоритет требований+/-х Необходимостьхх Простота внесения изменений-х Тестопригодность (возможно проверить) хх Полнотах- Однозначность интерпретациихх Реализуемостьхх Покрытие связями (traceable)х-

100 RUP или Agile? ??? Ответить на этот вопрос можете только вы сами

101 Средства управления требованиями Тут нет ничего особенного. Все что нужно делать человеку, это нажимать нужные клавиши в нужное время и инструмент будет играть сам. Иоганн Себастьян Бах, композитор, 1685 – 1750

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

103 Причины использования средства управления требованиями Управление версиями и изменениями Атрибуты требований Связи между требованиями и другими объектами Возможность оценить прогресс выполнения работы Выделение части требований (сортировки и фильтры) Управление доступом Как средство командной работы и связи со всеми заинтересованными лицами

104 Критерии выбора системы управления требованиями Возможность импорта существующих требований в систему Гибкая конфигурация атрибутов для различных типов требований Возможность создания версий и меток (Versions and Baselines) Возможность связи требований между собой Интеграция с другими системами возможность связи требований с объектами внутри этих систем Управление доступом Система экспорта и подготовки документов

105 Критерии выбора системы управления требованиями Наличие системы запросов на изменение Возможность включать объекты (файлы, графику, диаграммы) в текст требований Возможность обсуждения требований Автоматические нотификации Web interface Удобство использования Примеры проектов, обучающие материалы, документация, доступность курсов

106 Сравнение систем для управления требованиями INCOSE Requirements Management Tools Survey Requirements Tools Requirements Management Tools A Qualitative Assessment

107 Демонстрация систем

108 Спасибо! Илья Корнипаев