Прибыль:
- Способность различать функциональные и нефункциональные требования и писать четкие, измеримые выражения требований при поддержке искусственного интеллекта.
- Возможность использовать искусственный интеллект со структурированными подсказками для извлечения пользовательской истории, критериев приемки и ограничений объема из записей собеседования.
- Приобретение привычки проверять сгенерированные ИИ требования на предмет двусмысленности, противоречий и отсутствующих правил и подтверждать их заинтересованным сторонам.
Анализ требований — это задача полного, ясного и проверяемого определения того, что должна делать система. Это один из этапов, на котором специалист по ИСУ приносит наибольшую пользу; потому что ошибка здесь растет в геометрической прогрессии в конце проекта. Существует два основных типа анализа требований. Функциональное требование описывает работу, которую должна выполнять система: «Система должна отправить клиенту электронное письмо после подтверждения заказа». Нефункциональное требование описывает, какой должна быть система: такие качества, как производительность, безопасность, удобство использования и доступность. «Экран отчета должен открыться менее чем за 2 секунды при средней нагрузке» — это нефункциональное требование.
Хорошее требование имеет три характеристики: оно ясное (имеет единственную интерпретацию), измеримое (имеет проверяемый порог) и прослеживаемое (ясно, из какой бизнес-потребности оно исходит). «Система должна быть быстрой» не отвечает ни одному из этих требований; «быстро» субъективно, его нельзя измерить, нельзя протестировать. На этом этапе ИИ является мощным помощником в составлении требований и выявлении неоднозначных формулировок; но только заинтересованная сторона решает, какое бизнес-правило является реальным.
Пользовательская история и критерии приемлемости
Распространенным форматом при написании современных требований является пользовательская история: «Как [роль], для [цели], я хочу [функцию]». Пример: «Как торговый представитель, мне нужен расчет скидки на экране мобильного телефона, чтобы я мог быстро делать расценки на местах». История короткая и ориентирована на бизнес; Оно не навязывает технического решения.
У каждой истории должны быть критерии приемлемости: проверяемые условия, которые должны быть выполнены, чтобы история считалась «хорошей». Часто используемым шаблоном является шаблон «Дано/Когда/Тогда»: «Дано: клиент находится в VIP-сегменте. Когда: заказы на сумму более 10 000 TL. Затем: система применяет скидку 5%». Этот шаблон устраняет двусмысленность, поскольку четко связывает условие и ожидаемый результат.
Совет: при написании пользовательской истории для искусственного интеллекта обязательно скажите «создайте как минимум два критерия приемки в формате «Дано/Когда/Тогда» для каждой истории». Когда модель вынуждена выдавать контрольные показатели, становятся видимыми скрытые пробелы в требованиях.
Шаг за шагом: извлечение требований с помощью ИИ
Шаг 1 — Соберите необработанные данные. Журналы вызовов, электронные письма, существующие снимки экрана, списки жалоб. Чем больше реального вклада, тем меньше выдумок.
Шаг 2 — Извлеките первый набор историй. Предоставьте необработанные данные искусственному интеллекту и заставьте его создавать проекты пользовательских историй. Этот шаг — не полный список, а первый шаг.
Шаг 3 — Добавьте критерии приемки. Создайте критерии «Дано/Когда/Тогда» для каждой истории. История, для которой не могут быть выработаны критерии, на самом деле означает, что она недостаточно определена.
Шаг 4 — Поиск противоречий и пробелов. Спросите ИИ: «Есть ли между этими требованиями какие-либо противоречия, дублирования или неопределённые ситуации?» Спросите и проверьте. Отфильтруйте результат как человек.
Шаг 5 — Расставьте приоритеты и подтвердите. Расставьте приоритеты историй с заинтересованными сторонами, исходя из ценности бизнеса и срочности. Приоритетное решение принадлежит бизнес-подразделению, а не ИИ.
Не забывайте о нефункциональных требованиях
Большинство проектов испытывают трудности в полевых условиях, поскольку при написании функциональных требований забывают о нефункциональных. Отчет может работать «правильно», но если его открытие занимает 45 секунд, им никто не воспользуется. В следующей таблице показаны часто упускаемые из виду типы нефункциональных требований и измеримые примеры написания.
Жанр
плохое выражение
измеримое выражение
Производительность
«Должно быть быстро»
«Ответ на запрос < 2 секунд при средней нагрузке»
доступность
«Каждый должен иметь возможность использовать это»
«Совместимость WCAG 2.1 AA; полная навигация с помощью клавиатуры»
Безопасность
«Это должно быть безопасно»
«Персональные данные при хранении шифруются; доступ осуществляется на основе ролей»
доступность
«Должно быть легко»
«Новый пользователь оформляет заказ в 3 шага без обучения»
Доступность/непрерывность
«Не должно разбиться»
«Ежемесячное время безотказной работы ≥ 99,5%»
Три мини-кейса: в цифрах
Случай 1 — Цена неизмеримой потребности. Экран, который был разработан в банке с требованием, чтобы «экран отчета открывался быстро», при загрузке поля открывался за 22 секунды. Разработчик думал, что в своем окружении использует слово «быстро» (2 секунды). Если бы требование было записано как «< 3 секунд в час пик, фактическая пропускная способность», проблема была бы обнаружена при тестировании. Перепланировка стоила 3 недели и измеримые дополнительные расходы.
Случай 2. Пробелы, выявленные критериями приемки. При написании критериев приемки для истории «система применяет скидку» в проекте электронной коммерции заинтересованная сторона заметила, что то, что произойдет, если скидка будет противоречить купону и VIP-скидке, вообще не обсуждается. Единственный вопрос «Дано/Когда/Тогда» предотвратил двойную ошибку скидки перед запуском; Эта ошибка привела к серьезной потере доходов в аналогичных проектах.
Случай 3 — правило, созданное ИИ. В проекте по управлению персоналом компания AI добавила в проект требований предложение «запрос на отпуск автоматически утверждается в течение 24 часов». На встрече не обсуждалось такое автоматическое одобрение; В модели было сформулировано правило, которое казалось «разумным». Напротив каждого требования эксперт пишет «источник: какое интервью/документ?» Добавив столбец, он удалил 4 предложения без источника.
Слабая подсказка/Сильная подсказка
Слабая подсказка:
Напишите пользовательские истории для этого проекта.
Мощная подсказка:
Ваша роль: вы — бизнес-аналитик MIS. Извлеките пользовательские истории из примечания к собеседованию ниже. Правила: — Формат: «В качестве [роли] для [цели] я хочу [функцию]». — Напишите МИНИМУМ 2 критерия приемлемости для каждой истории в формате «Дано/Когда/Тогда». — Добавьте столбец «Источник» рядом с каждой историей: из какого предложения она взята? — Пометьте [НЕОПРЕДЕЛЕННО] любое правило, которое неясно в примечании; примерка.- Напишите измеримые нефункциональные требования (производительность, безопасность, доступность) в отдельный раздел. Примечание к интервью:[текст]
Мощные подсказки одновременно обеспечивают формат истории, критерии приемки, отслеживаемость источника и нефункциональные требования; Это облегчает контроль вывода.
Четыре копируемых шаблона
1) Уточнение требований:
Ознакомьтесь с требованием ниже. Отметьте каждое утверждение, которое является расплывчатым, несопоставимым или открытым для более чем одной интерпретации, и напишите уточняющий вопрос для каждого. Не придумывайте ответ. Требование: [текст]
2) Сканирование противоречий:
В списке требований ниже найдите пункты, которые противоречат друг другу, повторяются или оставляют логические пробелы. Сообщите о каждом выводе, указав номера пунктов и обоснование в одно предложение. Список: [текст]
3) Генерация критериев приемки:
Напишите как минимум 4 критерия приемлемости для следующей пользовательской истории в формате «Дано/Когда/Тогда», включая предельные и исключительные случаи. Также перечислите все моменты, которые остались неясными. История: [текст]
4) Краткое описание объема:
Составьте элементы «В рамках» и «Вне объема» в виде таблицы из двух столбцов в соответствии со следующими требованиями. Пометьте [ТРЕБУЕТСЯ ПОДТВЕРЖДЕНИЕ] для любого элемента, в котором вы не уверены. Требования: [текст]
Распространенные ошибки
- Думать о решении – это необходимость. «Добавить раскрывающееся меню» — это решение, а не требование. Требование гласит: «Пользователь должен иметь возможность выбрать страну из определенного списка»; ИТ-команда разрабатывает решение.
- Пропуск нефункциональных. Просто записать «что делать» и забыть «как быть» (скорость, безопасность, доступность) — самая распространенная и самая дорогая лазейка.
- Использование неизмеримых прилагательных. Такие слова, как «быстро, просто, безопасно, удобно для пользователя», недействительны без порогового значения.
- Не замечая правила, которое придумал ИИ. В модель могут быть добавлены «разумные», но не фактически произнесенные правила; Просите ресурсы для любых нужд.
- Оставляя приоритет ИИ. Что делать в первую очередь, так это решение о ценности бизнеса; Это дает бизнес-подразделение.
Внимание: самое опасное предложение в анализе требований — «все это уже знают». Невысказанные предположения не попадают в документацию, никогда не попадают в код и не проявляются в реальных условиях. Спросите ИИ: «Что предполагается, но не написано в этом требовании?» делает эти скрытые предположения видимыми.
В итоге
Анализ требований четко, измеримо и отслеживаемо определяет, что должна делать система. Функциональные требования описывают работу, нефункциональные требования описывают качества, а о последних часто забывают. Пользовательская история и критерии приемки «Дано/Когда/Тогда» — мощные инструменты, устраняющие неопределенность. Искусственный интеллект значительно ускоряет создание раскадровок, критериев приемки, обнаружение конфликтов и уточняющих вопросов; Однако правильность бизнес-правила, объем и приоритетное решение, а также источник каждого предложения являются ответственностью человека. Не завершайте формулировку каких-либо требований, которые не имеют источника и неизмеримы.
Задача приложения
Напишите бизнес-запрос из одного абзаца для воображаемой «системы онлайн-записей» (например, «Клиенты должны иметь возможность назначать встречи онлайн, сотрудники должны иметь возможность видеть календари»). (1) Создайте как минимум 5 пользовательских историй и 2 критерия приемлемости для каждой с убедительной подсказкой из этого запроса. (2) Найдите как минимум два скрытых пробела в критериях, созданных моделью (например, двойная встреча одновременно, правило отмены). (3) Включите как минимум 3 нефункциональных требования в измеримой форме. (4) Определите как минимум 3 пункта как «выходящие за рамки». (5) Отметьте правило, которое могла придумать модель, и напишите, как вы его подтвердите.
контрольный список
- [ ] Функциональные и нефункциональные требования я написал отдельно.
- [ ] Каждое требование ясно, измеримо и тестируемо.
- [ ] Каждая история имеет критерии приемлемости «Дано/Когда/Тогда».
- [ ] Я могу отследить источник (разговор/документ) каждого требования.
- [ ] Я отметил возможные правила, которые придумал ИИ, и оставил их для подтверждения.
- [ ] Я расставил приоритеты вместе с бизнес-подразделением.