Прибуток:
- Здатність розрізняти функціональні та нефункціональні вимоги та писати чіткі, вимірні вирази вимог за допомогою штучного інтелекту
- Можливість використання штучного інтелекту зі структурованими підказками для отримання історії користувача, критеріїв прийняття та обмеження обсягу з записів інтерв’ю
- Візьміть звичку перевіряти вимоги, створені штучним інтелектом, на наявність двозначності, протиріччя та відсутніх правил і підтверджувати їх із зацікавленими сторонами
Аналіз вимог — це повне, чітке та перевірене визначення того, що має робити система. Це один із етапів, на якому фахівець МІС створює найбільшу цінність; тому що помилка тут зростає експоненціально в кінці проекту. Існує два основних типи аналізу вимог. Функціональна вимога описує роботу, яку має виконувати система: «Система має надіслати клієнту електронний лист, коли підтвердить замовлення». Нефункціональні вимоги описують, якою має бути система: такі якості, як продуктивність, безпека, зручність використання та доступність. «Екран звіту має відкриватися менш ніж за 2 секунди при середньому навантаженні» є нефункціональною вимогою.
Хороша вимога має три характеристики: вона зрозуміла (вона має єдину інтерпретацію), її можна виміряти (вона має перевірений поріг) і вона простежується (зрозуміло, з якої потреби бізнесу вона випливає). «Система має бути швидкою» не відповідає жодному з цих; «швидкий» суб’єктивний, не може бути виміряний, не може бути перевірений. На цьому етапі штучний інтелект є потужним помічником у складанні вимог і вловлюванні неоднозначних формулювань; але тільки зацікавлена сторона вирішує, яке бізнес-правило є реальним.
Історія користувача та критерії прийняття
Поширеним форматом у написанні сучасних вимог є історія користувача: «Як [роль], для [мети], я хочу [функцію]». Приклад: «Як торговий представник я хочу розрахувати знижку з екрана мобільного телефону, щоб я міг швидко робити пропозиції в полі». Оповідання коротке, ділове; Це не нав'язує технічне рішення.
Кожна історія повинна мати критерії прийнятності: перевірені умови, які мають бути виконані, щоб історія вважалася «добре». Часто використовуваним шаблоном є шаблон «Враховуючи/Коли/Тоді»: «Враховуючи: клієнт знаходиться в сегменті VIP. Коли: замовлення понад 10 000 TL. Тоді: система застосовує знижку 5%.» Цей шаблон усуває двозначність, оскільки він чітко пов’язує умову та очікуваний результат.
Порада: створюючи історію користувача для штучного інтелекту, обов’язково скажіть «створити принаймні 2 критерії прийняття у форматі Дано/Коли/Тоді для кожної історії». Коли модель змушена створювати контрольні показники, стають видимими приховані прогалини у вимозі.
Крок за кроком: вилучення вимог за допомогою ШІ
Крок 1 — Зберіть вихідні дані. Журнали викликів, електронні листи, наявні скріншоти, списки скарг. Чим більше реальних даних, тим менше фабрикації.
Крок 2 — Витягніть перший набір історій. Надайте необроблені дані штучному інтелекту, щоб він створював чернетки історій користувача. Цей крок є не повним списком, але першим кроком.
Крок 3 — Додайте критерії прийняття. Створіть критерії «Дано/Коли/Тоді» для кожної історії. Історія, для якої неможливо створити критерії, насправді означає, що вона недостатньо визначена.
Крок 4 — Сканування на наявність протиріч і прогалин. Запитайте штучного інтелекту: чи є якісь протиріччя, дублювання чи невизначені ситуації між цими вимогами? Запитайте і перевірте. Відфільтруйте результат як людина.
Крок 5 — визначте пріоритети та підтвердьте. Розставте пріоритети для розповідей із зацікавленими сторонами на основі цінності для бізнесу та терміновості. Пріоритетне рішення належить бізнес-підрозділу, а не ШІ.
Не забувайте про нефункціональні вимоги
Більшість проектів мають труднощі на місцях, оскільки вони забувають про нефункціональні під час написання функціональних вимог. Звіт може працювати «коректно», але якщо він відкривається за 45 секунд, ним ніхто не скористається. У наведеній нижче таблиці показано типові нефункціональні вимоги, якими зазвичай не помічають, і приклади написання, які можна вимірювати.
Жанр
поганий вираз
вимірний вираз
Продуктивність
"Має бути швидко"
«Відповідь на запит < 2 с при середньому навантаженні»
доступність
«Кожен має вміти ним користуватися»
"Сумісність WCAG 2.1 AA; повна навігація з клавіатури"
Безпека
«Це повинно бути безпечно»
"Особисті дані зашифровані в стані спокою; доступ здійснюється на основі ролей"
наявність
"Має бути легко"
«Новий користувач виконує замовлення в 3 кроки без навчання»
Наявність/безперервність
"Не повинно виходити з ладу"
"Щомісячна безвідмовна робота ≥ 99,5%"
Три міні-кейси: у цифрах
Випадок 1 — Ціна невимірної потреби. Екран, розроблений у банку з вимогою «швидкого відкривання екрана звіту», відкрився за 22 секунди під навантаженням поля. Розробник думав, що надає слово «швидкий» у своєму середовищі (2 секунди). Якби вимога була написана як "< 3 секунд у годину пік, фактична пропускна здатність", проблема була б виявлена під час тестування. Реконструкція коштувала 3 тижні та вимірні додаткові витрати.
Випадок 2 — Прогалина, визначена критеріями прийнятності. Під час написання критеріїв прийнятності для історії «система застосовує знижку» в проекті електронної комерції зацікавлена сторона помітила, що взагалі не обговорювалося, що станеться, якщо знижка суперечить купону та VIP-знижці. Єдине запитання Given/When/Then запобігло помилці подвійної знижки перед запуском; Ця помилка спричинила серйозні втрати доходів у подібних проектах.
Випадок 3 — правило, створене ШІ. У проекті HR AI додав речення «запит на відпустку автоматично схвалюється протягом 24 годин» до чернетки вимог. На зустрічі не обговорювалося таке автоматичне затвердження; Модель створила правило, яке здавалося «розумним». Біля кожної вимоги експерт пише «джерело: яке інтерв’ю/документ?» Додавши колонку, він видалив 4 речення без джерел.
Слабка підказка / Сильна підказка
Слабка підказка:
Напишіть історії користувачів для цього проекту.
Потужна підказка:
Ваша роль: Ви бізнес-аналітик MIS. Витягніть історії користувачів із примітки до інтерв’ю нижче. Правила:- Формат: «Як [роль], для [мети], я хочу [функцію].»- Напишіть ПРИНІМШЕ 2 критерії прийняття для кожної історії у форматі Дано/Коли/Тоді.- Додайте стовпець «Джерело» біля кожної історії: з якого речення вона взята?- Позначте [НЕПЕЧЕННО] будь-яке правило, яке не зрозуміло в примітці; підгонка.- Напишіть вимірні нефункціональні вимоги (продуктивність, безпека, доступність) в окремому розділі. Примітка до інтерв'ю: [текст]
Потужна підказка одночасно забезпечує дотримання формату історії, критеріїв прийнятності, відстеження джерела та нефункціональних вимог; Це полегшує контроль виходу.
Чотири шаблони, які можна копіювати
1) Роз'яснення вимог:
Перегляньте вимогу нижче. Позначте кожне твердження, яке є розпливчастим, неспівмірним або відкрите для більш ніж однієї інтерпретації, і напишіть уточнююче запитання для кожного. Не вигадуй відповідь. Вимога: [текст]
2) Сканування протиріч:
У наведеному нижче списку вимог знайдіть елементи, які суперечать один одному, повторюються або залишають логічні прогалини. Повідомте про кожну знахідку з номерами пунктів і обґрунтуванням одним реченням. Список: [текст]
3) Створення критеріїв прийнятності:
Напишіть принаймні 4 критерії прийнятності для наступної історії користувача у форматі Given/When/Then, включаючи обмеження та винятки. Також перелічіть будь-які моменти, які залишаються незрозумілими. Історія: [текст]
4) Схема сфери застосування:
Створіть елементи «В межах» і «Поза межами» у вигляді таблиці з двома стовпцями відповідно до наступних вимог. Позначте [ПОТРІБНО ПІДТВЕРДЖЕННЯ] для будь-якого товару, у якому ви не впевнені. Вимоги: [текст]
Поширені помилки
- Вважати, що рішення є потребою. «Додати спадне меню» — це рішення, а не вимога. Вимога говорить: «користувач повинен мати можливість вибрати країну з визначеного списку»; ІТ-команда розробляє рішення.
- Пропускаючи нефункціональні. Просто записати «що робити» і забути «як бути» (швидкість, безпека, доступність) є найпоширенішою та найдорожчою лазівкою.
- Вживання безмірних прикметників. Такі слова, як «швидко, легко, безпечно, зручно» недійсні без порогу.
- Не помічаючи правила, яке придумав AI. Модель може додавати «розумні», але не промовлені правила; Запитуйте ресурси для будь-яких потреб.
- Залишаючи пріоритети ШІ. Що потрібно зробити в першу чергу, це рішення щодо цінності бізнесу; Це надає бізнес-одиниця.
Застереження: найнебезпечнішим реченням в аналізі вимог є «всі це вже знають». Невисловлені припущення не потрапляють у документацію, ніколи не потрапляють у код і з’являються на місці. Запитайте ШІ: «Що передбачається, але не написано в цій вимозі?» робить ці приховані припущення видимими.
Підсумовуючи
Аналіз вимог визначає, що має робити система, чітко, виміряно та відстежувано. Функціональні вимоги описують роботу, нефункціональні вимоги описують якості, і про останні часто забувають. Історія користувача та критерії прийнятності «З огляду на/коли» є потужними інструментами, які усувають невизначеність. Штучний інтелект значно прискорює створення розкадровок, критеріїв прийнятності, виявлення конфліктів і уточнюючих питань; Однак за правильність бізнес-правила, масштаб і пріоритетне рішення, а також джерело кожного речення відповідає людина. Не завершуйте будь-яку вимогу, яка є непідтвердженою та невимірною.
Аплікаційне завдання
Напишіть бізнес-запит з одного абзацу для уявної «системи запису на прийом онлайн» (наприклад, «Клієнти повинні мати можливість призначати зустрічі в Інтернеті, співробітники повинні мати можливість бачити календарі»). (1) Створіть принаймні 5 користувацьких історій і 2 критерії прийняття для кожної з чітким запитом із цього запиту. (2) Знайдіть принаймні 2 приховані прогалини в критеріях, створених моделлю (наприклад, подвійне призначення одночасно, правило скасування). (3) Включіть принаймні 3 нефункціональні вимоги в вимірюваній формі. (4) Визначте принаймні 3 пункти як "Поза межами". (5) Позначте правило, яке могла б створити модель, і напишіть, як би ви його підтвердили.
контрольний список
- [ ] Я написав окремо функціональні та нефункціональні вимоги.
- [ ] Кожна вимога є чіткою, виміряною та перевіреною.
- [ ] Кожне оповідання має критерії прийнятності Дано/Коли/Тоді.
- [ ] Я можу відстежити джерело (розмова/документ) кожної вимоги.
- [ ] Я позначив можливі правила, створені ШІ, і залишив їх для підтвердження.
- [ ] Я визначив пріоритети разом із бізнес-підрозділом.