В процесі розробки можуть помінятися вимоги. Уявімо, що дресирувальника собак Коточёву знадобився сайт, де актори-тварини знаходяться в розділі відповідної породи. На момент написання ТЗ в цирку їх три: лайки, мопси і чубаті китайські. Але, поки розроблявся дизайн, мопси здійснили зухвалу масову втечу. Коточёв в паніці замінив їх тим, чим вийшло: кішками і папужками. У підсумку розділів з тваринами стає більше. Не будемо ж ми відмовляти клієнтові у внесенні правок, відмахуючись ТЗ - тому воно стає неактуальним.
Або, коли сайт майже готовий, може надаватися, що деякі пристрасно бажані фичи при зіткненні з реальністю - так собі, і краще без них. Так ще 5 сторінок ТЗ втрачають актуальність.
ТЗ - зайвий артефакт, який тільки жере ресурси і потрібен для прикривання дуп. Вреальномміре це важливо, а дляразработкісофта при адекватномобеспеченііресурсов -практіческінет. Мені вистачає прототипів і короткого списку того, чого на прототипах не видно. Виняток - інтеграційні протоколи, це окрема тема і у нас на ніхотдельнийрегламент.
Трактувати ТЗзачастуюможно двояко (ктохочет поспоріть- висилайтевашеТЗ, я на спір іхорошійвіскі знайду в ньому дірки івозможностьдвоякой трактування) .Більше того, в scrum немає такого артефакту. Ми використовуємо ТЗ тільки для раздербаніванія на беклог.
