Основное из книги К. Вигерса "Разработка требований к ПО"

Подытоживаю все свои написанные заметки по прочитанной книге К. Вигерса "Разработка требований к ПО".

В книге рассматриваются три основные темы:

1. Работа над требованиями (разработка и управление).
2. Совершенствование процессов по работе с требованиями.
3. Управление рисками при работе с требованиями.

Работа над требованиями

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

Требование - это основа для плана проекта, проектирования решения и написания кода, тестирования.

Требования должны отвечать на вопрос ЧТО? Они не отвечают на вопрос КАК? Проектирование решения отвечает на вопрос КАК?

Цепочка от требований до кода: Бизнес-требование → Пользовательское требование → Функциональное требование → Элемент дизайна → Код, реализующий требование.

Примерный процесс формирования требований

1. Определите бизнес-требования.
2. Определите классы пользователей.
3. Определите представителей пользователей.
4. Определите ЛПР.
5. Разработайте план выявления требований.
6. Определите пользовательские требования и приоритизируйте их.
7. Сформулируйте пользовательские требования.
8. Выведите функциональные требования.
9. Смоделируйте требования.
10. Определите атрибуты качества.
11. Разработайте прототипы.
12. Разработайте архитектуру системы.
13. Распределите требования по компонентам архитектуры системы.
14. Разработайте тест-кейсы.
15. Проверьте пользовательские, функциональные, нефункциональные требования, модели, прототипы.

Выявление

Техники, приемы выявления требований

• Определение классов пользователей и их представителей;
• Выбор сторонника продукта;
• Проведение фокус-групп;
• Проведение интервью для выявления требований;
• Проведение совместных семинаров;
• Наблюдение за пользователями на рабочих местах;
• Раздача опросных листов;
• Анализ документов;
• Изучение отчетов о проблемах существующих систем;
• Требования из других проектов (Повторное использование требований);
• Анализ взаимодействия с внешними системами (интеграция);
• Анализ пользовательских интерфейсов.

Анализ

Классификация информации после выявления

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

1. Бизнес-требования.
2. Пользовательские требования.
3. Бизнес-правила.
4. Функциональные требования. Не стоит считать, что ЗЛ будут предъявлять ФТ. Аналитику на основании сказанного нужно уточнить, дополнить требования до ФТ.
5. Атрибуты качества.
6. Ограничения: то, что ограничивает разработчика.
7. Требования к внешним интерфейсам: связь системы с остальным миром.
8. Данные: формат данных, тип данных, допустимые значения, значения по умолчанию и пр.
9. Идеи, касающиеся решений. Пользователи часто говорят не требованиями, а уже готовыми решениями. Это может стать ограничением для разработчика, хотя убедительных причин для этого нет. Аналитику нужно убедиться в разумности, целесообразности предлагаемого пользователем решения.

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

1.     Внешние интерфейсы системы, границы системы:

• Контекстная диаграмма;
• Карта экосистемы;
• Диаграмма потоков данных;

2.     Поток бизнес-процессов:

• Диаграмма потоков работ;

3.     Описание данных, связи:

• Диаграмма потоков данных;
• Диаграмма сущность-связь;
• Диаграмма классов;
• Словарь данных (таблица);

4.     Состояния системы и объектов:

• Диаграмма перехода состояний;
• Таблица состояний;
• Таблица внешних событий и реакций системы на них;

5.     Сложная логика:

• Дерево решений;
• Таблица решений;

6.     Пользовательский интерфейс:

• Карта диалоговых окон;
• Создание прототипов;
• Модели “Отображение-действие-реакция”;
• Подробные макеты экрана;

7.     Описание задач пользователей:

• Пользовательские истории;
• Варианты использования;
• Диаграммы вариантов использования;
• Диаграммы Swimlane;
• Блок-схемы;
• ФТ на естественном языке;
• Диаграммы потоков работ

8.     НФТ:

• Естественный язык;
• Методика Planguage.

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

1. Определить автоматизируемые бизнес-процессы и акторов, в них участвующих.
2. Составить таблицу акторов и их вариантов использования (названия вариантов).
3. Разработать модели бизнес-процессов (графические, текстовые) с детализацией до функций. Выделить функции, которые должны быть автоматизированы.
4. Расспросить у ЗЛ подробнее о том, какие задачи должна поддерживать система при выполнении функций. Эти задачи / функции - потенциальные кандидаты в варианты использования.
5. Держать в голове бизнес-требования, чтобы отсеивать варианты использования, выходящие за границы проекта.
6. Определять внешние события, на которые система должна реагировать.
7. Фиксировать информационные объекты, участвующие в функциях.
8. Применить CRUD-анализ для информационных объектов.
9. Держать в голове контекстную диаграмму системы, чтобы ее входы и выходы нашли отражение в вариантах использования.
10. Далее совместно с ЗЛ выполнить спецификацию варианта использования с помощью соответствующего шаблона.
11. На основе вариантов использования сформировать функциональные требования и сценарии тестирования.

Моделирование и анализ данных

1. Словарь терминов предметной области + Модель данных (ERD или UML Диаграмма классов) + Словарь данных.
2. Матрица CRUD помогает обнаружить недостающие требования.

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

Документы

1. Документ о концепции (vision) и границах (scope) собирает бизнес-требования в единый документ. Расползание границ проекта.
2. Спецификация требований к системе.
3. Спецификация отчетов.

Принципы создания требований

1. Шаблон формулировки требования с точки зрения системы: [Необязательное предварительное условие] [Необязательный триггер события] Система должна [Ожидаемая реакция системы].
2. Шаблон формулировки требования с точки зрения пользователя: [Класс пользователей или действующее лицо] должен иметь возможность [выполнить что-то] [с каким-то объектом] [условие выполнения, время отклика, декларация качества].
3. Шаблон формулировки требования: Система должна позволить / давать возможность [классу пользователей] [выполнить то, то].
4. Избегать смешение активного и пассивного залога.
5. Не обозначать одно и тоже понятие синонимичными словами.
6. Не использовать сослагательного наклонения.
7. Использовать активный залог.
8. Четко отделять требования друг от друга. Требования должны быть атомарны.
9. Наличие союзов И, ИЛИ, слов - дополнительно, также - Повод задуматься, а не содержится ли в одном предложении несколько требований.
10. Не использовать И/ИЛИ в одном требовании (имеет ввиду через слеш).
11. Обращать внимания на формулировки, в которых содержится “Пока не”, так как есть риск наличия недостающих требований.
12. Избегать негативных формулировок в требованиях, двойного отрицания.
13. Избегать неоднозначные слова.

Подтверждение (утверждение, валидация)

Способы рецензирования

• Формальное рецензирование:
• Неформальное рецензирование:
• Тестирование требований до их реализации.

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

• Полнота;
• Корректность;
• Осуществимость;
• Необходимость;
• Недвусмысленность;
• Проверяемость;
• Назначение приоритета.

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

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

1. Управление версиями:

• Определение правил идентификации версий;
• Отслеживание версий отдельных требований;
• Отслеживание версий наборов требований;

2. Управление изменениями

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

3. Отслеживание состояния требования

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

4. Отслеживание связей требований

• Определение возможных связей требований с другими требованиями и элементами системы;
• Определение связей с другими требованиями;
• Определение связей с другими элементами системы.

Возможные взаимосвязи требований с другими элементами системы

Совершенствование процессов по работе с требованиями

Цепочка процесса совершенствования

Советы

1. Регламентировать процессы работы с требованиями в документах и внедрить их в своей организации.
2. Фиксировать проблемы с требованиями.
3. Помечать открытые проблемы TBD (To Be Defined) и возвращаться к ним, указывать ответственного за решение проблемы и сроки.
4. Вести график решения проблем с требованиями: ответственный, сроки.
5. Фиксировать часы, потраченные на работу с требованиями.
6. Проводить gap-анализ между плановым количеством часов и фактическим для повышения качества планирования будущих проектов.
7. Держать в курсе ЗЛ о состоянии требований, о возникающих проблемах.

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

1. Документировать риск.

2. Оценить риск:

• Вероятность;
• Влияние - оценка в баллах ущерба, который может быть нанесен, если риск реализуется;
• Подверженность = вероятность * ущерб;

3. Отслеживать риски с наибольшим значением подверженности.

Ссылки

1. Полный конспект по книге по ссылке.
2. Выжимка основного из книги по ссылке.