Неточные требования и удовлетворение заказчика/пользователя

В одной из недавних блогопубликаций наткнулся на мудрую цитату из книжки "Автоматизированное тестирование программного обеспечения" (Дастин-Рашка-Пол):
(жирным шрифтом автор выделил по его мнению главную фразу предложения)

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

Коллеги, а вы согласны с этим тезисом?

Тоже наткнулся на эту блогозапись запись. Цитата мне так понравилась, что я даже сохранил ее у себя в заметках.
Совру, если скажу, что согласен с цитатой из личного опыта, скорее на уровне интуиции.

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

Коллеги, а вы согласны с этим тезисом?

В целом, да.

Примерно 30% дефектов вносятся в программный продукт на стадии подготовки требований
© Стив Макконнелл "Сколько стоит программный проект" (http://www.labirint.ru/books/138619/)

Именно поэтому сначала нужно вводить контроль качества ДО кодирования и лишь после этого внедрения - после кодирования. http://blog.shumoos.com/archives/224

В одной из недавних блогопубликаций наткнулся на мудрую цитату из книжки "Автоматизированное тестирование программного обеспечения" (Дастин-Рашка-Пол):
(жирным шрифтом автор выделил по его мнению главную фразу предложения)

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

Коллеги, а вы согласны с этим тезисом?

С другой стороны, заказчик некоторые вещи может упустить из виду, а конечному пользователю часто бывает просто некуда деваться, в итоге все просто привыкают - используют обходные пути и т.п (это сплошь и рядом, взгляните хотя бы на свой телефон). Я правда не знаю, в каком контексте тут упоминаются не точные требования. Они полные, но не точные? Ну и также понятно, что абсолютно точных требований быть не может, все это довольно условно.

В одной из недавних блогопубликаций наткнулся на мудрую цитату из книжки "Автоматизированное тестирование программного обеспечения" (Дастин-Рашка-Пол):
(жирным шрифтом автор выделил по его мнению главную фразу предложения)

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

Коллеги, а вы согласны с этим тезисом?

Я тоже в целом согласен с тезисом, но в отрыве от контекста он выглядит довольно категорично, что мне не нравится. Вероятно, к тезису следует добавить оговорку, что результат будет неудовлетворительным в [подавляющем] большинстве случаев (но не всегда), а также при условии, что архитектор и кодер делают только то, что им сказали, не высовывая свой нос за сферу своей ответственности. В моей практике были случаи, когда несмотря на неточные требования, результат бывал вполне удовлетворительным. Это происходит, когда команда старается разработать полезный продукт, а не просто реализовать чьи-то требования. Но надо сделать замечание, что тут всё очень сильно зависит от формата команды, от принятых в ней процессов.

Выделение жирным не очень понял. Присутствие в формулировке тезиса заказчика тоже не понял, ведь заказчик не должен быть удовлетворён непосредственно программой, так как он ей не пользуется.

В одной из недавних блогопубликаций наткнулся на мудрую цитату из книжки "Автоматизированное тестирование программного обеспечения" (Дастин-Рашка-Пол):
(жирным шрифтом автор выделил по его мнению главную фразу предложения)

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

Коллеги, а вы согласны с этим тезисом?

А вдруг сделают лучше чем хотелось в этих неточных требованиях?

Коллеги, а вы согласны с этим тезисом?

1111111

Коллеги, а вы согласны с этим тезисом?

Согласна, однако, исключения могут быть.
Неточные требования - ПО не соответствует требованиям.
В данном случае не оговаривается - не точны требования в ТЗ или, вероятно, в период всего процесса развития программы заказчик (и, предполагаю, его команда) не смогли написать, объяснить точных требований, а на стадии приемки и эксплуатации ПО - они вдруг прозревают - разные ситуации бывают. Предполагаю, речь и о том, что пропущена стадия отладки ПО, когда "встречаются" лично или удаленно обе стороны, либо с участием посредника и, демонстрируя ПО, согласовывают все нюансы и вносят корректировки, либо этот этап был формальным. Я сторонник теплого взаимодействия групп заказчика и разработчиков. Конечно, итоговые решения по принципиальным вопросам принимают руководители сторон.
Чем крупнее проект, тем больше заинтересованных сторон и различаются их требования, тут еще вопрос и компетентности разработчиков и лояльности разноперых групп заказчиков, а также той силе такта и убеждения, что приходится в таких случаях проявлять ответственным причастным к разработке. А также продуманные возможности ПО в части индивидуальных настроек.

Хорошо, что все согласны, но давайте определимся -- кто что понимает под "точными" и "неточными" требованиями?

Очень хороший вопрос был у Валерия -- могут ли быть требования полные, но неточные?
Или, наоборот -- неполные, но точные?
Как соотносится точность и детальность?
Бывают ли требования точные, но непонятные? (мне кажется, что я видал такие)

Хорошо, что все согласны, но давайте определимся -- кто что понимает под "точными" и "неточными" требованиями?

Очень хороший вопрос был у Валерия -- могут ли быть требования полные, но неточные?
Или, наоборот -- неполные, но точные?
Как соотносится точность и детальность?
Бывают ли требования точные, но непонятные? (мне кажется, что я видал такие)

Если подойти формально, то требования всегда не полны и не точны. Ну, так же, как нельзя найти все ошибки или на 100% протестировать. :)
Многие требования дополняются на ходу исходя из гайдлайнов, здравого смысла и многих других источников - к примеру, как должна ругаться программа в том или ином случае. Я думаю, одни из самых детальных, точных и понятных требований должны быть в конторах типа НАСА, т.е. чем выше цена ошибки, тем качественнее должны быть требования.

Собственно, по свежим новостям.
И абсолютно про Требования.

"Москва. 17 декабря. INTERFAX.RU - Аварийный запуск трех спутников "Глонасс-М" 5 декабря произошел из-за неправильно написанной формулы в технической документации на заправку разгонного блока ДМ-03, заявил "Интерфаксу" в пятницу глава межведомственной комиссии по расследованию причин аварии, гендиректор ЦНИИМАШ Геннадий Райкунов. "

Ссылку надо давать? Ну вот -
http://www.interfax....t.asp?id=169663

А могли ли тестировщики найти сию ошибку (предположим -- что контроль заправки осуществляется в ПО )