А6дулла
Налицо и в этом треде, и в моей практике незнание нашей IT-средой роли "архитектор".
Ни программисты, ни заказчик чаще всего не имеют такой квалификации, с его функции выполняет кто попало - от ведущего программиста до РП.
IMHO кроме ведущего программиста, с большим опытом, но больше обучающего других, чем пишущего самостоятельно, эту роль не может взять никто.
Архитектор, оторванный от разработки, и тем более 20-летний студент-"архитектор", который знает всё только в теории - беда.
РП-архитектор - ещё большая беда: у него есть власть продавить свои глупости, а потом свалить неудачи на то, что разработчики не поняли его "гениальных" идей.

А6дулла
Например, как я видел, эту роль выполняет программист - он изо всех сил старается натянуть проект на ту технологию, которой лучше всего владеет, либо срочно хочет овладеть, потому что она модная!
Я тоже такое видел. Одна такая картина складывается у меня на глазах - архитектура фреймворка столь "изящна", и при этом глючна и недокументирована, что её понимают только 2 человека из ~10, да и то один из них - "архитектор" - только в теории. Остальные 8 вынуждены быть кодерами.
А вы назначайте архитектором не самого заумного и умеющего себя продавать, а того, кто имеет опыт доведения дел до конца, а значит - обладает здоровым прагматизмом и консерватизмом.

А6дулла
Архитектор же должен знать, как системы делаются В ПРИНЦИПЕ, а не на Oracle или WPF, как правильно уложить новую систему в уже имеющийся ландшафт, оценить риски/плюсы разных реализаций, выбрать сбалансированную и предусмотреть в архитектуре сценарий ее будущего развития!
IMHO правильные, но очень общие слова. Таких людей единицы, они дороги, ими трудно управлять - отсюда неприменение и незнание.

Диез<...>
Нее, я такой документ в жизни бы не подписал! :) Представляете, какой простор для трактовок?Я бы, как исполнитель, не подписал другой. Более того, сильно задумался, если бы исполнитель потребовал от меня, как заказчика, точной, не терпящей изменений спецификации требований и архитектуры до начала проекта.

Знаете, есть такая форма забастовки - "сидячая". При ней каждый сотрудник делает только то, что прописано в его должностных обязанностях. При этом работа обычно становится бессмысленной и через некоторое время втаёт. Разработку строго по ТЗ можно превратить в такую же сидячую забастовку. Самое противное, что не заплатить оклад за сидячую забастовку - незаконно.

Тема - " предварительное ТЗ, составленное закачиком ИС ". Вы хотите, чтобы в нём было описано всё? А сколько это проектировать и писать? Кто за это заплатит? Будет ли человек уровня тех. директора, принимающий решение о финансировании, читать "кирпич" в 300-500-1000 страниц? Который, к тому же, устареет в течение месяца?

Диез
Я, как исполнитель, потребовал бы точного указания списка полей счета, с указанием типа и поведения каждого поля.Разумеется, должно быть требование, а то и термин в глоссарии: счёт - документ, состоящий из... по форме... пример... Но никак не в ТЗ. Если говорить в терминах ГОСТ - в ЭП.

Диез
Это по сути описание UI в абстрактных терминах: текст, список, таблица etc.Получается, UI проектирует заказчик, причём изначально, с нуля? Т.е. должен оплачивать работу проектировщика? Такое бывает только если заказчик - фирма, разрабатывающая ПО, и отдающая компонент на аутсорсинг.
GUI лучше обсуждать, показав будущим пользователям системы интерфейсный прототип.

Диез
Иначе за месяц до сдачи проекта заказчик скажет, мол, мы добавили 20 новых полей в определение счета, а в договоре сказано: "инициировать создание нового счёта..." Делайте!
1) Счёт - вполне стандартный документ. Если исполнитель не учёл 20 полей (их общее кол-во примерно таково) - значит, у него нет людей, компетентных в документообороте и бух. учёте, сам виноват.
2) Изначально определние счёта было... Изменение будет стоить X рублей, Y недель.
3) Если добавить несколько полей в форму, БД и отчёт - проблема, значит, архитектура очень плоха.
4) Тех. директор, читающий предварительное ТЗ, понятия не имеет о форме счёта. IMHO её лучше зафиксировать непосредственно перед реализацией счёта, опросив будущих пользователей и их начальство. До этого, для долгосрочного и среднесрочного планирования, достаточно детализации на уровне стандартного счёта.

Диез
С другой стороны, я, как заказчик, имею полное право желать, чтобы "по нажатию клавиши 'Tab' происходил последовательный переход по полям формы сверху вниз". Вполне понятное функциональное требование (думаю, с кривыми табордерами сталкивались все.)
"Система должна поддерживать массовый ввод."

Наверное, наши разногласия связаны с тем, что, насколько я понимаю, вы считаете, что в требованиях можно учесть всё и сразу. Что архитектуру и GUI можно продумать во время формализации требований, ещё до того, как известны все требования. Что требования слабо подвержены изменениям. Распространение agile, книги "классиков" управления требованиями (Вигерса, Коберна, Леффингуэлла) и мой опыт говорят, что это не так.

Диез
Корень наших разногласий, ИМХО, состоит в том, что вы считаете заказчика и исполнителя партнерами, делающими общее дело. А я считаю их юрлицами, каждое из которых стремится извлечь максимальную выгоду для себя.
Наверное, мне просто везло с проектами: всякий раз заказчик и исполнитель были именно партнёрами, и одновременно извлекали из этого максимальную выгоду для себя.

Разумеется, во всяких паталогических случаях, когда заказчик невменяемо жаден или по какой-то причине занимается саботажем разработки, либо исполнитель неспособен/не собирается ничего разрабатывать и хочет денег за безрезультатный процесс, жёстко зафиксированное, формальное ТЗ должно быть. А в остальных эта фиксация только мешает делать дело. В результате заказчик получает не то, что ему нужно, а разработчик - дурную славу.

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

bebop<...>
Размер ПО - 420 000 строк. Полная документация на ПО - 40 000 страниц.
Спецификация на фичу из 6 000 строк кода - 2500 страниц.
<...>
1) Умеют же разводить. Вот интересно, можно ли на 1253 странице найти слова Lorem Ipsum?
2) Возможно, это спецификация функции расчёта необходимой коррекции траектории с учётом уменьшающейся массы, инерции, гравитационных воздействий, состояния систем и ещё 1000 вещей. Copy-paste из десятка учебников физики.
3) Если шаттл рухнет - это будет стоить США престижа. Ну, ещё это будет стоить человеческих жизней и денег.
4) Программу шаттлов сворачивают - слишком дорого даже для США.
5) Возможно, функцию писали, когда у 30-килограммового суперкомпьютера шаттла памяти было всего на 10000 строк. Деваться-то некуда :) .