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

Nobody faults but mine... (LZ)

Ну хоть кто-то откликнулся...

МайевтикОпишите, что такое "хорошее ТЗ" - получите метрики как отклонения от эталона.
Я могу предположить - идеальное ТЗ, это документ по прочтении которого ни у заказчика, ни у разработчика не возникает никаких вопросов, а выполненный проект не содержит просчетов по функционалу. Понятно, что по каждому пункту в такой расплывчатой формулировке можно придраться, понятно что и заказчик может быть туп, и разработчик туда же и т. п.
Однако хорошее ТЗ от плохого отличается мерой приближения к идеалу.

Я думаю, что если под ТЗ понимается документ с требованиями, то соответственно результат складывается из 2-х составляющих:
1. Качество документа
2. Качество требований
Причем качество требований, как правило, имеет большее значение.

авторА в конкретном случае многое будет определяться целью ревизии ТЗ - какие метрики являются значимыми.
Вот! А как проводить такие ревизии? Вам самим приходилось заниматься чем-то подобным?

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


Nobody faults but mine... (LZ)

авторСоответственно введя шкалы этих оценок и проведя процедуру оценки со стороны ЗЛ мы можем получить взвешенную интегральную оценку ТЗ.
Да, именно так. Вы ухватили саму суть :) Вот только как ее провести?
Майевтик "Забыли важный нюанс" - забыли кто? ) Если люди работают совместно, единой командой, то вопроса про "кто виноват" не возникает - виноваты все.
"Виноваты все" - это не виноват никто. Берем того же Вигерса:
"Я недавно имел дело с группой разработчиков, которая применяла доморощенные
инструменты разработки ПО, в том числе и редактор исходного кода. К сожалению,
ни один из них не записал, что инструмент должен позволять пользователям печа-
тать код, хотя пользователи без сомнения предполагали, что это будет именно так."
В приведенном примере - тестировщики виноваты в отсутствии функции печати? А кодеры? Правильно, виноват либо аналитик (забыл описать, забыл спросить), либо заказчик (не сказал об этом).
Т.е., берем и сравниваем пару ТЗ (для простоты, после внедрения) - скажем, в первом полностью описаны все важные требования, но документ перегружен, трудночитаем и т.д. Второе ТЗ - легкоусвояемое, но упущен ряд критических требований ;). Делаем вывод - первое ТЗ лучше.
Разумеется, это очень упрощенный пример.

LoShuТЗ это тоже "живой" документ и браться за реализацию не проработав ТЗ нельзя -- видимо у Вас не настроен процесс разработки программного обеспечения -- потому как перед началом разработки необходимо произвести review (извините, не знаю русского слова, которое бы наиболее полно отражало специфику данного английского) ТЗ, определить все неточности, неясности, все неописанные моменты и доработаь его (ТЗ) с учетом найденных замечаний. Тогда, в результате, вы получите *качественное* ТЗ и можно будет начинать разработку....
С чего бы это? Откуда такая уверенность, что изначальное ТЗ - сырое, а после однажды проведенного review - готовое? А может, после окончания review, нужно провести re-review?
Имхо, степень проработанности ТЗ в какой-то степени можно определить уже только в процессе эксплуатации проекта.

МайевтикСаша, тут автор треда похоже намекает на то, что ТЗ может в большей или меньшей мере способствовать успешности проекта, типа исключать риск переделки продукта, появления новых требований, которые будут коренным образом менять архитектуру и т.д. Это интересная постановка вопроса, выходящая за рамки понятия "хорошее требование". Здесь всё-таки речь о "хорошем наборе требований", который как система сложнее, чем отдельное требование.
Не намекает, а говорит прямым текстом. Именно так, практически для любого проекта ТЗ всегда включает набор взаимоувязанных требований.

byurНе зависимо от того насколько хорошо мы сформулировали требования, если завтра бизнес посчитает целесообразным открыть например новое направление - ...
Ну, не передергивайте. Причем здесь изменение требований бизнеса? Речь идет о том, что изначальные (будем считать, неизменные на время разработки проекта) требования были либо некорректно описаны, либо про какие-то из них забыли.

Nobody faults but mine... (LZ)

почитал www.uml2
Это именно те вопросы, над которыми я раздумываю. Очень интересно.
Экспертное вычитывание, безусловно хорошая вещь, но, по крайней мере в нашем случае, работает недостаточно - точнее, оно сильно зависит от лиц, которые проводят экспертизу. Заказчик внутренний, ответственность за ТЗ он, как правило, чувствует слабо. Следовательно, важнейшая часть - функциональные требования - остается менее проверенной.


Nobody faults but mine... (LZ)

авторВы и в правду хотите иметь ФОРМАЛЬНУЮ методику оценки ПОЛНОТЫ требований????
Ну, я надеялся, что умные головы за рубежом, которые любят писать методики по всему, добрались и до области составления ТЗ :) Есть же методики подсчета стоимости разработки, есть разнообразные методики оценки качества, в том числе ПО.
авторВсегда есть риск того, что часть требований не выявлена
После внедрения/опытной эксплуатации риск невыявленных требований на момент ТЗ минимален. Могут появится другие требования - но это уже другая история.
По поводу остального все более-менее ясно.
Ну, вобщем уже понял, что никакой методики нет.

Nobody faults but mine... (LZ)