Форум Сообщества Аналитиков
Дисциплины => Системный Анализ и Требования => Тема начата: Denis Beskov от 27 Июля 2007, 19:13:23
-
Публикую свои примеры порядка работ над созданием технических заданий.
Пока нигде подобного не видел, в 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. Вопрос не понял. Это из серии - имеет ли смысл фиксировать требования.
В смысле, а нужно ли тратить усилия на него? По крайней мере в таком формализованном виде...