единица 2 / 12

Анализ на изискванията и проектиране на софтуер

Печалби:

  • Възможност за трансформиране на неясни бизнес заявки в ясни, тествани софтуерни изисквания и потребителски истории с поддръжка на AI
  • Възможност за сравняване на плюсовете и минусите на системния дизайн, модела на данните и архитектурните решения по структуриран начин с AI
  • Способност за критично валидиране на предложения дизайн на AI спрямо изисквания, мащабируемост и ограничения

По-голямата част от софтуерните проекти се провалят не поради лош код, а поради неразбрани изисквания. Заявка от едно изречение като „Позволете на потребителите да изтеглят отчети“ оставя след себе си десетки въпроси без отговор: В какъв формат? Кой отговаря? Колко записа? Ами ако е бавно? Анализът на изискванията (превеждане на бизнес заявка в ясни, тествани технически нужди) и дизайнът на софтуера (конструиране на структурата на хартия, за да отговори на тези нужди) е етапът, на който най-скъпите грешки се предотвратяват преди писането на код. В този урок ще се научим да използваме AI като „партньор на мисълта“ на този етап: партньор, който демистифицира несигурността, подрежда опциите, но оставя окончателното решение на вас.

AI произвежда две големи стойности тук. Първо, той задава въпроси, които пропускате; Той извежда на повърхността скрити предположения и крайни случаи в дадена заявка. Второ, той бързо представя плюсовете и минусите на дизайнерско решение. Но това е опасността: AI ще даде общи препоръки като „най-добра практика“, без да познава напълно вашия контекст (бюджет, екип, съществуваща система, правно ограничение). Ваша работа е да филтрирате този съвет срещу собствената си истина.

Концепции: Потребителска история: Кратко изречение, изразяващо нужда под формата на „... тъй като, искам да мога да... защото...“. Критерии за приемане: Тестваеми условия, които трябва да бъдат изпълнени, за да се счита дадена работа за „свършена“. Нефункционално изискване: Изисквания, свързани с „как ще се държи“, а не с „какво ще прави“, като скорост, сигурност, мащабируемост.

От неясно искане до подлежащо на проверка изискване

Доброто изискване е измеримо и проверимо. Не „нека системата да бъде бърза“, а „нека резултатите от търсенето се връщат в рамките на 500 ms“. Ето един стъпка по стъпка начин да използвате AI за стесняване на несигурността:

  1. Дайте заявката такава, каквато е, и генерирайте въпроса. Попитайте изкуствения интелект не за решението, а първо да „изброите всичко неясно в тази заявка като въпрос“.
  2. Вие давате отговорите. Само вие знаете контекста; Отговорете на въпросите на AI с вашите реални бизнес ограничения.
  3. Преведете го в потребителски истории и критерии за приемане. Преведете изяснената нужда в тествани елементи.
  4. Добавете крайни случаи и негативни сценарии. „Празен резултат“, „неоторизиран потребител“, „твърде голям файл“ и др.

Подкана за извличане на неясноти: „Ще преведем следната бизнес заявка в софтуерно изискване. Все още не предлагайте решение. Първо извлечете ВСИЧКИ неясноти и скрити предположения, на които не е отговорено в тази заявка, като списък с въпроси. Групирайте въпросите под следните заглавия: обхват, потребител/правомощия, обем на данните, производителност, условия за грешки, сигурност. Заявка: „Позволете на потребителите да изтеглят хронологията на поръчките като отчет.““

Потребителска история + подкана за критерии за приемане: „Разделете следната изяснена нужда на потребителски истории, които отговарят на принципите на INVEST. Напишете 3-5 тествани критерии за приемане за всяка история (във формат Дадено-кога-тогава). Добавете поне 2 отрицателни сценария (неоторизиран достъп, празни данни). Нужда: [напишете изяснена нужда тук]“

Сравняване на дизайнерски решения с AI

Дизайнът е постоянен компромис: скорост срещу гъвкавост, простота срещу мащабируемост? AI поставя тези компромиси в бърза електронна таблица. Например, за функцията „изпращане на известие“ можете да обсъдите дали да използвате синхронен (изпращане при поискване) или асинхронен (опашка, изпращане във фонов режим) подход.

Подкана за сравнение на дизайна: „Проектирам функция за „изпращане на имейл известие до потребителя“. Сравнете двата подхода: (A) синхронна доставка по време на HTTP заявката, (B) асинхронна доставка във фонов режим, като я поставите в опашката за съобщения. Направете таблица по следните оси: време на изчакване на потребителя, толерантност към грешки, сложност, цена на инфраструктурата, трудности при отстраняване на грешки. Обобщете в 2 изречения кое бих направил избери в крайна сметка в кой случай не вземай решение вместо мен."

ос

синхронно предаване

Асинхронен (опашка)

Време за изчакване на потребителя

Дълго (чакане на пратка)

Кратко (връща се веднага)

Толерантност към грешки

Ниско (заявката експлодира, ако се изпрати)

Високо (възможен е повторен опит)

сложност

ниско

Средно-висока (инфраструктура на опашка)

Разходи за инфраструктура

ниско

Необходими са допълнителни компоненти

Където пасва

Нисък обем, лесно приложение

Голям обем, критична доставка

Съвет: Казването на AI „не вземай решение вместо мен, просто ми покажи опциите и условията“ ви принуждава да мислите и намалява риска от сляпо приемане на предложение. Най-доброто дизайнерско решение е това, взето от човека, който познава вашия контекст (вие).

Слаба подкана / Силна подкана

СЛАБО: „Проектиране на база данни за системата за поръчки.“ (Резултат: кой мащаб, кои връзки, кои ограничения не са ясни; обща, нереалистична схема.) СИЛНО: „Предложете проект на модел на данни за малка електронна търговия. Обекти: клиент, поръчка, продукт, артикул от поръчка. Ограничения: може да има много продукти в една поръчка; цената на продукта може да се промени с времето, но текущата цена трябва да се запази в предишната поръчка; очакват се ~500 поръчки на ден. Връзки и защо това „Обяснете, че сте взели решението. Посочете как сте решили проблема с историята на цените. Дайте го като списък от обекти и полета, а не код."

Разликата на мощната подкана; мащаб (500 поръчки на ден), бизнес правило (минала цена трябва да се поддържа) и желания изходен формат. Едно-единствено изречение като „Миналата цена трябва да се поддържа“ напълно променя дизайна; Ако не посочите това, AI ще създаде неточна, но правдоподобна диаграма.

Мини калъфи

Случай 1 — Скрито предположение. Екип директно кодира заявката „потребителят може да качва профилна снимка“. Друг екип попита AI относно несигурността: "максимален размер? разрешени формати? неподходящ контрол на съдържанието? изтриване на стара снимка?" Той произвежда 8 въпроса като. Първият екип научава за проблема в производството, когато 20 MB файлове запълнят сървъра; Вторият екип го решава проектно.

Случай 2 — Неправилно предположение за мащаба. AI предлага сложен кеширащ слой за функция за отчитане. Когато инженерът посочва, че реалните данни са само 30 отчета на ден, AI опростява предложението. Неуточняването на мащаба води до разходите за ненужна сложност; уточняването спестява 2 седмици ненужна работа.

Случай 3 — Пропуск в критериите за приемане. „Какво ще стане, ако плащането е неуспешно?“ Тъй като въпросът никога не е бил задаван, системата за поръчки все пак ще маркира поръчката като „потвърдена“ в случай на неуспешно плащане. Списъкът с негативни сценарии, генерирани от AI, улавя тази празнина; Критериите за приемане на 1 ред предотвратяват реални загуби на пари.

Често срещани грешки

  • Предаване на заявката директно към кода. Кодът, написан преди неяснотата да бъде разрешена, бързо решава грешния проблем.
  • Сляпо приемане на общата „най-добра практика“ на AI. Ако не посочите своя контекст (мащаб, бюджет, екип), препоръката няма да работи за вас.
  • Пропускане на нефункционални изисквания. Ако скоростта, сигурността и мащабът не са посочени, дизайнът ще бъде непълен.
  • Само като си помисля за щастливия сценарий. Негативните сценарии като празни данни, неоторизиран потребител, състояние на грешка трябва да бъдат включени в дизайна.
  • Делегиране на решението на AI. AI генерира опции; Вие решавате кой компромис е подходящ за вашия бизнес.

В обобщение

Анализът на изискванията и проектирането е етапът, на който се улавят най-евтините грешки. Тук AI генерира въпроси, които разкриват несигурност, чертае потребителски истории и критерии за приемане и компромиси в дизайна на графики. Но само вие знаете контекста; Ваша работа е да филтрирате препоръките на AI въз основа на вашия мащаб, бюджет, екип и законови ограничения и да вземете окончателното решение. Дисциплината „не вземайте решение вместо мен, покажете ми опциите“ води както до по-добър дизайн, така и до по-задълбочено обучение.

Задача за приложение

Изберете молба за работа от едно изречение от вашия контекст. Първо, приложете подканата за неяснота към AI и отговорете на въпросите с реалните си ограничения. След това преведете изяснената нужда в поне 2 потребителски истории и 3 критерия за приемане за всяка; Включете поне 1 негативен сценарий. И накрая, създайте сравнителна таблица за дизайнерско решение (синхронно/асинхронно, структура на таблица и т.н.) и напишете собственото си решение в 2 изречения.

контролен списък

  • [ ] Премахнах неяснотите като въпроси, преди да предам заявката в кода.
  • [ ] Дадох контекста (мащаб, авторитет, производителност, правно ограничение) на AI.
  • [ ] Разделих потребителските истории на тествани критерии за приемане.
  • [ ] Добавих поне един сценарий за недостатък/ръб.
  • [ ] Оцених дизайнерското решение с таблицата за компромиси.
  • [ ] Взех окончателното решение въз основа на моя контекст, не го оставих на AI.