Требования, ИИ, составление блок-схемы

1. Вводная часть: планировщик разрабатывает не 'экран', а 'процесс'

В IT-индустрии роль планировщика сервиса часто ошибочно воспринимается как 'человек, который делает эскизы и рисует экраны'. Это связано с тем, что работа по расстановке кнопок и созданию вайрфрейма наиболее заметна.

Однако визуальный экран является лишь 'результатом' множества логик и стратегий, определенных планировщиком. Настоящая роль планировщика заключается в том, чтобы переводить неясные требования бизнеса на 'структурный язык', понятный для разработки и дизайна, и тщательно управлять полным жизненным циклом продукта (Product Life Cycle) — от начала сервиса до финального QA перед запуском.

Я хотел бы поделиться практическим опытом создания новой службы управления справочной информацией о судне, решая проблемы и развиваясь через три основных столпа планирования: требования, IA, и флоучарты.

2. Анализ и определение требований: ключевые моменты SRS, найденные в дни, когда мы спешили заполнить экран

Когда мы ведем проект, мы получаем множество запросов от пользователей или клиентов, как 'пожалуйста, добавьте эту информацию на экран', 'пожалуйста, добавьте эту функцию'. В начале своего планирования я тоже спешил просто заполнять эти запросы на экране беспрекословно. В первую очередь я сосредоточился на создании кнопок и размещении полей ввода, визуализируя требования. Однако, ведя новый проект и глубоко анализируя процесс планирования, я осознал, что этот процесс является ключом к определению требований.

2.1 Четыре этапа анализа требований

В практике я прошел через четыре этапа: исследование целесообразности, извлечение и анализ требований, определение требований, проверка и управление требованиями, чтобы создать основу для работы с неясностями.
[1. Исследование целесообразности] ➔ [2. Извлечение/анализ требований] ➔ [3. Определение требований] ➔ [4. Проверка/управление требованиями]

• Исследование целесообразности

• Мы проверяем необходимость продвижения проекта и осуществимость (Техническая/Бизнес целесообразность) по сравнению с ресурсами.

• Извлечение и анализ требований

• Мы собираем и упорядочиваем функциональные требования системы от пользователей (юзеров). Планировщик не просто должен пассивно записывать, но задавать необходимые вопросы и определять юзкейс (Use Case) в форме сценария с точки зрения пользователей.

• Определение требований

• На основе проанализированных сценариев мы четко формулируем функциональные элементы, описывающие поведение системы, а также свойства системы, ограничения и производительность, которые относятся к нефункциональным элементам.

• Верификация и управление требованиями

• Мы проверяем, "соответствует ли это пожеланиям клиента", "возможно ли это технически", "может ли это быть проверено тестированием" и учитываем мнения разных частей (разработка/дизайн/бизнес). После этого мы продолжаем отслеживать историю изменений (дата изменения, измененные пункты и т.д.).

Что нужно учесть при анализе требований

Во время анализа требований у меня появились некоторые практические рекомендации.

• Содержимое должно быть проанализировано как можно более подробно:Не просто 'нужна функция входа', а нужно углубиться в 'какими способами и какое исключение будет обрабатываться'.

• Записывайте термины, используемые специалистами:Чтобы уменьшить количество коммуникационных ошибок, на начальном этапе мы архивируем слова, которые используют доменные эксперты или специалисты.

• Письменное согласование и подтверждение:Убедитесь, что оформленный материал обязательно отправлено заинтересованным лицам по электронной почте или официальным инструментам совместной работы, и получите финальное подтверждение. Это станет барьером для будущих споров о диапазоне (Scope).

2.2 Составные элементы и пример написания документа спецификации требований (SRS)

Документ спецификации требований (Software Requirement Specification) описывает, "как система будет выполнять свои функции, а не что она будет выполнять".

• Ключевые составные элементы:ID требования, классификация/элемент, подробное содержание, запрашивающий/дата запроса, важность (приоритет), сложность, приемлемость, ответственный, мнение ответственного, замечания

Пример практического руководства по документации требований

Контрольный список для обзора спецификаций требований

С помощью нижеприведенного контрольного списка вы можете проверить, правильно ли整理ованы требования.

• [ ] Все требования не являются неопределенными и ясными и конкретными?

• [ ] Являются ли исключительные ситуации и обработка ошибок явно включенными помимо нормального потока?

• [ ] Возможно ли технически реализовать на текущей инфраструктуре и ресурсах?

• [ ] Приведены ли тестируемые критерии, которые четко различают истинные и ложные результаты тестов?

• [ ] Не конфликтует ли одно требование с логикой других требований?

• [ ] Являются ли соблюдение Закона о защите персональных данных и другие вопросы безопасности и соблюдения норм отражены без пропусков?

• [ ] Установлены ли приоритеты (высокий/средний/низкий) в соответствии с этапами?

3. Проектирование структуры сервиса (IA, блок-схема)

3.1 Схема информации (IA, Information Architecture)

Теперь мы систематически проектируем всю экранную и меню-структуру сервиса.Схема информации (IA, Information Architecture)Переходим к этапу разработки. Когда мы сталкиваемся с огромными данными о судах в состоянии белого листа, необходимо классифицировать и группировать основные и подменю, чтобы пользователь не заблудился в системе и создать плотную структуру глубины.

• Правило проектирования глубины:Для снижения сложности пользователя и уменьшения усталости, по возможности все меню следует проектировать на уровнедо 3-х уровней глубины.Хотя в сложной структуре, такой как система управления судами, может потребоваться много экранов, которые должны отображаться поэтапно, это также должно сопровождаться предварительными усилиями по минимизации глубины на четком логическом основании.

• Правило руководства по идентификаторам экранов:Все страницы, зарегистрированные в IA, имеют уникальный идентификатор экрана.

• Аббревиатура названия меню 1-2 уровня:Название основного меню сокращается до 2 заглавных букв латинского алфавита. (Например: Управление участниками ➔ MB)

• Код разделения по глубине: Правила разделения экрана по числам с различными глубинами. (например: MB_01, MB_01_01)

• Краткая форма разделения экрана: Также можно разделить по форме в зависимости от деталей (Список, Детали, Попап и т.д.) добавив суффикс.

• Абсолютные правила: ID ни в коем случае не должен дублироваться, и даже если какой-либо ID изменяется или удаляется из-за изменений в планировании, его не следует повторно использовать на других экранах — это принцип управления историей.

• Основные компоненты IA: Классификация, глубина сервиса (1/2/3), номер экрана сервиса, ID экрана, определение страницы и требования, детали, этап выполнения (Ожидание/В стадии планирования/Завершено)

3.2 Диаграмма потока (Flowchart)

Диаграмма потока — это документ, который визуализирует путь перемещения пользователя и процесс обработки системой по экрану и функциональным единицам. Это помогает пользователю понять, каким образом он использует сервис и как система работает внутренне.

Особенно в управлении судами, которое я вел, во время планирования возникло множество экранов, которые органически переплетались или возникали сложные ситуации обработки данных без перерыва. Сначала, даже если я подробно и долго записывал текстовые исключительные случаи рядом с вайрфреймами сценарного плана (документа проектирования экранов), было невероятно сложно донести свою планировочную идею на 100%.

Чтобы решить эту проблему, я нарисовал диаграмму потока, соблюдая международные стандартные символы (Начало, Процесс, Условие и т.д.) и передал ее разработчикам. Я сосредоточился на том, чтобы четко провести поток согласно условным переходам (ромб), чтобы движение пользователя не путалось.

Международные стандарты, которые необходимо соблюдать при составлении диаграммы потока

• Использование стандартных символов: Строгое соблюдение международных стандартных символов, таких как Начало/Конец (круглый квадрат), Процесс (прямоугольник), Сравнение/Условие (ромб) и т.д.

Представительная международная форма программы (международный стандарт ISO 5807)

• Поток внимания: Общий путь пользователя должен плавно проходить слева направо или сверху вниз.

• Разветвление суждений: При использовании знака ромба (сравнение/суждение) результат чаще всего отображается стрелкой вниз, если ответ Yes, и стрелками влево/вправо, если No.

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

• Рекомендуемые инструменты: На практике чаще всего используются Draw.io, Visio, Axure, а также популярные в последнее время Figma и Miro.

4. Заключение: крепкая основа создает безупречный сервис

То, что я ощутил при планировании службы справочной информации о судах, заключается в том, что планировщик является не просто 'человеком, рисующим экран', а скорее 'архитектором системы', который строит плотную 'логику' и органический 'процесс'.Системный архитекторЭто так.

Если бы я сосредоточился только на дизайне экрана на начальном этапе, я бы никогда не смог запустить эту массивную службу данных. Это стало возможным благодаря тому, что я уточнил требования на переднем плане, создал каркас с помощью IA и организовал поток с помощью диаграммы потоков.

Если в этой статье я надежно укрепил верхние концепции и структуру службы, то в следующем посте я намерен поделиться опытом создания 'финального дизайна экрана (сценарный план)' для общения с дизайнерами и разработчиками, основанным на такой структуре. Кроме того, я вернусь с практическими историями о том, как я провел тестирование (QA), чтобы поднять качество продукта до максимума перед запуском услуги.

Рю