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