Telegram Group & Telegram Channel
Польза и вред той самой книги Вигерса 📖

Наверняка вы слышали о «Библии» или настольной книге аналитика (БА/СА) – «Разработка требований к программному обеспечению» Карла Вигерса и Джой Битти

Прочитал ее и делюсь мнением

🔹 Что узнал полезного

– Группы нефункциональных требований (глава 14) – тут они очень подробно расписаны с обилием примеров
– Методика расчета приоритетов (глава 16) по множеству критериев
– Признаки, по которым понятно, что сбор требований завершен (глава 7, ст 159-160) – коротко и ясно
– Правила для составления «идеальных требований» (глава 11) – полезная формула «Система/пользователь должен» «активный глагол» «наблюдаемый результат»
– Утверждение требований (глава 17) – для лидов и старших аналитиков
Про документирование требований и шаблоны SRS (глава 10) – приведенную структуру можно доработать под свой проект

В остальных главах тоже встречается что-то полезное, но по мелочи

⚠️ Что же не так с этой книгой

– Главная проблема – книга морально устарела. Описанный процесс сбора требований был актуален лет 20 назад. Тогда люди готовились месяцами, сидели с пользователями в одной комнате – в общем, целый ритуал. Сейчас сбор требований не такая грандиозная история, а скорее итеративный подход (исключением может быть гос сектор)
– Отсюда идут устаревшие техники и советы. В главе 12 описаны диаграммы UML, но там нет Sequence. В главе 13 пишут про структуру данных в БД, но нет JSON
Некоторые главы вообще можно смело пропускать – например, глава 9 про составление Бизнес-правил (вы их когда-нибудь писали?), глава 18 про Повторное использование требований (в моей практике не встречалось таких случаев)
Вода, из-за которой тут аж 700 страниц. Не все осилят такой объем – признаюсь, что последние несколько глав и я не дочитал

🤔 Стоит ли читать?

Во введении пишут, что книга для всех, в том числе и разработчиков, но по содержанию она подойдет в основном бизнес и системным аналитикам

Прочитать ее полностью стоит начинающим аналитикам, когда многое в голове не структурировано (но помните об устаревших методиках)

А если же у вас есть опыт, то рекомендую не читать все, а выбрать главы, которые вам действительно интересны, чтобы закрыть некоторые пробелы

🙈 Альтернативы?

Несмотря на возраст, книга остается одной из немногих, где системно разобран весь цикл разработки ПО. Более современные книги освещают узкие темы («Пользовательские истории» Джеффа Паттона, «UML. Основы» Мартина Фаулера)

Есть труды англоязычных авторов, типа «Agile Software Requirements» от Дина Леффингвела, но перевод мне не удалось найти

Если вам попадалось что-то более современное, где охвачены такие же темы, и все это с переводом – поделитесь в комментариях, с удовольствием почитаю

——

А вы читали эту книгу? Что думаете? Пишите в комментах

P.S. Данные пост отправляю на конкурс «Продолжи мысль» от @systems_education в номинацию «Критический взгляд»

#книги_системный_анализ
#продолжи_мысль_SE
🔥9



group-telegram.com/system_analysis_max/42
Create:
Last Update:

Польза и вред той самой книги Вигерса 📖

Наверняка вы слышали о «Библии» или настольной книге аналитика (БА/СА) – «Разработка требований к программному обеспечению» Карла Вигерса и Джой Битти

Прочитал ее и делюсь мнением

🔹 Что узнал полезного

– Группы нефункциональных требований (глава 14) – тут они очень подробно расписаны с обилием примеров
– Методика расчета приоритетов (глава 16) по множеству критериев
– Признаки, по которым понятно, что сбор требований завершен (глава 7, ст 159-160) – коротко и ясно
– Правила для составления «идеальных требований» (глава 11) – полезная формула «Система/пользователь должен» «активный глагол» «наблюдаемый результат»
– Утверждение требований (глава 17) – для лидов и старших аналитиков
Про документирование требований и шаблоны SRS (глава 10) – приведенную структуру можно доработать под свой проект

В остальных главах тоже встречается что-то полезное, но по мелочи

⚠️ Что же не так с этой книгой

– Главная проблема – книга морально устарела. Описанный процесс сбора требований был актуален лет 20 назад. Тогда люди готовились месяцами, сидели с пользователями в одной комнате – в общем, целый ритуал. Сейчас сбор требований не такая грандиозная история, а скорее итеративный подход (исключением может быть гос сектор)
– Отсюда идут устаревшие техники и советы. В главе 12 описаны диаграммы UML, но там нет Sequence. В главе 13 пишут про структуру данных в БД, но нет JSON
Некоторые главы вообще можно смело пропускать – например, глава 9 про составление Бизнес-правил (вы их когда-нибудь писали?), глава 18 про Повторное использование требований (в моей практике не встречалось таких случаев)
Вода, из-за которой тут аж 700 страниц. Не все осилят такой объем – признаюсь, что последние несколько глав и я не дочитал

🤔 Стоит ли читать?

Во введении пишут, что книга для всех, в том числе и разработчиков, но по содержанию она подойдет в основном бизнес и системным аналитикам

Прочитать ее полностью стоит начинающим аналитикам, когда многое в голове не структурировано (но помните об устаревших методиках)

А если же у вас есть опыт, то рекомендую не читать все, а выбрать главы, которые вам действительно интересны, чтобы закрыть некоторые пробелы

🙈 Альтернативы?

Несмотря на возраст, книга остается одной из немногих, где системно разобран весь цикл разработки ПО. Более современные книги освещают узкие темы («Пользовательские истории» Джеффа Паттона, «UML. Основы» Мартина Фаулера)

Есть труды англоязычных авторов, типа «Agile Software Requirements» от Дина Леффингвела, но перевод мне не удалось найти

Если вам попадалось что-то более современное, где охвачены такие же темы, и все это с переводом – поделитесь в комментариях, с удовольствием почитаю

——

А вы читали эту книгу? Что думаете? Пишите в комментах

P.S. Данные пост отправляю на конкурс «Продолжи мысль» от @systems_education в номинацию «Критический взгляд»

#книги_системный_анализ
#продолжи_мысль_SE

BY Системный анализ на максималках




Share with your friend now:
group-telegram.com/system_analysis_max/42

View MORE
Open in Telegram


Telegram | DID YOU KNOW?

Date: |

Recently, Durav wrote on his Telegram channel that users' right to privacy, in light of the war in Ukraine, is "sacred, now more than ever." Unlike Silicon Valley giants such as Facebook and Twitter, which run very public anti-disinformation programs, Brooking said: "Telegram is famously lax or absent in its content moderation policy." Pavel Durov, a billionaire who embraces an all-black wardrobe and is often compared to the character Neo from "the Matrix," funds Telegram through his personal wealth and debt financing. And despite being one of the world's most popular tech companies, Telegram reportedly has only about 30 employees who defer to Durov for most major decisions about the platform. Investors took profits on Friday while they could ahead of the weekend, explained Tom Essaye, founder of Sevens Report Research. Saturday and Sunday could easily bring unfortunate news on the war front—and traders would rather be able to sell any recent winnings at Friday’s earlier prices than wait for a potentially lower price at Monday’s open. The Security Service of Ukraine said in a tweet that it was able to effectively target Russian convoys near Kyiv because of messages sent to an official Telegram bot account called "STOP Russian War."
from us


Telegram Системный анализ на максималках
FROM American