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

Да мне он тоже особо не нужен и важен. Этот ГОСТ . Но есть и иные стандарты: IEEE, ISO и т.п.

В общем твоя позиция мне понятна

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

Т.е. описание классов будет составлять программист?

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

При описании он будет пользоваться модулем (назовем это так), который еще на разработан, чтобы получить некоторую информацию об описываемом классе из системы (или среды - непонятно, несколько там систем или одна)?

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

А сам модуль нужен для того, чтобы ускорить процесс получения информации о классе в процессе описания, и сделать ее единообразной?

Именно так.

И на этот модуль было написано ТЗ, которое кому-то не понравилось?

Да было написано ТЗ в духе ГОСТ 34, которое оказалось непонятным для соотвествующих читателей

Это вопросы по частной задаче (собственно, это и есть задача, как я поняла).

Совершенно верно - это частное ТЗ

А более общая задача, с которой вы начали: постановка процесса работы с требованиями. Документ "техническое задание" или "постановка", или еще как, будет только одним из пунктов реализации этого процесса.

Смысл заключался в том какую форму лучше принять и как она может влиять на процесс управления требованиями и их изменениями и интегрироваться в общий цикл разработки

Так вот о чем речь сейчас - об общей задаче или о частной?

Пока речь идет о частной задаче

Может темы разделить все-таки?

Да возможно Вы правы.

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

Но пожалуй уже поздно

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

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

IMHO  нужно документировать классы/методы в процессе проектирования, чтобы программист получал готовую спецификацию и только исполнял ее в соответствии с определенными нормативами по времени. Таким образом документация будет создаваться по мере продвижения разработки ДО того, как что-то будет закодировано. Ну а программист станет, наконец, обычным кодером и займет свое положенное место в пищевой цепочке.

Ничего личного.

А если классы разрабатываются программистами? Не везде же есть отдел проектирования, где ребята проектируют, а после чего программист только кодирует.

и что, пользователь теперь должен документацию писать чтоли, как в соседней теме?

и что, пользователь теперь должен документацию писать чтоли, как в соседней теме?

пользователем и будет программист.

даже если его должность - программист, и он обладает соответствующей квалификацией, с точки зрения системы он всё равно будет ПОЛЬЗОВАТЕЛЕМ, как бы это ни было унизительно для него :о))