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: |

As the war in Ukraine rages, the messaging app Telegram has emerged as the go-to place for unfiltered live war updates for both Ukrainian refugees and increasingly isolated Russians alike. "There are a lot of things that Telegram could have been doing this whole time. And they know exactly what they are and they've chosen not to do them. That's why I don't trust them," she said. Emerson Brooking, a disinformation expert at the Atlantic Council's Digital Forensic Research Lab, said: "Back in the Wild West period of content moderation, like 2014 or 2015, maybe they could have gotten away with it, but it stands in marked contrast with how other companies run themselves today." Pavel Durov, Telegram's CEO, is known as "the Russian Mark Zuckerberg," for co-founding VKontakte, which is Russian for "in touch," a Facebook imitator that became the country's most popular social networking site. Again, in contrast to Facebook, Google and Twitter, Telegram's founder Pavel Durov runs his company in relative secrecy from Dubai.
from us


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