Короткий ответ саркастичному ![[dreamwidth.org profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
bamalip.
Самые лучшие спецификации я видел там, где их с нуля писали ведущие инженеры и руководители групп. Причём, они были в обычных вордовских файлах.
Незамутнённый "специалист по требованиям" в лучшем случае может откопать информацию и верифицировать её при перекрёстном сравнении. Для валидации нужны специалисты в предметной области.
Мой уникальный скил в requirements engineering - это умение найти лажу в сложных многосвязных информационных структурах.
То есть, я могу выяснить, что инженеры-электрики на самом деле ещё не определились с типом коннектора в требовании XXX.NNN, пять требований из спецификации по безопасности повисли и на самом деле никак не тестируются, а в техзадании на подсистему X требование XXX.XXX.N выведено не из требований пользователя, а из протокола тестирования, и похоже, это не ошибка с неправильно направленной стрелкой, а непонимание иерархии документов.
То, что я мог на приемлемом уровне говорить с инженерами-механиками или со страховыми математиками, - это не результат моих знаний в теории и практике requirements engineering, а честное изучение предмета по внутрифирменной документации и банальным учебникам. Иногда в объёмах полновесного университетского курса.
Программисты никогда не умели писать нормальные требования, потому что мыслят языками программирования. Сертификации и курсы только ухудшили ситуацию, укрепив самомнение и убедив в совершенно ошибочной формуле "Спросите заказчика - он расскажет".
Популярность agile связана во многом с девизом "Всё равно техзадание никто написать не сумеет, потому будем делать как получится, а заказчики потом скажут, что им не нравится."
bamalip.Самые лучшие спецификации я видел там, где их с нуля писали ведущие инженеры и руководители групп. Причём, они были в обычных вордовских файлах.
Незамутнённый "специалист по требованиям" в лучшем случае может откопать информацию и верифицировать её при перекрёстном сравнении. Для валидации нужны специалисты в предметной области.
Мой уникальный скил в requirements engineering - это умение найти лажу в сложных многосвязных информационных структурах.
То есть, я могу выяснить, что инженеры-электрики на самом деле ещё не определились с типом коннектора в требовании XXX.NNN, пять требований из спецификации по безопасности повисли и на самом деле никак не тестируются, а в техзадании на подсистему X требование XXX.XXX.N выведено не из требований пользователя, а из протокола тестирования, и похоже, это не ошибка с неправильно направленной стрелкой, а непонимание иерархии документов.
То, что я мог на приемлемом уровне говорить с инженерами-механиками или со страховыми математиками, - это не результат моих знаний в теории и практике requirements engineering, а честное изучение предмета по внутрифирменной документации и банальным учебникам. Иногда в объёмах полновесного университетского курса.
Программисты никогда не умели писать нормальные требования, потому что мыслят языками программирования. Сертификации и курсы только ухудшили ситуацию, укрепив самомнение и убедив в совершенно ошибочной формуле "Спросите заказчика - он расскажет".
Популярность agile связана во многом с девизом "Всё равно техзадание никто написать не сумеет, потому будем делать как получится, а заказчики потом скажут, что им не нравится."
