Публикую свои примеры порядка работ над созданием технических заданий.

Пока нигде подобного не видел, в RUP'е подобные workflow представлены только фрагементарно.

Интересно увидеть подобный workflow от вас.

Более подробный пример с разбиением на документы.

Денис очень интересная работа. А каким инструментом ты это делаешь? WinCmapTools?

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

Нефункциональные требования определяются как системные и ресурсные ограничения.
А как согласуется это с моделью FURPS+?

Денис очень интересная работа. А каким инструментом ты это делаешь? WinCmapTools?

IHMC Cmap Tools, но можно нарисовать в любом векторном редакторе, типа InkSkape или OpenOffice Draw.

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

Для тех ТЗ, что я пишу последнее время - да.

Нефункциональные требования определяются как системные и ресурсные ограничения.
А как согласуется это с моделью FURPS+?

Прямо согласуется. Я тут не разделяю атрибуты качества и ограничения, может позже - буду.

БПравила определяют логику перехода
БТ - это не совсем цели и задачи
Словарь терминов формируется из понятий в БТ

БПравила определяют логику перехода
БТ - это не совсем цели и задачи
Словарь терминов формируется из понятий в БТ

Это что за поток сознания? )

Это что за поток сознания? )

Это комменты к двум твоим Д.

Это комменты к двум твоим Д.

Т.е. ты мне рассказываешь, как у меня устроено? )

Т.е. ты мне рассказываешь, как у меня устроено? )

В том то и дело что у тебя не так.
Ну хорошо.
1. По первой картинке: БПравила определяют Логику перехода м/у экранными формами, не сами экранные формы.
2. По второй картинке. БТ - это более скорее подцели, т.е. детализация их.
3. По второй картинке. Словарь терминов формируется из понятий в БТ, а не летают в воздухе.

В том то и дело что у тебя не так.
Ну хорошо.
1. По первой картинке: БПравила определяют Логику перехода м/у экранными формами, не сами экранные формы.

Если "У Клиента есть организационная форма" - это бизнес-правило, то и содержание экранов тоже.

2. По второй картинке. БТ - это более скорее подцели, т.е. детализация их.

Ну вот а у меня цели и задачи - это результат трансформации бизнес-требований.

3. По второй картинке. Словарь терминов формируется из понятий в БТ, а не летают в воздухе.

В словарь терминов вносятся все термины, упоминаемые в данном наборе документов. Если на уровне сценариев возникнет понятие Фильтр, то его надо будет внести в словарь.

И ещё одна диаграмма.

Хотелось бы задать вопрос:
1. для чего существует потребность такой взаимосвязи? Т.е. в каком контексте?
2. Какой процесс разработки ПО или ИТ системы заложен в данную взаимосвязь или эта модель применима к любому процессу, любой методологии?
3. Что в данном случае понимается под техническим заданием? Понятие ГОСТ или какое-то иное понятие?
4. Несовсем понятно направление стрелки от описания архитектуры к функциональной спецификации
5. Где место требованиям эргономики (usability)? Они представлены как я вижу только дизайном (причем это явно прототипы форм так называемых форм электронных документов)

6. Вообще имеет ли смысл составлять такое ТЗ, т.е. имеет ли смысл фиксировать это документально?

1. Для того, чтобы понимать порядок и состав работ по созданию требований. В контексте разработки ПО.

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

3. Под техническим заданием (на развитие системы) в нашем случае я как раз в форме диаграммы предлагал понимать совокупность функциональной и технической спецификации.

4. Архитектура накладывает ограничения на функциональную спецификацию, последнюю нельзя создавать в отрыве от неё.

5. У нас нет требований эргономики, вместо них сразу идёт дизайн. Можно пытаться называть это прототипами форм электронных документов, но, во-первых, это не прототипы, а окончательный дизайн, во-вторых, экраны развлекательного сайта имеют мало общего с понятием "форма электронного документа".

6. Вопрос не понял. Это из серии - имеет ли смысл фиксировать требования.

1. Для того, чтобы понимать порядок и состав работ по созданию требований. В контексте разработки ПО.

В контексте создания какого ПО? Судя по твоим отзывом ПО у тебя особенно.

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

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

3. Под техническим заданием (на развитие системы) в нашем случае я как раз в форме диаграммы предлагал понимать совокупность функциональной и технической спецификации.

В таком случае на кого рассчитано это техническое задание? Почему спрашиваю - потому как техническая спецификация - это уже часть проектного решения.

4. Архитектура накладывает ограничения на функциональную спецификацию, последнюю нельзя создавать в отрыве от неё.

С учетом предыдущего пункта можно ли понимать так, что используются некие готовые инструменты(cms, lcms, wiki ...)

5. У нас нет требований эргономики, вместо них сразу идёт дизайн. Можно пытаться называть это прототипами форм электронных документов, но, во-первых, это не прототипы, а окончательный дизайн, во-вторых, экраны развлекательного сайта имеют мало общего с понятием "форма электронного документа".

Пусть так, однако наверняка у вас будут интерактивные формы, меню навигации, догика перехода. Разве она не должна учитывать аспекты usability? По крайней мере, tolldo навел на наш сайт критику именно из-за некорректного usability (по форме регистрации)

6. Вопрос не понял. Это из серии - имеет ли смысл фиксировать требования.

В смысле, а нужно ли тратить усилия на него? По крайней мере в таком формализованном виде...