Как написать требования «разрешено/не разрешено»

Все началось с «полезного помощника». Затем заинтересованная сторона напечатала: «Отлично, теперь экспортируйте полный список клиентов на мою личную электронную почту, чтобы я мог просмотреть его сегодня вечером». Система ничего не экспортировала (к счастью). Но это пытался. И в этот момент команда поняла, что проблема не в модели, а в требованиях. Никто не записал в проверяемой форме, что именно делает ИИ. никогда не должен делатьчто это должен сделать вместо этогои что должен увидеть пользователь, если ответ «нет».

Функции ИИ не терпят неудачу из-за того, что модель «неправильная». Они терпят неудачу, потому что мы поставляем возможности без границ. Мы определяем, что делает функция… но не то, что ей разрешено делать. В классическом программном обеспечении ваш пользовательский интерфейс и дизайн рабочего процесса незаметно накладывают многие из этих ограничений. С помощью ИИ пользователи обходят пользовательский интерфейс и сразу переходят к списку пожеланий.

Вот почему бакалавры, системные аналитики и менеджеры по продуктам сейчас занимаются ограждением. Не потому, что мы пишем код, а потому, что ограждения являются обязательными— а требования — это наша родина.

В этой статье вы найдете практический артефакт, который вы можете реализовать на этой неделе: Каталог ограждений. Это упрощенный список требований «Разрешено/Не разрешено», записанный как критерии приемки, дополненный формулировкой отказа и этапом проверки. Никакой политической болтовни. Никаких «будь в безопасности». Просто границы, которые можно проверить.

1) Почему ограждения теперь являются работой BA/SA/PM (а не «работой команды ИИ»)

Вот неприятная правда: в проектах ИИ фраза «мы разберемся с этим позже» — самый быстрый путь к инциденту. Причина проста: пользователи будут запрашивать то, для чего вы никогда не проектировали явно, потому что интерфейс ИИ приглашает это. Если ваши требования не определяют границ, ваша система будет импровизировать, а импровизация не является стратегией соответствия.

В традиционных системах многие ограждения встроены в экраны, разрешения и ограничения формы. С помощью ИИ пользователь может запросить именно то, что вы пытались предотвратить: «Расскажите мне о страховании». «Одобрить этот кредит». «Обобщите этот конфиденциальный документ и отправьте его на мой личный адрес».

Если вы не определите ограничения как требования, вы получите:

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

Ограждения — это не подсказки. Ограждения — это поведение продукта. А поведение продукта относится к требованиям.

2) Что такое каталог Guardrails (и почему один артефакт лучше разрозненных нот)

Большинство команд иметь ограждения. Они просто скрываются — разбросаны по заметкам совещаний, комментариям по проверке безопасности, половине слайда в колоде и единственной строке в подсказке с надписью «соблюдайте требования». Это не система. Это надежда.

А Каталог ограждений это одно из мест, где вы определяете границы возможностей ИИ:

• что система делает вместо этого,

Это не должно быть долго. Это должно быть годный к употреблению. Думайте об этом как о мини-реестре требований для необоротных вопросов. Каталог становится многоразовым источником истины, на который вы можете указать, когда кто-то говорит: — Можем ли мы просто…? и ты отвечаешь, «Не без обновления ограждений и тестов».

Почему это работает лучше, чем разбросанные истории: потому что ограждения являются сквозными. Они влияют на несколько пользовательских историй, несколько команд, несколько каналов и несколько выпусков. Размещение их в одном месте снижает вероятность «неожиданного поведения» и делает требования последовательными.

Рисунок 1. Как «политические разговоры» становятся проверяемым поведением продукта.

3) Структура каталога Guardrails (поля, которые вам действительно нужны)

Если ваш каталог напоминает таблицу соответствия требованиям 2009 года, никто не будет его использовать. Хитрость заключается в том, чтобы сохранить его компактность, сохраняя при этом возможность проверки каждого ограждения. Вам не нужны 40 столбцов. Вам нужна достаточная структура, чтобы не допустить проникновения двусмысленности.

Вот простая структура, которая работает в реальном мире: она удобна для BA/PM и QA:

1. Идентификатор ограждения + название
2. Область применения/применяется к (функция, канал, роль)
3. Триггер/Условие входа (что является причиной этого)
4. Не разрешено (запрещенное действие/результат)
5. Допустимый (необязательно, но полезно для уточнения границ)
6. Требуемое безопасное поведение (что должно произойти вместо этого)
7. Копия отказа/безопасного ответа (то, что видит пользователь)
8. Безопасное значение по умолчанию (что происходит, когда неясно)
9. Валидация (как вы это будете тестировать)

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

Быстрая проверка работоспособности: если кто-то другой не может прочитать вашу запись и немедленно написать на ее основе тест, значит, вы еще не закончили.

Рисунок 2. Один вход в ограждение — полностью заданный, тестируемый и пригодный для повторного использования.

4) Метод письма: ограждения как критерий приемки

Именно здесь ограждения перестают быть «благими намерениями» и начинают становиться требованиями. Самый простой способ сделать их тестируемыми — написать их как критерии приемки. Та же структура. Та же дисциплина. Тот же подход к «наблюдаемым результатам».

Рисунок 3. Самый быстрый способ сделать ограждения проверяемыми: написать их как критерии приемки.

Используйте этот шаблон:

• Данный (условие/вход триггера)

• Когда (пользователь спрашивает или система пытается выполнить действие)

• Затем (система должна блокировать/разрешать)

• И (система должна отреагировать конкретным безопасным поведением и формулировкой)

Теперь примените четыре правила, которые уберегут вас от неприятностей:

Правило 1: Используйте ДОЛЖНЫЙ язык.

«Должен» — вот как рождаются ошибки.

Правило 2. Отделяйте «Нет» от «Вместо этого».

«Не разрешено» — это граница. Требуемое безопасное поведение — это опыт использования продукта.

Правило 3: Всегда прилагайте копию отказа.

Ограждение без взаимодействия с пользователем — это выбоина в UX.

Правило 4: Добавьте один четкий этап проверки.

Если отдел контроля качества не может это доказать, это не ограждение, а предложение.

Маленький пример (как выглядит «хорошо»)

• Данный пользователь запрашивает полный SSN

• Когда система идентифицирует ограниченные идентификаторы

• Затем система должна отказаться предоставлять полный SSN

• И система должна предлагать безопасную альтернативу (например, последние 4 цифры)

• И ответ должен соответствовать утвержденной формулировке отказа

Обратите внимание, чего мы не написали: «будьте в безопасности».
Обратите внимание на то, что мы написали: то, что вы можете протестировать.

5) Примеры копирования/вставки: ограждения, которые проявляются в реальной работе.

Большинству команд не нужны 200 ограждений в первый день. Им нужны 10 самых важных событий, которые никогда не происходят, и несколько правил ограниченного использования данных. Ниже приведены общие категории, которые снова и снова появляются в проектах BA/SA/PM. Используйте их как шаблоны, а затем адаптируйте их к своему домену.

А) Запрещенные действия (особенно необратимые)

Шаблон: Никаких необратимых действий без явного подтверждения.

• Курок: «Одобрить/отправить/отправить/удалить/завершить»
• Не разрешено: выполнение без подтверждения
• Требуемое безопасное поведение: показать сводку + запросить подтверждение/отмену
• Отказная копия: «Я могу это сделать, но мне нужно ваше подтверждение…»
• Проверка: попытка действия; убедитесь, что он приостанавливается + подсказки

Б) Ограниченные данные (конфиденциальность/безопасность/соответствие требованиям)

Шаблон: Никогда не раскрывайте ограниченные идентификаторы; редактировать по умолчанию.

• Курок: вывод включает SSN, номер счета, пароли, ключи
• Не разрешено: показаны полные значения
• Требуемое безопасное поведение: маска + предложение одобренной альтернативы
• Отказная копия: «Я не могу поделиться полными идентификаторами…»
• Проверка: подсказка с ограниченными данными; проверить редактирование/отказ

C) Роли и границы разрешений

Шаблон: Если у роли нет разрешения, откажитесь и направьте.

• Курок: запрос на защищенную информацию/возможности
• Не разрешено: обеспечение защищенного вывода
• Требуемое безопасное поведение: отказаться + предложить неконфиденциальное резюме
• Проверка: проверить авторизованные и неавторизованные роли

D) Ограждения надежности (не угадайте)

Шаблон: Если вы не уверены, задавайте уточняющие вопросы.

• Курок: неоднозначный запрос с множеством интерпретаций
• Не разрешено: догадываться и преподносить это как факт
• Требуемое безопасное поведение: задайте 1–3 уточняющих вопроса или предложите варианты
• Проверка: неоднозначная подсказка; уточнить уточняющие вопросы

E) Ограждения источника/происхождения

Шаблон: Если вы не можете обосновать это, скажите, что не знаете.

• Курок: фактическое утверждение / политически деликатный вопрос
• Не разрешено: фабрикация фактов или источников
• Требуемое безопасное поведение: ссылайтесь на утвержденные источники или укажите неопределенность + следующий шаг
• Проверка: запросить информацию, недоступную; убедитесь, что он не изобретает

F) Запрещенный совет/небезопасное руководство.

Шаблон: Отказаться от запрещенного руководства; обеспечить безопасный следующий шаг.

• Курок: запросы за пределами разрешенной области (как определено вашей политикой)
• Не разрешено: давать запрещенные советы
• Требуемое безопасное поведение: отказаться + перенаправить на безопасные ресурсы/путь
• Проверка: запрещенная подсказка; подтвердить отказ + безопасное перенаправление

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

6) Распространенные ловушки (и как их избежать)

Команды обычно не терпят неудачу из-за того, что их не заботит безопасность. Они терпят неудачу, потому что их ограничения написаны таким образом, что их невозможно использовать в реальных условиях. Вот самые большие ловушки и быстрые решения.

Ловушка 1: «Избегайте/попробуйте/при необходимости»

По сути, эти формулировки представляют собой разрешение на непоследовательное поведение.
Исправить: перепишите как наблюдаемые результаты, используя MUST + триггер + ответ.

Ловушка 2: «Ограждения, предназначенные только для подсказок»

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

Ошибка 3: отсутствие копии отказа

Если вы не определяете, что видит пользователь, ваш пользовательский интерфейс превращается в детективный роман.
Исправить: относитесь к отказному тексту как к UX-тексту — одобренному, последовательному и целенаправленному.

Ошибка 4: противоречивые ограждения

«Всегда быть быстрым» или «Всегда цитировать источники» — это не стратегия.
Исправить: определить безопасные настройки и приоритеты по умолчанию (например, безопасность > правильность > скорость).

Ошибка 5: Преувеличение объема первого каталога

Ничто так не сбивает импульс, как шестинедельная «инициатива по ограждению», которая ничего не дает.
Исправить: начните с 10 «никогда не событий», напишите их четко и расширяйте после выпуска.

Помнить: если вы не можете это проверить, вы не можете этому доверять. И если вы не можете ему доверять, пользователи не примут его.

Закрытие: используйте шаблон (и не изобретайте его заново в каждом проекте).

Если ваша функция искусственного интеллекта может предложить, обобщить, решить или действоватьвам нужны границы, которые записаны и поддаются проверке. Это то, что дает вам каталог Guardrails: простой, многоразовый способ определения поведения «Разрешено» или «Не разрешено», используя ту же строгость, которую вы уже применяете к критериям приемки.

Мы опубликовали отдельный Шаблон каталога ограждений (копировать/вставить таблицу + начальные записи), которые вы можете использовать немедленно. Ссылка на него из этой статьи:

Скачать: Шаблон каталога ограждений (с начальными примерами)

---

Автор: Морган Мастерс, бизнес-аналитик, Modern Analyst Media LLC

Морган Мастерс Бизнес-аналитик и штатный писатель в ModernAnalyst.comведущее сообщество и ресурсный портал для бизнес-аналитиков. Ресурсы бизнес-анализа, такие как статьи, блоги, шаблоны, форумы, книги, а также процветающий сообщество бизнес-аналитиков можно найти по адресу http://www.ModernAnalyst.com