Дата публикации:
16.01.2024
Книга изобилует терминами, сокращениями которые усложняют восприятие.
Авторы злоупотребляют длинными предложениями.
Например: «Средства управления требованиями помогают отслеживать требования, давая возможность определять связи между различными типами требований, между требованиями в различных подсистемах и между отдельными требованиями и связанными системными компонентами (например, дизайном, модулями кода, тестами и пользовательской документацией).»
По ходу изложения авторы неоднократно упоминают продукты Microsoft. Они настолько известны, что нет смысла писать про них. А когда надо назвать примеры систем управления требованиями, то авторы о них умалчивают.
Не смотря на это, книга интересная, написана как техническая литература но много живых примеров, диаграмм, схем. Сложнейший процесс работы над требованиями к ПО разложен почти до мелочей. Подробные чек-листы содержатся почти в каждой главе.
Информация четко структурирована. В каждой главе есть отсылки на другие главы, если какой-либо вопрос там описан подробнее.
Понравилась трехуровневая иерархия требований:
- бизнес-требования
- пользовательские требования
- функциональные требования
Через всю книгу красной нитью проходит правило, при разработке требований обязательно нужна документальная фиксация и лучше всего это делать в серийном специальном средстве управления требованиями.
Приводится много примеров того как сэкономленное время на разработку качественных требований, приводит к увеличению затрат на доработку ПО.
«Если пользователь обнаруживает ошибку после релиза, то её цена возрастает в 21 раз. На стадии ТЗ устранить её гораздо дешевле»
Приводятся советы как улучшить качество требований, мощным инструментами является построение диаграмм, схем, таблиц, создание прототипов, рецензирование требований.
Понравился приведенный пример с построением прототипа копировального аппарата), на вопрос как это сделать? - “Купите большой холодильник….возьмите от него коробку, внутрь посадите человека и смоделируйте работу по аппарата”
Очень подробна описана Роль бизнес аналитика в процессе разработки требований.
“Аналитик обычно оказывается ключевым человеком, на плечи которого ложится налаживание сотрудничества между разработчиками, клиентами и заинтересованными лицами”
Аналитик фиксирует всю собранную информацию касающуюся разработки требований, обрабатывает, документирует сами требования, отслеживает чтобы не было пропусков в требованиях, все взаимосвязи между различными требованиями, обеспечивает одинаковое понимание требований всеми участниками процесса, предусматривает возможность использования требований в будущих проектах, отслеживание и управление рисками проекта, инициирует создание групп лиц принятия ключевых решений и другое.
Понравилось отображение расшифровки подписи на документе (что означает подпись на документе)
«Подтверждаю, что настоящий набор требований наилучшим образом представляет наше понимание требований к этому проекту на данный момент и что описанная система удовлетворит наши потребности. Я согласен вносить в будущем изменения в это базовое соглашение в соответствии с процессом изменения требований, определенным в проекте. Я понимаю, что изменения могут потребовать переоценки стоимости, ресурсов и сроков сдачи проекта»
Приводится пример как не нужно делать вот один из таких примеров если требований много и нужно выбрать часть для реализации в первой итерации продукта, нужно установить приоритет исполнения требований, вы сделали работу но у всех требований остался высокий приоритет, значит вы не сделали работу!
Совет бизнес аналитику: Избегайте конкуренции между требованиями и дизайном
суть требований заключается в том, что система должны делать, а то, как решение будет реализовано
Задача аналитика — понять задачи пользователя настолько, чтобы разработчики могли начать работу над системой при минимальном риске возможных переделок.
Книгу сложно рекомендовать к чтению абсолютно всем, но тем ее осилит, можно сказать что время потрачено не зря.
