shelsoft
2) ТЗ: нужно за 3 года сделать ракету чтоб летала за стопицот километров.

Этот документ называниеся тактико техническое задание.

shelsoftТП: будем работать делать прототип ракеты (вот методика и план) пока оно в не начнет летать за стопицот километров.

Это методология разработки, к техническому проекту отношения не имеет.

2 musson

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

От озарений избавляет моделирование и прототипирование системы.
На основании моделей и прототипов выявляются и формулируются требования сначала к бизнес целям проекта (например силами пати менеджеров обеспечить обслуживание 1000 клиентов в день, что на 20% больше существующего практического предела при семи менеджерах), затем к самой системе и к её окружению (обеспечению).
Виды требований которые впринципе следует рассматривать перечислены в ГОСТе. Как правило для разработки программы достаточно выявить только функциональные требования (если разработчик не вполне адекватен, то может потребоваться документирование и других на первый взгляд очевидных требований, например, к лингвистическому обеспечению, чтобы вдруг не оказалось, что программа общается с пользователем на зарубежном языке). Требования других видов нужно выявлять и документировать в особых случаях, как правило при наличии каких то ограничений, например в численности и подготовке персонала (например в штате предусмотрено пять менеджеров которые владеют ПК на уровне пользователя и обучены работе с вашей программой), времени выполнения, надёжности оборудования и климатических условий, в которых оно должно эксплуатироваться.

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

ЮВНо на стадии ТЗ на разработку надо уже выдавать готовый результат - за вполне конкретную сумму и к заданному сроку.

суммы и сроки, это вопрос не столько ТЗ (конечно сроки могут быть обусловлены техническими причинами, например проблемой 2000 года, тогда срок должен быть частью ТЗ), сколько контракта на разработку АС.

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

В ГОСТовом ТЗ предусмотрена возможность проведения НИР (например разработка новых алгоритмов). Естественно, такие работы значительно увеличивают риски проекта, так что может быть рационально разделить проект на подпроекты, от результата которых будет зависеть дальнейшее финансирование работ (например, вечный двигатель никто до сих пор не сделал, так что велика вероятность, что и теперь не удасться его изобрести, потому имеет смысл сначала провести НИР, и если результат будет положительным, приступить к разработке вечного паровоза), однако это далеко не всегда необходимо.

shelsoft,

1)
ТЗ, это не модель системы, а требования к системе и её обеспечению.
Сравни, требование ТЗ - система должна изменять температуру диска в пределах о 0oC до 60oC с точностью 1 oC.

Модель - принципиальная электрическая схема на которой изображёны соединённые термопара и вольтметр.

2)
Требование ТЗ - система должна изменять температуру диска с точностью до 1 oC.

Реализация - на диск налеплена термочувствительная полоска со шкалой, в корпусе дисковой стойки прорезано окошко для наблюдения за полоской.

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

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

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

1) за три года можно было уйти...
2) чё та я тебя не понимаю. Технологии разработчика важны, но это не часть ТЗ. Бери ТЗ и ищи разработчика, которыей использует милую твоему сердцу методологию.

ЮВшифрование данных должно выполняться по алгоритму XXX ...

Алгоритм тоже можно реализовать по разному. Можно написать программу для ПК, можно сделать чип, чтобы шифрование выполнялось аппаратно и т.д. В алгоритме важно не то, в каком порядке выполняются операции (оптимизирующий компилятор наверняка что нибудь "перепутает"), а то к какому результату это приводит.

Если разработчик владеет адекватной технологией, он берётся за заказ. Если не владеет, то бывает, что тоже берётся, с тем расчётом что освоит новую технологию в процессе разработки.

shelsoft,

Что то я не понимаю сложностей с моделями разработки.

Относительно ТЗ, модель разработки регламентирует процедуру изменения его требований. Спираль, подразумевает итерационное изменение и уточнение требований ТЗ по мере их реализации. Так в контракте с заказчиком можно прописать процедуру изменения требований. Типа, в рамках проекта предусмотреть четыре итерации и ограничится пересмотром не более 10% ключевых требований и 20% дополнительных требований за итерацию.

Пусть весь проект разбивается на стадию ТЗ и стадию ТП. По окончании стадии ТЗ заказчик должен получить первую версию ТЗ. Далее идёт согласование и утверждение ТЗ, заключение контракта на разработку АС и проект переходит на стадию ТП. По окончании стадии ТП заказчик должен получить готовый продукт соответсвующий окончательной версии ТЗ (или дополнений и уточнений к нему, если так удобнее для делопроизводства).