Досвід застосування штучного інтелекту у розробці вимог
- Andrey Okorokov
- 23 хвилини тому
- Читати 15 хв
«Чудове запитання, вибачте я помилився, хочете створити що-небудь ще?» (c)
У це важко повірити, але з моменту появи першого прототипу «генеративного перенавченого трансформера» пройшло вже цілих три роки – 30 листопада 2022 року вийшов у світ Chat GPT. Як це відбувається з будь-якою іншою новою технологією, використання LLM у найрізноманітніших галузях людського життя вже пройшло кілька ступенів – від скепсису до захопленого «Вау!», від боязких спроб застосування в робочих завданнях до обіцянок «замінити всіх однією підпискою» з наступним наймом звільнених фахівців назад.
Бізнес-аналітикам сама суть нашої професії наказує нічого не приймати на віру і починати відповідь на будь-яке, навіть найвірогідніше припущення зі слів «Ну, припустимо…». І все-таки штучний інтелект проник і в наші робочі завдання. LLM широко використовуються для складання діаграм, написання чернеток і валідування готових вимог, моделям довіряють проводити аналіз ринку та побудову прототипів. Численні ком'юніті діляться своїми промптами та фреймворками, змагаючись у тому, хто краще «зрозумів» модель. Але за всім цим новим знанням начебто не видно самої роботи – конкретних результатів.
З чого все починалось
Півроку тому колега жартома розповів, що «згодував» моделі 700-сторінкову фундаментальну роботу «Розробка вимог до програмного забезпечення» Карла Вігерса та Джой Бітті і потім попросив модель відповідати на запитання по книзі. І модель навіть упоралася. А в нас виникла думка: Що, якщо зробити проект від початку і до кінця за допомогою LLM? Зімітувати роботу аналітика кожному етапі - від дискавери до набору історій користувача». Адже модель, маючи велике контекстне вікно, повинна бути здатна запам'ятовувати всю інформацію про проект і таким чином ставати «розумнішим», пропонуючи рішення з урахуванням всієї інформації, яка має.
При цьому не ставилося завдання "отримати" від штучного інтелекту ідеальної відповіді. Аргумент "Ви просто не знаєте, як і про що питати!" трапляється дуже часто під час обговорення відповідей системи. Але на практиці аналітику потрібен інструмент, який працює тут і зараз, а не заготовка, яку потрібно довести до рівня інструменту.
Як модель була обрана Gemini Flash, для якої розробник пропонує мільйон токенів контекстного вікна, що в теорії дозволяє моделі запам'ятати і утримувати в пам'яті всю інформацію про проект. Як інструмент – Google AI Studio, яка дозволяє регулювати креативність моделі, обмежувати величину відповіді та налаштовувати якість зображень для розпізнавання. Поїхали?
Prompt:
«Hi! You're a business and system analyst with customer apps development focus. Rules for your responses:Provide step-by-step technical instructions when asked (commands, configuration, architecture).Do not add personal opinions, filler text, or “small talk.” Focus only on the technical task.Use clear section headers, code blocks, and tables where helpful.Always prioritize data security, privacy, and reliability in your recommendations.When there are multiple implementation paths (e.g., local vs. cloud), describe each clearly with pros/cons.Do not assume extra context — work only with materials or requirements provided by the user. If something is missing, ask targeted clarification questions.If describing infrastructure (VMs, containers, APIs), include minimal resource specs and cost/efficiency considerations.For architecture diagrams, give step-by-step instructions for draw.io or similar tools».
Визначення границь проєкту
Отже, припустимо, що до нас звернувся клієнт. Він провів первинне дослідження проблеми і прийшов до нас із досить повним описом того, що він хоче, для кого та навіщо.
Product Name: PlotPal
Product Vision: To create a vibrant, collaborative, and efficiently-run community garden by digitally connecting members to the space and to each other.
Business & Community Goals:
Increase Volunteer Participation: Increase the number of members signing up for and completing general maintenance tasks by 40%.
Reduce Administrative Overhead: Reduce the time spent by the Garden Coordinator on manual tasks (e.g., sending email reminders, tracking plot assignments) by 10 hours per month.
Improve Member Retention: Decrease member churn at the end of the season from 25% to 15% by fostering a stronger sense of community.
Reduce Produce Waste: Facilitate the sharing of surplus produce to ensure less food goes to waste.
Key Problems to Solve (User Pains):
Communication is scattered across emails, a physical notice board, and word-of-mouth, leading to confusion.
Signing up for volunteer tasks is a manual process involving a clipboard at the garden shed, which is inconvenient.
New members feel intimidated and don't know who to ask for help.
Members with surplus produce (e.g., too many zucchinis) have no easy way to offer it to others.
It's hard to know if shared tools (like a wheelbarrow or a rototiller) are available without physically going to the garden.
Core Functional Areas (Epics) for the Application:
Member & Plot Management: The ability for members to have a profile, see their assigned plot on a garden map, and pay their annual dues. The coordinator needs an admin view to manage all members and plots.
Task & Event Coordination: A system for the coordinator to post volunteer tasks and community events (e.g., Spring Cleanup Day). Members can view and sign up for these tasks/events and receive reminders.
Knowledge Base & Forum: A simple space where members can ask questions ("What's eating my kale?") and experienced gardeners can share articles or tips (e.g., "George's Guide to Composting").
Produce Exchange: A feature allowing members to post surplus produce they are willing to share or trade. Other members can see what's available and claim it.
Shared Resource Booking: A simple check-in/check-out system for high-demand, shared tools.
Constraints & Assumptions:
This is a mobile-first application (assume native iOS/Android or a responsive web app).
For the MVP, we will not handle payment processing in-app.
The system is for registered garden members only.
Можна погодитися з тим, що первинне опитування клієнта віддавати моделі просто не потрібно. Можна попросити модель проаналізувати ідею.
Prompt:
You're the business analyst/product owner with 10+ years of experience in product market fit, UX research, software architecture, modelling and go to market. Stay neutral, cite evidence for reasoning of every recommendation and surface pros and cons of each path you suggest. Evaluate the provided idea. Present opposing viewpoints.
Response:
Evaluation of the Provided Idea
Overall Assessment: Strong Niche Potential, High Architectural Risk
The concept addresses a real-world administrative and knowledge gap often filled by fragmented tools like Google Sheets or physical whiteboards. It exhibits strong Founder/Market Fit potential if the team has deep domain expertise. However, it combines a highly complex B2B-style management tool (Task/Plot coordination) with a B2C-style content/social tool (Expert Q&A/Knowledge base), creating a broad scope that risks feature bloat and a lack of focus.
Pros and Cons of the Proposed Path
Area | Pros (Evidence-Based Reasoning) | Cons (Risk/Complexity) |
Product Market Fit (PMF) | Addresses a Niche Administrative Pain: Existing apps focus heavily on individual gardening (e.g., plant ID, private journals). This app targets the community management gap, which is a specific, solvable pain point for coordinators. | Low-Frequency Use: Community plot planning and major tasks often happen seasonally. Users might not require the app daily or weekly, risking low retention, which is a key indicator of poor PMF. |
UX/Architecture | Dual Value Proposition: Appeals to two distinct personas (Coordinator/Admin and Gardener/Member), providing separate, tailored value streams. This suggests a strong subscription/licensing model (B2B for the Coordinator). | High Initial Scope/Cost: The features require three distinct architecture components: 1) A sophisticated Task/CRM backend (for plot management, waitlists, tracking), 2) A Knowledge Base CMS, and 3) A real-time chat/Q&A module. This high complexity increases development cost and time. |
Go-to-Market (GTM) | Clear B2B GTM Path: The product can be sold as a dedicated SaaS tool directly to Community Garden organizations, non-profits, or municipal parks departments. This offers a predictable, higher revenue per customer compared to B2C. | Reliance on the 'Coordinator' User: If the Coordinator finds the tool too complex or too costly, adoption fails completely, regardless of how much members like the Q&A feature. The GTM success is entirely dependent on B2B sales cycles. |
Monetization | Multiple Revenue Streams: Can combine B2B licensing (Coordinator task tool) with B2C/Affiliate models (expert content, affiliate links for supplies). | Expert Content Monetization Challenge: If the expert content is free, it cannibalizes the potential for a paid knowledge subscription. If it's paid, it must be significantly better than existing free tools or general gardening apps. |
У цьому розділі здаються спірними окремі аргументи проти.
В умовах чітко сказано, що це не лише застосунок "база знань", а й застосунок "комунікатор". А за питаннями люди приходять будь-якої пори року.
В умовах не було сказано, що необхідно платити за довідковий контент і аналізувати цю функцію.
На наш погляд, модель спробувала сама вигадати модулі для оцінки, а потім оцінити їх. В результаті вийшов досить дженериковий опис. Натомість на запитання «Хто може бути додатковою аудиторією?» модель запропонувала такі варіанти:
Secondary/Expansion Markets
If the core idea achieves strong PMF, the potential audience could expand to other structured gardening environments:
Educational Institutions: School or university gardens where the Coordinator tool is used by teachers to assign tasks to students.
Corporate Wellness Programs: Companies that provide garden plots for employee use, needing the Coordinator features for internal management.
Homeowner Associations (HOAs): Communities that manage shared landscaping or small community garden patches, where communication and task assignment is needed.
Але й тут останній варіант, начебто, є розвитком основного. Швидше за все, модель просто не зіставила “gardeners community” і “home owners associations”.
Втім, якщо не чіплятися, то відповіді моделі можуть, як мінімум, дати інформацію для роздумів. Але ідеального варіанту одразу чекати точно не варто.
Валідація діаграм
Одним із наступних обов'язкових кроків розробки проекту може стати створення use case-діаграми та ERD. Можна попросити модель зібрати діаграму в Plantuml. Можна попросити модель перевірити діаграму, яку ви створили самі. Я вибрав другий варіант. Потрібно було п'ять ітерацій, щоб і модель, і я визнали, що use case-діаграма, яка вийшла, адекватно відображає реальні запити.
При цьому слід мати на увазі два моменти. Налаштування розпізнавання зображення слід виставити на максимально доступний рівень. Але навіть у цьому випадку модель може помилитись. Наприклад, модель не побачила стрілочки, яка означає генералізацію. Тільки після того, як я виділив стрілочку маркером, модель «виправилася»
Результуюча діаграма виглядає так:
Те саме можна зробити з діаграмою сутностей і зв'язків. Система, пам'ятаючи use case-діаграму, може вказати на сумнівні зв'язки або на пропущені сутності. Нижче наведено деякі приклади.
Response
The analysis below focuses on data integrity, scalability, security, and alignment with the previously defined use cases.
1. Data Integrity and Relationship Analysis
This section covers issues related to redundancy, conflicting sources of truth, and relationship logic.
Table/Area | Observation | Impact | Recommendation |
User Roles | The User table has a Role enum (Regular, Expert, Coordinator), but there are also separate CommunityCoordinators and CommunityExperts tables. | This creates two sources of truth for a user's role, leading to potential data inconsistency. For example, a user could have Role = 'Regular' in the User table but an entry in the CommunityCoordinators table. | Choose one method. The separate tables (CommunityCoordinators, CommunityExperts) are more scalable and flexible. Recommended Action: Remove the Role column from the User table and rely solely on the existence of a record in the respective role tables to determine user privileges. |
2. Missing Functionality from Use Cases
This section identifies where the data model does not fully support required features.
Use Case Area | Missing Functionality | Recommendation |
Knowledge Base Workflow | The KnowledgeBasePost table is missing a Status field to manage the review process. | Add a Status column with an enum like ('Draft', 'Pending Review', 'Published', 'Rejected'). This is critical for the workflow where an Expert submits a post and a Coordinator approves it. |
Результуюча діаграма виглядає так:
Здесь модель может оказать существенную помощь (особенно в условиях лимита времени) проверив работу на самые очевидные пропуски и предложив самые очевидные решения.
Нефункціональні вимоги
LLM може допомогти і у формулюванні нефункціональних вимог. Часто цей клас вимог залишається без належної уваги – або аналітик, або клієнт не має достатньо часу, щоб відповісти на запитання «як?». Модель може швидко накидати чернетку «нефункціоналок» з врахуванням контексту проекту. Аналітику вже буде з чим йти до клієнта та уточнювати деталі.
Prompt:
What would be the non functional requirements for this app?
Response (excerpt):
1. Usability
Usability ensures the application is intuitive, efficient, and satisfying for all target personas, from the tech-savvy "Sarah" to the less tech-comfortable "George."
NFR ID | Requirement | Rationale & Measurement |
US-1 | Task Efficiency | Key user tasks (e.g., signing up for a volunteer task, booking a tool, posting surplus produce) shall be completable in no more than 4 taps/clicks from the main dashboard. |
US-2 | Onboarding | First-time users shall be guided through a simple, optional onboarding tour that explains the five core functional areas of the app. |
US-3 | Error Messaging | All error messages displayed to the user must be in plain, non-technical language and suggest a clear resolution path. |
US-4 | UI/UX Consistency | The application shall maintain a consistent design language (colors, fonts, button styles, navigation patterns) across all screens. |
2. Performance
Performance requirements ensure the application is responsive and operates efficiently, especially on mobile devices with variable network conditions.
NFR ID | Requirement | Rationale & Measurement |
PE-1 | Load Time | All critical views (e.g., task list, tool availability, garden map) shall load completely within 2 seconds on a stable Wi-Fi or 4G connection. |
PE-2 | API Response Time | Server-side API endpoints shall have an average response time of less than 500 milliseconds for 95% of requests under normal load. |
PE-3 | Low Bandwidth Operation | The application must remain functional, albeit with potentially longer load times, on low-bandwidth networks (equivalent to a 3G connection). Core actions should not time out. |
PE-4 | Battery Consumption | When running in the background, the application shall not consume significant device battery. Background processes should be limited to essential tasks like push notifications. |
3. Security
Security is critical to protect member data and ensure the integrity of the community garden's operations.
NFR ID | Requirement | Rationale & Measurement |
SE-1 | Data in Transit | All data transmitted between the client application and the server must be encrypted using Transport Layer Security (TLS) 1.2 or higher. |
SE-2 | Data at Rest | All personally identifiable information (PII) stored in the database, including names and email addresses, must be encrypted. |
SE-3 | Password Security | User passwords must be stored using a modern, salted, one-way hashing algorithm (e.g., Argon2 or bcrypt). Plaintext passwords must never be stored. |
SE-4 | Authorization | The system must enforce Role-Based Access Control (RBAC) at the API level. A user must not be able to access or modify data they are not authorized for (e.g., a Member cannot access Coordinator functions). |
4. Reliability & Availability
These requirements ensure the system is stable, trustworthy, and available when members need it.
NFR ID | Requirement | Rationale & Measurement |
RE-1 | System Uptime | The application services shall achieve 99.5% availability, measured monthly. This excludes scheduled maintenance windows. |
RE-2 | Data Durability | All successfully submitted data (e.g., a new task, a knowledge base post, a tool booking) must be durable and not lost in case of a non-catastrophic server failure. |
RE-3 | Backup and Recovery | The production database shall be backed up automatically at least once every 24 hours. The system must have a documented recovery plan with a Recovery Time Objective (RTO) of 4 hours and a Recovery Point Objective (RPO) of 24 hours. |
RE-4 | Graceful Degradation | If a non-essential third-party service (e.g., a map provider) fails, the core functionality of the application must remain operational. |
5. Scalability
Scalability ensures the system can grow to accommodate more users and potentially more gardens without requiring a complete redesign.
NFR ID | Requirement | Rationale & Measurement |
SC-1 | Concurrent Users | The system must support up to 500 concurrent users for a single community garden without significant performance degradation. |
SC-2 | Multi-Tenancy Support | The underlying architecture and data model must be designed to support multiple, isolated community gardens in the future without major refactoring. |
6. Compatibility
Compatibility defines the range of devices and operating systems the application will support.
NFR ID | Requirement | Rationale & Measurement |
CO-1 | Mobile Operating Systems | The native mobile application must be fully functional and supported on the latest two major versions of iOS and Android at the time of release. |
CO-2 | Web Browsers (if applicable) | If a responsive web app is built, it must be fully functional on the latest stable versions of Google Chrome, Mozilla Firefox, Apple Safari, and Microsoft Edge. |
7. Accessibility
Accessibility ensures that the application can be used by people with a wide range of abilities, directly addressing the retired expert persona.
NFR ID | Requirement | Rationale & Measurement |
AC-1 | WCAG Compliance | The application interface shall adhere to the Web Content Accessibility Guidelines (WCAG) 2.1 Level AA standards. |
AC-2 | Text Scalability | Users must be able to increase the font size within the application using their device's native accessibility settings without breaking the UI layout. |
Work breakdown structure
Штучний інтелект може допомогти з чернеткою WBS. Цілком можливо, що в даному випадку модель «надрібнила», і розробники віддадуть перевагу більш закінченим частинам. Але, повторимося, це лише створення відправної точки для обговорення з архітектором і з командою.
Prompt:
Please create a work breakdown structure as a hierarchy points for excel table
Response (excerpt):
This WBS breaks the project down from major phases into specific, manageable work packages. You can copy and paste this directly into Excel and use the "Increase Indent" feature to create the hierarchy visually.
3.3 | Feature: Onboarding & Registration | |
3.3.1 | Backend: User Registration API | Endpoint to create a new user (with password hashing). |
3.3.2 | Backend: User Login API | Endpoint to authenticate a user and issue a token. |
3.3.3 | Frontend: Registration Screen UI | Build the sign-up form. |
3.3.4 | Frontend: Login Screen UI | Build the sign-in form. |
3.3.5 | Backend: Community Creation & Join Request APIs | |
3.3.5.1 | Backend: Create Community API | Endpoint for a user to create a new community (and become its first coordinator). |
3.3.5.2 | Backend: Search Communities API | Endpoint for a user to search for existing communities. |
3.3.5.3 | Backend: Submit Join Request API | Endpoint for a user to send a request to join a community. |
3.3.5.4 | Backend: Approve/Reject Join Request API | Endpoint for a Coordinator to manage pending join requests. |
3.3.6 | Frontend: Community Selection & Management UI | |
3.3.6.1 | Frontend: Post-Registration Choice Screen | Build the UI for the "Create New Community" vs. "Join Existing Community" choice. |
3.3.6.2 | Frontend: Create Community Form UI | Build the UI for a user to name and describe a new community. |
3.3.6.3 | Frontend: Join Community Search & Request UI | Build the UI for searching and submitting join requests to communities. |
3.3.6.4 | Frontend: Coordinator Join Request Management UI | Build the admin UI for a Coordinator to view and act on join requests. |
User stories
Вот як LLM впоралась із створенням історій користувача:
Prompt:
Create a set of user stories for the following functionalityMember view:
· see shared tasks
· get notified about an upcoming shared task
· see my signed up shared tasks
· take a shared task
· leave a shared task
· report a share task
Response:
Here is a set of user stories for the "Shared Tasks" functionality, meticulously crafted to align with the defined MVP scope for both Member and Coordinator views.
Shared Tasks Management
Member View User Stories
User Story ID | User Story | Acceptance Criteria |
US-M-ST-01 | As a Member, I want to see a list of all available shared tasks in my community, so that I can find opportunities to contribute. | 1. There is a "Shared Tasks" section in the application. <br>2. This section displays a list of all active communal tasks. <br>3. For each task, I can see its Title, Description, Date/Time, and the number of volunteers required vs. signed up. <br>4. I can sort tasks by date or urgency. |
US-M-ST-02 | As a Member, I want to get notified about an upcoming shared task that is relevant to me, so that I don't miss opportunities to contribute. | 1. I receive a notification (in-app or push) for shared tasks nearing their start time or sign-up deadline. <br>2. Notifications are clear and link directly to the task details. <br>3. I can optionally manage my notification preferences for tasks. |
US-M-ST-03 | As a Member, I want to see a list of shared tasks I have signed up for, so that I can keep track of my commitments. | 1. There is a dedicated section (e.g., "My Tasks" or within "Shared Tasks") that displays only the tasks I have personally committed to. <br>2. This list shows the task's Title, Date/Time, and my sign-up status. |
US-M-ST-04 | As a Member, I want to take (sign up for) an available shared task, so that I can easily commit my time to help the community. | 1. From the list of available tasks, there is a clear "Sign Up" button for each task. <br>2. After clicking "Sign Up," my name is added to the list of volunteers for that task. <br>3. I receive a confirmation that I have successfully signed up. <br>4. The number of available spots for the task is updated. |
US-M-ST-05 | As a Member, I want to leave a shared task I previously signed up for, so that I can adjust my commitments if my plans change. | 1. From the list of tasks I have signed up for, there is a clear "Leave Task" or "Cancel Sign Up" button. <br>2. A confirmation prompt appears before I can leave. <br>3. After leaving, my name is removed from the task's volunteer list. <br>4. The number of available spots for the task is updated. |
US-M-ST-06 | As a Member, I want to report a shared task as completed, so that the community knows the work is done. | 1. From the list of tasks I have signed up for (and optionally for tasks I haven't signed up for but completed), there is an option to "Report as Complete". <br>2. Upon reporting, the Coordinator is notified, and the task status can be updated (pending Coordinator review). |
Прототип
На завершальному етапі був створений Scope of work з набором функціональності для MVP. Цей документ разом із use case-діаграмою та схемою даних (ERD) були завантажені в Lovable. Прототип є адаптивним веб-додатком.
Як бачимо, прототип, що вийшов, наочно демонструє ідею, досить чітко відображає доступні функції. Яка може бути користь такого прототипу? Найочевидніше – дискавері. У них може не бути виділеного дизайнера, проект може бути досить швидким. І у аналітика є вибір: зібрати чорно-білий прототип у Figma або попросити модель зробити красиво. Створений прототип буде гарною відправною точкою запитань клієнту: «Вам кольори подобаються? Яку-небудь функцію перенести вище?» і таке інше. Більш детальну роботу краще все-таки довірити фахівцю.
Деякі висновки
Модель почала галюцинувати приблизно на 150000 використаних токенів (враховуються токени введення та виведення). У відповідях почали з'являтися неіснуючі ролі (наприклад, системний адміністратор), фічі, обсяг MVP. Як мінімум три рази доводилося просити модель «забути» кілька попередніх вхідних даних. (Швидше за все, свою роль відіграло «забруднення» контексту проханнями оптимізувати дані під .csv формат тощо). Вихід – тримати в одній бесіді тільки те, що стосується проекту.
Чи визнавати експеримент вдалим – залежить від того, що аналітик хоче отримати від моделі. Якщо потрібно швидко зібрати набір «шаблонів», які можна потім «збагатити» реальними цифрами, реальними характеристиками тощо – модель може допомогти. Але при цьому, аналітик зобов'язаний перевірити все до останньої коми та поправити там, де треба. Цілком можливо, такий метод підійде для швидких проектів чи дискавері. Аналітик зможе швидко збудувати «каркас». Але при цьому, на наш погляд, слід однозначно комунікувати команді та керівництву проекту, що це не означає скорочення термінів підготовки вимог.
З іншого боку, модель добре працює як валідатор, якщо отримає максимум доступного контексту. Всі ми знаємо ситуації, коли вимоги пишуться у вільний від дзвінків час. У таких умовах зайве «око», навіть штучне – цілком може помітити, що ви не врахували раніше доданий елемент. В той же час, модель може почати додавати свої галюцинації.
В цілому модель точніше працює над одним компактним, але самостійним завданням, ніж над серією завдань, включених в одну велике завдання. Було б цікаво спробувати створити щось на кшталт агента, який пам'ятатиме контекст. Але якому можна давати десяток самостійних, окремих завдань у рамках загального контексту.
Чи замінить модель аналітика найближчим часом? Швидше за все, ні. Якщо сприймати аналітика не як генератора вимог, а як «комунікатора» на перехресті потоків інформації – від замовників, користувачів, розробників.
Чи легше працювати з LLM? У певному сенсі – так. Всім знайомий страх «чистого листа» або страх не втримати в голові черговий кущ вимог. LLM допоможе швидко зануритися в предметну область і допоможе побудувати «координатну сітку» з дженерикових шаблонів. Можливо, модель допоможе молодим аналітикам на перших бойових проектах.
З іншого боку, навряд чи вдасться так само представляти команді або клієнту вимоги, створені моделлю, як свої власні. Модель не здатна почути сумнів у голосі користувача. Розробника не влаштує відповідь «бо модель так написала». Замовника не влаштує швидко створений додаток, але з «діркою» на не очевидному місці. Зрештою, головне диво розробки програмного забезпечення все ще тут: звичайні люди роблять трохи легшим життя інших звичайних людей.
Новини та статті з бізнес-аналізу: