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