1. Разработкой технических условий
1.1. Разработка требований
1.1.1. Выявление и сбор требований
1.1.2. Анализ требований
1.1.3. Документирование требований
1.1.4. Утверждение требований
2. Бизнес-контекст
2.1. Профили заинтересованных лиц
2.1.1. Заинтересованными в проекте лицами называются отдельные лица, группы или организации, которые активно вовлечены в проект, на которых влияет результат проекта и которые сами могут влиять на этот результат
2.2. Приоритеты проекта
2.2.1. Ограничение
2.2.2. Ведущий фактор
2.2.3. Степень свободы
2.3. Особенности развертывания
3. Подводные рифы при способе с применением вариантов использования
3.1. Слишком много вариантов использования
3.2. Очень сложные варианты использования
3.3. Включение дизайна в варианты использования
3.4. Включение определения данных в варианты использования
3.5. Варианты использования, которые непонятны пользователям
4. Основы разработки требований к ПО
4.1. Поиск упущенных требований
4.1.1. Раскладывайте требования высокого уровня на простейшие составляющие
4.1.2. Убедитесь, что все классы пользователей предоставили вам информацию
4.1.3. Подробно документируйте, на каких функциональных требованиях основаны требования к системе, пользовательские требования списки откликов на события и бизнес-правила,
4.1.4. Используйте разнообразные формы представления информации о требованиях.
4.2. Атрибуты качества ПО
4.2.1. Прототип ПО
4.2.1.1. Особенности определения отчетов
4.2.1.1.1. Предлагайте другие варианты
4.2.1.1.2. Поиск данных
4.2.1.1.3. Рассчитывайте на рост в будущем
4.2.1.1.4. Следите за аналогиями
4.2.1.1.5. Различайте статические и динамические отчеты
4.2.1.1.6. Создавайте прототипы отчетов
4.2.1.2. Прояснение, формулировка и утверждение требований
4.2.1.3. Исследование альтернативных решений
4.2.1.3.1. Основная цель создания прототипа — устранение неясностей на ранних стадиях процесса разработки. Для этого не нужен прототип всего продукта. Надо сосредоточиться на высокорисковых областях и известных неясностях и именно исходя из них следует решать, для каких частей системы необхо- дим прототип и что вы надеетесь выяснить, оценивая его.
4.2.1.4. Создание подмножества, которое в конечном итоге превратится в конечный продукт
4.2.1.5. Бумажный прототип
4.2.1.6. Тестирование требований
4.2.1.7. Функциональное требование
4.2.2. Внешние атрибуты качества
4.2.2.1. Доступность
4.2.2.2. Удобство установки
4.2.2.3. Целостность
4.2.2.4. Совместимость
4.2.2.5. Производительность
4.2.2.6. Надежность
4.2.2.7. Устойчивость
4.2.2.8. Защита
4.2.2.9. Безопасность
4.2.2.10. Удобство использования
4.2.3. Внутренние атрибуты качества
4.2.3.1. Эффективность
4.2.3.2. Возможность модификации
4.2.3.3. Переносимость
4.2.3.4. Возможность повторного использования
4.2.3.5. Масштабируемость
4.2.3.6. Проверяемость
4.3. Выявление требований
4.3.1. Методы выявления требований
4.3.1.1. Интервью
4.3.1.1.1. Установите контакт
4.3.1.1.2. Предлагайте идеи
4.3.1.1.3. Слушайте активно
4.3.1.2. Семинары
4.3.1.2.1. Определите и отслеживайте выполнение основных правил
4.3.1.2.2. Обеспечьте наличие всех ролей в команде
4.3.1.2.3. Планируйте повестку дня
4.3.1.2.4. Придерживайтесь границ проекта
4.3.1.2.5. Фиксируйте темы для дальнейшего обсуждения
4.3.1.2.6. Ограничивайте некоторые дискуссии по времени
4.3.1.2.7. Не увеличивайте размер команды и тщательно отбирайте участников
4.3.1.2.8. Вовлекайте в обсуждение каждого
4.3.1.3. Фокус-группы
4.3.1.3.1. Фокус-группы надо организовывать и контролировать. Нужно следить, чтобы участники придерживались темы, но оказывать влияния на их мнения. Можно записывать встречу, чтобы можно было вернуться и внимательно вы- слушать комментарии.
4.3.1.4. Наблюдение
4.3.1.5. Опросные листы
4.3.1.6. Анализ системных интерфейсов
4.3.1.7. Анализ пользовательского интерфейса
4.3.1.8. Анализ документов
4.3.1.8.1. Анализ документов — хороший способ быстро освоить текущую систему или новую предметную область. Выполнение исследования и подготовка предварительных требований способствует сокращению времени, необходи- мого для проведения встреч по выявлению требований. Анализ документов может выявить информацию, о которой люди не говорят вам — потому что не подумали об этом или просто не владеют ею.
4.3.2. Объясняйте заинтересованным лицам свои методы
4.3.3. Обеспечьте качественное протоколирование
4.3.4. Задействуйте физическое пространство
4.3.5. Планирование выявления требований в проекте
4.3.5.1. Подготовка к выявлению требований
4.3.5.1.1. Определение границ и графика выявления требований
4.3.5.1.2. Узнайте больше о заинтересованных лицах
4.3.5.1.3. Подготовьте вопросы
4.3.5.2. Цели выявления требований
4.3.5.3. Стратегии и способы выявления требований
4.3.5.4. График и смета ресурсов
4.3.5.5. Документы и системы, необходимые для независимого выявления требований
4.3.5.6. Ожидаемые результаты выявления требований
4.3.5.7. Риски, связанные с выявлением требований
4.4. Разработка требований
4.4.1. Бизнес-требования
4.4.1.1. Исходные данные
4.4.1.2. Возможности бизнеса
4.4.1.3. Бизнес-цели
4.4.1.4. Критерии успеха
4.4.1.5. Бизнес-риски
4.4.1.6. Предположения и зависимости
4.4.2. Рамки и ограничения проекта
4.4.2.1. Основные функции
4.4.2.2. Объем первоначально запланированной версии
4.4.2.3. Объем последующих версий
4.4.2.3.1. В последующих версиях вы сможете реализовать дополнительные варианты использования и функции и расширить возможности первоначальных ва- риантов использования и функций. Чем дальше вы заглядываете, тем более расплывчатыми будут границы проекта
4.4.2.4. Ограничения и исключения
4.4.3. Способы представления границ проекта
4.4.3.1. Контекстная диаграмма
4.4.3.2. Карта экосистемы
4.4.3.3. Дерево функций
4.4.3.4. Список событий
4.5. Каркас процесса создания требований
4.5.1. Выявление требований
4.5.1.1. Изучение отчетов о проблемах работающих систем с целью поиска новых идей
4.5.1.2. Раздача опросных листов
4.5.1.2.1. Качественные вопросы позволяют быстро выявить аналитическую информацию о потребностях. На основе результатов опросных листов можно более целенаправленно применять дополнительные усилия.
4.5.1.3. Проведение интервью для выявления требований
4.5.1.3.1. Это эффективный способ выявления требований без слишком большого отвлечения заинтересованного лица от его работы, потому на таких встречах обсуждаются только конкретные требования, имеющие значение для интервьюируемого заинтересованного лица.
4.5.1.4. Работа с пользователями для выяснения назначения продукта
4.5.1.5. Выбор сторонника продукта в каждом классе пользователей
4.5.1.6. Наблюдение за пользователями на рабочих местах
4.5.1.7. Определение концепции продукта и границ проекта
4.5.1.7.1. Концепция и границы — хорошая база для оценки предлагаемых требований. Концепция продукта должна оставаться от версии к версии относительно стабильной, но для каждого выпуска необходимо составить отдельный документ о границах
4.5.1.8. Определение классов пользователей и их характеристик
4.5.1.8.1. Создайте архетипы пользователей — описания выдуманных людей, которые будут представлять конкретные классы пользователей.
4.5.1.9. Проведение фокус-групп типичных пользователей
4.5.1.9.1. Фокус-группы особенно ценны при разработке коммерческих продуктов, когда приходится иметь дело с большой и разнородной клиентской базой. В отличие от сторонников продукта, у фокус- групп обычно нет полномочий на принятие решений
4.5.1.10. Проведение совместных семинаров
4.5.1.11. Анализ документов
4.5.1.11.1. Просмотр и анализ этих документов может помочь выявить функциональность, которая должна остаться и которая больше не нужна, а также определить, как сейчас люди выполняют свою работу, что предлагают конкуренты и что говорят поставщики о том, что должно делать их ПО.
4.5.1.12. Повторное использование требований
4.5.2. Анализ требований
4.5.2.1. Моделирование среды приложения
4.5.2.2. Создание пользовательского интерфейса и технических прототипов
4.5.2.3. Анализ осуществимости требований
4.5.2.4. Определение приоритетов требований
4.5.2.5. Создание словаря данных
4.5.2.6. Моделирование требований
4.5.2.7. Анализ интерфейсов между системой и внешним миром
4.5.2.8. Распределение требований по подсистемам
4.5.3. Спецификации требований
4.5.3.1. Внедрение шаблонов документов требований
4.5.3.2. Определение источников требований
4.5.3.3. Присвоение уникальных идентификаторов всем требованиям
4.5.3.4. Документирование бизнес-правил
4.5.3.5. Определение нефункциональных требований
4.5.4. Проверка требований
4.5.4.1. Рецензирование требований
4.5.4.1.1. Соберите не-большую команду рецензентов, представляющих различные области, (таких как аналитик, клиент, разработчик и тестировщик), и внимательно изучите письменные требования, аналитические модели и связанную информацию на предмет ошибок. Также ценно неформальное предварительное рецензирование во время разработки требований. Важно обучить членов команды, как эффективно выполнять рецензирование требований, а также внедрить в организации процесс рецензирования.
4.5.4.2. Тестирование требований
4.5.4.3. Определение критериев приемки
4.5.4.4. Моделирование требований
4.5.5. Управление требованиями
4.5.5.1. Определение процесса управления изменениями
4.5.5.2. Анализ влияния изменений требований
4.5.5.3. Создание базовой версии и управление версиями требований
4.5.5.4. Ведение журнала изменений требований
4.5.5.5. Отслеживание состояния всех требований
4.5.5.6. Отслеживание проблем с требованиями
4.5.5.7. Создание матрицы связей требований
4.5.5.8. Использование средств управления требованиями
4.5.6. Обучение
4.5.6.1. Обучение аналитиков требований
4.5.6.2. Ознакомление заинтересованных лиц с требованиями
4.5.6.3. Ознакомление разработчиков с предметной областью
4.5.6.4. Определение процесса разработки требований
4.5.6.5. Создание бизнес-словаря
4.5.7. Управление проектом
4.5.7.1. Выбор цикла, или модели, разработки ПО
4.5.7.2. Планирование подхода к работе с требованиями
4.5.7.3. Оценка усилий на работу с требованиями
4.5.7.4. Планы реализации проекта должны быть основаны на требованиях
4.5.7.5. Определение лиц, ответственных за принятие решений по требованиям
4.5.7.6. Пересмотр обязательств по проекту при изменении требований
4.5.7.7. Анализ, документирование и управление рисками, связанными с требованиями
4.5.7.8. Контроль объема работ по созданию требований
4.5.7.9. Извлечение уроков из полученного опыта
4.6. Утверждение требований
4.6.1. Рецензирование требований
4.6.1.1. Процесс экспертизы
4.6.1.1.1. Этапы экспертизы
4.7. Спецификация требований к ПО
4.7.1. клиенты, отдел маркетинга и специалисты по продажам хотят иметь представление о конечном продукте
4.7.2. менеджеры проекта по данным спецификации рассчитывают графики, затраты и ресурсы
4.7.3. команда разработчиков ПО получает представление о том, какой продукт надо создавать;
4.7.4. тестировщики составляют основанные на требованиях тесты, планы тестирования и процедуры
4.7.5. специалистам по обучению спецификация требований к ПО и пользовательская документация необходима для разработки обучающих материалов
4.7.6. персонал, занимающийся юридической стороной проекта, проверяет, соответствуют ли требования к продукту существующим законам и постановлениям
4.7.7. Шаблон требований к ПО
4.7.7.1. Введение
4.7.7.1.1. Назначение
4.7.7.1.2. Соглашения, принятые в документах
4.7.7.1.3. Границы проекта
4.7.7.1.4. Ссылки
4.7.7.2. Общее описание
4.7.7.2.1. Общий взгляд на продукт
4.7.7.2.2. Классы и характеристики пользователей
4.7.7.2.3. Операционная среда
4.7.7.2.4. Ограничения дизайна и реализации
4.7.7.2.5. Предположения и зависимости
4.7.7.3. Функции системы
4.7.7.3.1. Функция системы X
4.7.7.3.2. Описание
4.7.7.3.3. Функциональные требования
4.7.7.4. Требования к данным
4.7.7.4.1. Логическая модель данных
4.7.7.4.2. Словарь данных
4.7.7.4.3. Отчеты
4.7.7.4.4. Получение, целостность, хранение и утилизация данных
4.7.7.5. Требования к внешним интерфейсам
4.7.7.5.1. Пользовательские интерфейсы
4.7.7.5.2. Интерфейсы ПО
4.7.7.5.3. Интерфейсы оборудования
4.7.7.5.4. Коммуникационные интерфейсы
4.7.7.6. Атрибуты качества
4.7.7.6.1. Удобство использования
4.7.7.6.2. Производительность
4.7.7.6.3. Безопасность
4.7.7.6.4. Техника безопасности
4.7.7.7. Требования по интернационализации и локализации
4.8. Уровни и типы требований
4.8.1. Бизнес-требования
4.8.2. Функциональные требования
4.8.2.1. Характеристика
4.8.2.2. Нефункциональное требование
4.8.2.2.1. Атрибут качества
4.8.3. Системное требование
4.8.3.1. Пользовательское требование
4.9. Формирования требований
4.9.1. Влияние
4.9.1.1. Сильное
4.9.1.1.1. Определите процесс разработки требований Планируйте на основании требований Своевременно пересматривайте обязательства. Создайте матрицу связей требований. Проведите семинары по выявлению требований. Оцените объем работ по реализации требований. Повторно задействуйте существующие требования.
4.9.1.2. Средняя
4.9.1.2.1. Обучите аналитиков требований • Планируйте подход к работе с требованиями • Выделите из пользователей ярых сторонников продукта • Определите пользова- тельские требования • Проведите интервью для выявления требований • Определите нефункцио- нальные атрибуты • Расставьте приоритеты для требований • Определите концепцию продукта и границы проекта • Определите процесс управления изменениями • Изучите документы с требованиями • Распределите требования по подсистемам • Используйте средство управления требованиями • Задокументируйте бизнес-правила
4.9.1.3. Низкое
4.9.1.3.1. Обучите разработчиков основам предметной области • Внедрите шаблон спецификации требований • Определите классы пользователей • Смоделируйте среду приложения • Определите источники требований • Определите базовую и контрольную версии наборов требований • Определите лиц, ответственных за принятие решений по требованиям Создайте словарь данных • Наблюдайте за пользователями на рабочих местах • Протестируйте требо- вания • Отслеживайте состо- яние требований • Выполните анализ документов • Отлеживайте проб- лемы с требованиями • Задайте каждому тре- бованию уникальный идентификатор • Создайте словарь терминов
4.9.2. Сложность
4.9.2.1. Высокая
4.9.2.2. Средняя
4.9.2.3. Низкая
4.10. Риски, связанные с выявлением требований
4.10.1. Основные риски требований
4.10.1.1. Недостаточное вовлечение пользователей
4.10.1.2. Небрежное планирование
4.10.1.3. «Разрастание» требований пользователей
4.10.1.4. Двусмысленные требования
4.10.1.5. Требования-«бантики»
4.11. Схемы требований
4.11.1. Инструкция
4.11.2. Содержимое
4.11.3. Шаблон
4.11.4. Примеры
4.11.5. Дополнительные требования
4.11.6. Особенности разработки и тестирования
4.12. Приемы формулирования требований
4.12.1. Сбор информации
4.12.2. Анализ
4.12.3. Спецификации
4.12.4. Проверка
4.12.5. Управление требованиями
4.12.6. Обучение
4.12.7. Управление проектом
5. Бизнес-аналитик
5.1. Роль бизнес-аналитика
5.1.1. Задачи аналитика
5.1.1.1. Определить бизнес-требования
5.1.1.2. Спланировать подход к работе с требованиями
5.1.1.3. Определить заинтересованных лиц и классы пользователей
5.1.1.4. Выявить требования
5.1.1.5. Анализировать требования
5.1.1.6. Документировать требования
5.1.1.7. Доводить требования до заинтересованных лиц
5.1.1.8. Управлять проверкой требований
5.1.1.9. Обеспечить расстановку приоритетов требований
5.1.1.10. Управлять требованиями
5.1.2. Навыки, необходимые аналитику
5.1.2.1. Умение слушать
5.1.2.2. Умение опрашивать и задавать вопросы
5.1.2.3. Способность соображать на ходу
5.1.2.4. Навыки анализа
5.1.2.5. Навыки системного мышления
5.1.2.6. Навыки обучения
5.1.2.7. Навыки создания комфортных условий общения
5.1.2.8. Лидерские качества
5.1.2.9. Умение наблюдать
5.1.2.10. Навыки общения
5.1.2.11. Организационные навыки
5.1.2.12. Навыки моделирования
5.1.2.13. Навыки межличностного общения
5.1.2.14. Творческий подход
5.1.3. Становление аналитика
5.1.3.1. Бывший пользователь
5.1.3.2. Бывший разработчик или тестировщик
5.1.3.3. Бывший (или текущий) менеджер проекта
5.1.3.4. Специалист предметной области
5.1.3.5. Молодой специалист
6. Требования с точки зрения клиента
6.1. Классификация предоставляемой клиентом информации
6.1.1. Бизнес-требования
6.1.2. Пользовательские требования
6.1.3. Бизнес-правила
6.1.4. Функциональные требования
6.1.5. Атрибуты качества
6.1.6. Требования к внешнему интерфейсу
6.2. Заинтересованное лицо
6.2.1. Клиент
6.3. Сотрудничество клиентов и разработчиков
6.3.1. Клиент
6.3.1.1. «Билль о правах клиента ПО»
6.3.1.1.1. Иметь дело с аналитиком, который разговаривает на вашем языке
6.3.1.1.2. Иметь дело с аналитиком, хорошо изучившим ваш бизнес и цели, для которых создается система
6.3.1.1.3. Потребовать, чтобы аналитик зафиксировал требования в надлежащей форме
6.3.1.1.4. Получить подробный отчет о будущих процедурах и результатах процесса формулирования требований
6.3.1.1.5. Изменить свои требования
6.3.1.1.6. Взаимное уважение
6.3.1.1.7. Знать о вариантах и альтернативах требований и их решении
6.3.1.1.8. Описать характеристики, упрощающие работу с продуктом
6.3.1.1.9. Узнать о способах корректировки требований для ускорения разработки за счет повторного использования
6.3.1.1.10. Получить систему, функциональность и качество которой соответствует вашим ожиданиям
6.3.2. Разработчик
6.3.2.1. «Билль о правах разработчика».
6.3.2.1.1. Ознакомить аналитиков и разработчиков с особенностями вашего бизнеса
6.3.2.1.2. Потратить столько времени, сколько необходимо на предоставление и уточнение требований
6.3.2.1.3. Точно и конкретно описать требования к системе
6.3.2.1.4. По запросу принимать своевременные решения относительно требований
6.3.2.1.5. Уважать определенную разработчиком оценку стоимости и возможности реализации ваших требований
6.3.2.1.6. Определять реалистичные приоритеты требований совместно с разработчиками
6.3.2.1.7. Проверять требования и оценивать прототипы
6.3.2.1.8. Определить критерии приемки
6.3.2.1.9. Своевременно сообщать об изменениях требований
6.3.2.1.10. Уважительно относиться к процессам создания требований
6.4. Ответственные за принятие решений
6.4.1. Главный ответственный за принятие решений
6.4.2. Правило принятия решений,
6.5. Достижение соглашения о требованиях
6.5.1. Базовое соглашение о требованиях
6.5.2. Не удается достичь соглашения
6.5.3. Согласование требований в проектах гибкой разработки
7. От требований — к планам проекта
7.1. Требования и график
7.2. Дизайн ПО
7.3. Тестирование
8. Проекты доработки или замены
8.1. Работа с требованиями при наличии существующей системы
8.1.1. Создание дерева функций для представления изменений
8.1.2. Определение классов пользователей
8.1.3. Определение бизнес-процессов
8.1.4. Документирование бизнес-правил
8.1.5. Создание вариантов использования и пользовательских историй
8.1.6. Создание контекстной диаграммы
8.1.7. Создание карты экосистемы
8.1.8. Создание карты диалоговых окон
8.1.9. Создание моделей данных
8.1.10. Определение атрибутов качества
8.1.11. Создание таблиц отчетов
8.1.12. Создание прототипов
8.1.13. Изучение спецификаций требований
9. Управление требованиями
9.1. Управление рисками ПО
9.1.1. Оценка риска
9.1.1.1. Анализ риска
9.1.1.1.1. Подверженность риску
9.1.2. Предотвращение риска
9.1.3. Контроль риска
9.2. Управление версиями требований
9.3. Отслеживание состояния требований
9.4. Разрешение проблем с требованиями
9.5. Проблемы, связанных с требованиями
9.5.1. Продукт не удовлетворяет нужд пользователей или не соответствует их ожиданиям;
9.5.2. Продукт требует исправлений и «заплат» сразу после выпуска
9.5.3. Выпущенное решение не помогает организации в достижении бизнес-целей
9.5.4. Нарушение графика и перерасход бюджета;
9.5.5. Разочарование членов команды, деморализация, утрата мотивации и текучка кадров
9.5.6. Масса переделок во время разработки решения
9.5.7. Упущенная возможность на рынке или задержка с получением бизнес преимущества
9.5.8. Потеря доли на рынке или доходов
9.5.9. Возврат продукта, неприятие продукта рынком или плохие отзывы о продукте
9.6. Проблемы, связанные с выявлением требований
9.6.1. Команда не может добиться достаточного вовлечения представителей клиентов в выявление требований
9.6.2. Разработчики делают большое количество допущений о реализуемых функциях
9.6.3. Разработчикам приходится разрешать возникающие вопросы по требованиям
9.6.4. Вовлечены не тепредставители пользователей
9.6.5. Пользователи не уверены в своих потребностях
9.6.6. Менеджер проекта или бизнес-аналитик не знают, кто их пользователи
9.6.7. Реализованные требования не удовлетворяют нужды пользователей
9.6.8. Требования слишком ограничены
9.6.9. Отсутствуют необходимые требования