Post #496

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