Опыт применения искусственного интеллекта в разработке требований
- Andrey Okorokov
- 5 часов назад
- 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 c набором функциональности для MVP. Этот документ вместе с use case-диаграммой и схемой данных (ERD) были загружены в Lovable. Прототип представляет собой адаптивное веб приложение.
Как видим, получившийся прототип наглядно демонстрирует идею, достаточно четко отображает доступные функции. Какая может быть польза от такого прототипа? Самое очевидное – проекты дискавери. В них может не быть выделенного дизайнера, проект может быть достаточно быстрым. И у аналитика есть выбор: собрать черно-белый прототип в Figma или попросить модель сделать красиво. Созданный прототип будет хорошей отправной точкой для вопросов клиенту: «Вам цвета нравятся? Какую-нибудь функцию перенести повыше?» и так далее. Более детальную работу лучше всё-таки доверить специалисту.
Некоторые выводы
Модель начала галлюцинировать примерно на 150000 использованных токенов (считаются токены ввода и вывода). В ответах начали появляться несуществующие роли (например, системный администратор), фичи, объём MVP. Как минимум три раза приходилось просить модель «забыть» несколько предыдущих вводных. (Скорее всего, свою роль сыграло «загрязнение» контекста просьбами оптимизировать данные под .csv формат и тому подобное). Выход – держать в одной беседе только то, что имеет отношение к проекту.
Признавать ли эксперимент удачным – зависит от того, что аналитик хочет получить от модели. Если требуется быстро собрать набор «шаблонов», которые можно затем «обрастить» реальными цифрами, реальными характеристиками и так далее – модель может помочь. Но при этом, аналитик обязан вычитать все до последней запятой и поправить там, где надо. Вполне возможно, такой метод подойдет для быстрых проектов или дискавери. Аналитик сможет быстро построить «каркас». Но при этом, на наш взгляд, следует однозначно скоммуницировать команде и руководству проекта, что это не означает сокращения сроков готовности требований.
С другой стороны, модель неплохо работает как валидатор, если получит максимум доступного контекста. Все мы знаем ситуации, когда требования пишутся в свободное от созвонов время. В таких условиях лишний «глаз», даже искусственный – вполне может заметить, что вы не учли ранее добавленный элемент. В то же время, модель может начать добавлять свои «галлюцинации».
В целом модель точнее работает над одной компактной, но самостоятельной задачей, чем над серией задач, включенных в одну большую. Было бы интересно попробовать создать что-то вроде агента, который будет помнить контекст. Но которому можно давать десяток самостоятельных, отдельных задач в рамках общего контекста.
Заменит ли модель аналитика в ближайшее время? Скорее всего нет. Если воспринимать аналитика не как генератора требований, а как «коммуникатора» на перекрёстке потоков информации – от заказчиков, пользователей, разработчиков.
Легче ли работать с LLM? В известном смысле – да. Всем знакома боязнь «чистого листа» или боязнь не удержать в голове очередной куст требований. LLM поможет быстро погрузиться в предметную область и поможет построить «координатную сетку» из дженериковых шаблонов. Возможно, модель поможет молодым аналитикам на первых «боевых» проектах.
С другой стороны, вряд ли получится точно так же представлять команде или клиенту требования, созданные моделью, как свои собственные. У модели не получится услышать сомнение в голосе пользователя. Разработчика не устроит ответ «потому что модель так написала». Заказчика не устроит быстро созданное приложение, но с «дырой» на не самом очевидном месте. В конце концов, главное чудо разработки ПО всё ещё здесь: обычные люди делают чуть легче жизнь других обычных людей.
Новости и статьи по бизнес-анализу: