Впереди зимние каникулы, и, наверное, многие выбирают себе чтение на эти дни. Самая известная книга среди системных аналитиков — "Разработка требований к программному обеспечению" Карла Вигерса и Джой Битти. Это как Кнут для программистов — все про неё слышали, но мало кто читал от начала до конца. Труд монументальный — в русском издании больше 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 и раздел про тексты и формулировки.

Опционально некоторые вещи, если они встречаются у вас в проекте.

Вот и всё, не благодарите.

(Если что, это шутка. Но в каждой шутке, как мы знаем, есть доля истины...)