«Разработка требований» Вигерса: самый короткий конспект
Впереди зимние каникулы, и, наверное, многие выбирают себе чтение на эти дни. Самая известная книга среди системных аналитиков — «Разработка требований к программному обеспечению» Карла Вигерса и Джой Битти. Это как Кнут для программистов — все про неё слышали, но мало кто читал от начала до конца. Труд монументальный — в русском издании больше 700 страниц! Мало кто осилит. В сети ходит краткий конспект страниц на 70, но и это много. Я написал для вас супер-краткий конспект или инструкцию по чтению. Так что, если вы давно хотели прочесть Вигерса, но вас пугал объем — воспользуйтесь этой инструкцией, тут ровно то, что вам следует знать про разработку требований, без воды.
Страницы приведены по изданию БХВ, 3-е издание, на русском языке. Для уточнения смысла я иногда заглядывал в англоязычный оригинал.
Конспект супер-циничный, имейте в виду! :) Итак, поехали, что вам нужно знать «из Вигерса»:
Часть I. Требования к ПО
Взаимосвязи нескольких типов информации для требований.
Схема на стр. 7. Уровни требований. В реальности вы будете разрабатывать только функциональные требования. Можно почитать стр. 8 и 9, там расшифровка текстом (стр. 8 — бизнес-требования и юзер-стори, 9 — функциональные). Итого — прочесть 2 страницы.
Составные части предмета разработки технических условий
Рис. 1–4 на стр. 16 — показано, какие есть операции в работе над требованиями. Перевод диаграммы очень плохой, приведу свой: Инженерия требований состоит из разработки требований и управления требованиями. Разработка требований состоит из этапов выявления, анализа, спецификации и валидации. Прочтите расшифровку диаграммы на стр. 17, если что-то непонятно. +1 страница.
Стр. 42–46 — плач о согласовании требований. Совет Вигерса про участников согласования, которые морозятся, на стр. 45, оцените его применимость:
В позитивном ключе упомяните, что вы в курсе, что они пока не одобрили требования, но проект движется вперед с этими требованиями в качестве базовых, чтобы не задерживать работу. Сообщите им, что если они хотят что-то изменить, для этого есть соответствующий процесс. В сущности, вы действуете так, как будто заинтересованное лицо согласилось с требованиями, but you’re managing the communications closely.
+4 страницы
Итеративный процесс формулирования требований
Схема на стр. 51 показывает главную идею: не ждите, что все действия по разработке требований удастся выполнить последовательно и за один проход. Выявление, анализ, спецификация и валидация будут на самом деле происходить одновременно. Всё, можете ссылаться на Вигерса, когда разговариваете с менеджерами, ожидающими, что все требования можно собрать за один проход!
Дальше с 54 по 62 страницу идёт описание действий, которые нужно выполнять на каждом этапе — если вы вообще никогда про бизнес- и системный анализ не слышали — ну, почитайте, может быть любопытно. Имейте в виду, что вы и половины из этого не будете делать в реальном проекте. + 8 страниц (опционально).
После этого идёт большой кусок текста про личные качества аналитиков и откуда аналитики обычно берутся. Можно пропустить.
Часть II. Разработка требований.
Со стр. 85. Вся часть — про действия, которые нужно выполнить при разработке требований. Продолжаю кратко и цинично:
Бизнес-цели, концепция продукта — никого не интересует, почти никто не выявляет и не пишет.
Границы проекта. У проекта должны быть границы. Есть что-то, чего мы делать точно не будем. Для разных релизов границы могут отличаться. Всё. Контекстная диаграмма на стр. 104 полезная, но её почти никогда не рисуют (разве что, может быть, в нотации C4, если вы её используете).
Частичная контекстная диаграмма для системы.
Классы пользователей — скорее всего, у вашей системы один класс пользователей — ваши пользователи («сотрудники <вставьте название отдела>», если это внутренняя система). Или ваш продакт оунер. Ну, может быть два, если вы не забыли администраторов.
Методы выявления требований — реально вы будете делать только интервью. Стр. 138, инструкции, цитирую: установите контакт, следите за границами проекта, заранее подготовьте вопросы и предварительные модели, предлагайте идеи, слушайте активно.
Важность наличия клиента на месте — если у вас agile, постарайтесь сидеть в одной комнате с вашими будущими пользователями. Вигерс советует!
Поиск упущенных требований — стр. 136, точнее один абзац оттуда, про то, что работа надо требованиями не может быть выполнена за один проход:
Выявляется часть требований, после чего анализируется обнаруженная информация, формулируется часть требований, обнаруживается, что какой-то информации не хватает, выполняется дополнительное выявление требований и т. д. Не стоит ожидать, что вы проведете ряд семинаров по выявлению требований, объявите о победе и все — можно заниматься другим проектом.Когда тут остановиться, Вигерс не пишет.
Варианты использования (use cases) — разве их где-то ещё пишут? Если не пишете — пропускаете. Или читаете стр. 171–193. +22 страницы, опционально.
Бизнес-правила — разве их когда-то вообще писали? И вы не будете. Пропускаете. Ну или читаете главу 9.
Шаблон SRS — единственное, что вам нужно из этой части. стр. 223–234. +11 страниц.
Критерии качественных требований — забейте, это никого не волнует и никто не проверяет.
Формулирование и проверка полноты требований, стр. 243–254. Ну тоже полезно. +11 стр.
Моделирование, гл. 12. Много разных диаграмм. Реально вам нужна только Sequence Diagram, но у Вигерса она не описана, ищите где-то ещё.
Требования к данным, гл. 13 — вам это не нужно. Максимум, нужно понимать, как составлять JSONы, но этого у Вигерса тоже нет.
Атрибуты качества ПО — гл. 14. Это «нефункциональные требования». Если вы их не пишете — можно пропустить.
Прототипирование — скорее всего, его у вас нет. Пропускаете.
Приоритеты, гл. 16. Любопытно, но скорее всего у вас приоритеты требований назначаются по принципу «кто ближе к руководству» и «кто громче всех кричит на совещаниях».
Рецензирование, в гл. 17 — ну, почитайте, если оно у вас есть. Это скорее для лидов.
Повторное использование требований, гл. 18. Не бывает.
ЧАСТЬ III. Всё то же самое, но для отдельных видов проектов:
Проекты гибкой разработки. Проекты по доработке и замене систем. Продукты. Проекты с внешним подрядчиком. Проекты автоматизации бизнес-процессов. Бизнес-анализ. Встроенные системы и системы реального времени.
В общем, тут немного нюансов для разных типов проектов. Найдите свой.
Часть IV. Управление требованиями. Для лидов, или стреммящихся ими стать. Вы реально ведёте учет разных версий требований, отслеживаете изменения, состояния и связи требований? Или просто пишете один раз документ, отдаете его, и потом никогда его не переделываете? Если так — можно пропустить.
Часть V. Реализация процесса построения требований — это для лидов. Как улучшить процесс работы с требованиями. Забейте. Глава про управление рисками: риски вообще никто никогда не анализирует и ими не управляет.
Итого, нужно просмотреть несколько страниц из первой части, потом шаблон SRS и раздел про тексты и формулировки.
Опционально некоторые вещи, если они встречаются у вас в проекте.
Вот и всё, не благодарите.
(Если что, это шутка. Но в каждой шутке, как мы знаем, есть доля истины…)
