Здравствуйте.

У меня вопрос по структуризации технических заданий.

Если система очень огромная и технических заданий очень и очень много, то кто как структурирует ТЗ?

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

Вопрос абстрактно-гипотетический или реально-практический? Если последнее - то декомпозиция Вам ответ. Вообще в классическом ТЗ от ГОСТ 34, все уже есть и сказано: сначала идут требования к системе в целом, потом идет явная иерархическая декомпозиция. Если каждая подсистема - есть суть самостоятельные системы, а общее ТЗ - есть ТЗ для интеграции, то ответ довольно очевиден.

Кроме того, то что Вы спросили, является классической задачей проектирования баз данных на базе функциональных зависимостях - т.е. нормализации. По-моему идеи те же.

Спасибо за ответ 

Вопрос реально-практический.

Понимаете, ГОСТ-ы и все такое - это хорошо. Но меня интересует, кто как на практике делает.

Понимаете, ГОСТ-ы и все такое - это хорошо. Но меня интересует, кто как на практике делает.

Вас понял.Сам предельно не сталкивался с проблемой больших ТЗ. Как-то обходимся. Подождем, что скажут другие.

Уточните, пожалуйста,  что именно вы пытаетесь структурировать:
  * требования к системе в целом, которые дают пониманием как и что уже работает и куда новые требования "вписывать".
Я структурировала требования по подсистемам. 
  * или речь о структуре самого ТЗ на разработку, в котором должно быть описано все-все?

Если мы говорим о хранении и поддержке актуального БОЛЬШОГО ТЗ, то тут как раз начинают использовать системы по управлению требованиями (СУТ).
Т.е. уже спицифика зависит от того, где вы будете хранить ТЗ. Я бы назвал 3 оснонвых типа СУТ:
1. Ворд + система версионного контроля.
2. Вики
3. Специализированные СУТ, такие как EA, Doors, ReqPro и т.д.

Все имеет свои + и -, поэтому нужно изучать, смотреть, пробовать.

Пусть мы делаем систему для некого ведомства. Например для "санэпиднадзора". Глобальную на все регионы, с глобальной базой и мобильными рабочими местами. Будет учет лицензий, организаций, аудитом и прочего всего.
Будет 15-40 модулей по 20-150 юзкейсов каждый. 3 000-20 000 одновременно работающих сотрудников + вебдоступ к личным кабинетам для клиентов ведомства.

Короче с "го и гейшами", "вистом и куртизанками", "маджонгом и кисэн".
------------------------------------------------------------------
Структура:
Головное ТЗ, в котором:
* о функциональности совсем чуть чуть, общими словами
* виды обеспечения (лингвистическое, ...)
* требования к системе в целом, можно в разрезе атрибутов качества ГОСТ 9126 (удобный классификатор) кроме функциональной группы
* и прочая и прочая

Та каждый модуль пишутся ЧТЗ (частное ТЗ). Структура:
* ПМИ (программа и методика испытаний) - обязательный раздел, без этого не сдадите
* инфологическая модель данных, легко сделать в виде выходных форм - обязательный раздел, без этого программисты не напишут программу
* функциональные требования - желательный, но не обязательный раздел

Это скелет. Вполне рабочий. Дополняется по мере необходимости разными доп главами.
* Так например, может оказаться требованием описание API к сторонней системе. Вы его не проектируте, оно уже есть, его поддержать надо.

* Отдельный секретый документ "заинтересованные лица и их интересы". Его заказчик показывать не надо, но из него должна родиться или глава или документ "Роли / Акторы и их область действия".
-----------------------------------------------------
Примерно так. При таком делении вполне реально поддерживать документы просто в ворде. Да, не АфторИт, не EA, Doors, ReqPro, но ворда хватает.

Примерно так. При таком делении вполне реально поддерживать документы просто в ворде. Да, не АфторИт, не EA, Doors, ReqPro, но ворда хватает.

Хотелось бы понять, в каких случаях тогда имеет смысл использовать ПО для управления требованиями? Или это дело вкуса/привычек организации рабочего процесса?

Хотелось бы понять, в каких случаях тогда имеет смысл использовать ПО для управления требованиями? Или это дело вкуса/привычек организации рабочего процесса?

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

Хотелось бы понять, в каких случаях тогда имеет смысл использовать ПО для управления требованиями? Или это дело вкуса/привычек организации рабочего процесса?

Не путайте теплое с мягким. Разработка требований отдельно, управление отдельно. Это совершенно разные вещи. Их  даже разные люди делают.

Что касается фиксации, то дело привычек организации. я, например, почти все проектирование делаю в тетради в клетку формата А4 цветными ручками. А для фиксации и обмена чаще всего использую MSoffice + почта / сисетма версионирования / ...

Уточните, пожалуйста,  что именно вы пытаетесь структурировать:
  * требования к системе в целом, которые дают пониманием как и что уже работает и куда новые требования "вписывать".
Я структурировала требования по подсистемам. 
  * или речь о структуре самого ТЗ на разработку, в котором должно быть описано все-все?

У меня вопрос больше касался как можно соединить все-все ТЗ (в том числе и требования) на систему так, чтобы, если что-то меняется не править во многих местах. 

Всем спасибо за ответы  И хотелось бы еще услышать пару дельных советов 

По поводу того, как лучше хранить ТЗ - в данном случае (в фирме много сотрудников) - и для меня лучше не хранить ТЗ в формате Word, и делать рассылку по почте людям тоже не удобно.

Мы используем ВИКИ.

У меня вопрос больше касался как можно соединить все-все ТЗ (в том числе и требования) на систему так, чтобы, если что-то меняется не править во многих местах. 

Не знаю как другие делают, к сожалению, поделюсь своим предыдущим опытом работы с требованиями в вики.
был кластер по системе . Структура со временем сложилась достаточно стройная. В кластере были разделы для разработчиков, админов, требований(!), Видений (прости за хромую терминологию) и  иногда для пользователей с инструкциями.
В разделе с видениями были страницы с описаниями проектов:
  * заказчики\цели\сроки
  * описание текущих процессов (если нужно)
  * варианты решения с + и - . В данном случае детализация не высока.
  * раздел с детальным описанием выбранного варианта решения, в котором как раз таки стояли ссылки на требования.
  * раздел с описанием изменений в архитектуре системы (этот раздел поддерживался разработчиками и архитектором системы)
  * раздел с планом работ, если проект крупный (не всегда был такой раздел, поддерживался ПМом)
В разделе с требованиями
  * ссылка на словарь предметной области, скажем так
  * ссылки на требования (у меня больша часть требования была в виде вариантов использования), сгруппированные по подсистемам.  Подсистемы можно выделять по различным признакам, конечно. Требования могли ссылаться друг на друга.
  * ссылки на требования нефункциональные
А какая система, кстати? Каково ее назначение?

У меня вопрос больше касался как можно соединить все-все ТЗ (в том числе и требования) на систему так, чтобы, если что-то меняется не править во многих местах. 

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

В разделе с требованиями
  * ссылка на словарь предметной области, скажем так
  * ссылки на требования (у меня больша часть требования была в виде вариантов использования), сгруппированные по подсистемам.  Подсистемы можно
выделять по различным признакам, конечно. Требования могли ссылаться друг на друга.
  * ссылки на требования нефункциональные

вот в том то и проблема - что ссылка на ссылке    мы так и делаем.

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

итог: время от времени я сижу периодически просматриваю все ТЗ и дублирующиеся удаляю, и обновляю информацию.

и шаблоны, где что должно лежать, и как оформляется и название, и само ТЗ - есть, но это не помогает 

А какая система, кстати? Каково ее назначение?

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