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

Эти ограничения могут быть разными в зависимости от бизнес-требований.
ТС привёл пример с удалёнными документами и их историей.
На основании этого примера и развернулась вся дискуссия.
Смотрим ещё раз:

1. После подписания ТЗ исходя из бизнес-требований не следовал однозначный вариант реализации ограничений (по крайней мере, ТС таковых не привёл).

2. Возможно, поэтому, они были реализованы так, как решил программист (ну или как смог, если не хамить словами guest_20040621) - и это сплошное предположение, информации от ТС об этом нет.
3. Последние пару лет назад бизнес-требования не входили в противоречие с выбранным разработчиком вариантом реализации.
4. Сегодня появилось новое требование (по мнению ТС , должен был быть внешний ключ между документом и историей его изменения).
Причём это даже не бизнес-требование, а сформулированное как нефункциональное - к качеству или способам решения.
И выполнение этого нового требования может повлиять на бизнес-требования: из 3-4 вариантов будет выполняться только одно, и не выполняться остальные.

Кто ДОЛЖЕН сказать, что это новое неявно возникшее бизнес-требование и есть правильное? ТС, guest_20040621? За чей счёт это должно быть реализовано?

Так что:
1) бага (явного несоответствия требованиям) нет .
2) согласовывать и оформлять новое требование (запиской, новым ТЗ, ваши варианты ... )

guest_20040621, "5-ка с минусом" ("5-ка" за мощный скил "качество решения", "минус" за просчёты в скиллах "трассировка требований", "выявление требований", "согласование требований", "отслеживание границ проекта").

Как архитектора данных в проект, где особо не требуется обсуждение , и каждый хорошо понимает свои обязанности, можно брать.
Аналитиком или руководителем проекта - противопоказано :).

guest_20040621> нет, не очевидно

Дружище, давайте я ещё немного поработаю КО: возраст у человека существует независимо от наличия или отсутствия документов. Как и, например, гендерная принадлежность. Как в одной базе данных, нарисованной криворукими быдлокодерами, регистрировать данные другой базы данных, нарисованной такими же криворукими быдлокодерами, - отдельная задача.

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

guest_20040621> Эти ограничения пока очевидны только guest_20040621.

Дружище, я пытаюсь донести до вас простую, в общем, мысль: любое техническое задание - набор ограничений, дополняющих естественные ограничения. Набор конкретных ограничений - контекст реализации, понимаете? Допустим, есть промышленные продукты. Контекст - от технологических процессов до системы национальных счетов. Если вы представляете эти контексты хотя бы в общих чертах, вы можете оперировать структурой контекстов, да? Контексты, в свою очередь, представляют собой набор ограничений и регламентов. Понимаете, да? Отсюда - и формат технического задания, и особенности реализации, и прочая хрень. Формальная постановка и формальная реализация вместо псевдокреатива. Проще пареной репы.

Правильно ли я понимаю, что для случая, описанного ТС вы считаете:
1) разработчики должны были при реализации на основании ТЗ и естественных ограничений добавить внешний ключ между таблицей "документы" и таблицей "история изменения документов";
2) разработчики должны согласиться с тем, что это именно "ошибка" в реализованной по ТЗ системе (разработчики и тестировщики виноваты в том, что программа сейчас так работает) ;
3) поскольку разработчики этого не сделали раньше, они должны сделать это сейчас (ну, допустим, в рамках сопровождения системы, прямых своих рабочих обязанностей, или просто потому, что "Во-первых, это красиво" (с) анек).

guest_20040621> Правильно ли я понимаю, что для случая, описанного ТС вы считаете:

Это неправильно заданный вопрос - что должны сделать кодеры и/или их заказчик. Я говорю вам о том, как должна быть построена структура данных . А вы пытаетесь увязать её с договорными обязательствами. Нет такой связи. В принципе нет.

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

В вопросе ТС этот контекст прост:
"Какая система" = "упоминаемая ТСом",
"Кому должна" = "ТСу".

А какой контекст подразумеваете вы в своих суждениях?