Уровень 3 (занятие) · лекция · 19 сентября, 11:10
Требования к системе: бизнес, функциональные, нефункциональные
Как из Vision и user stories вырастает описание системы: бизнес-требования, функциональные и нефункциональные требования, архитектура и структура данных.
В предыдущих сериях
User story (пользовательская история) — это краткое описание функциональности продукта или системы с точки зрения конечного пользователя. Она фокусируется на том, что именно пользователь хочет сделать в системе и почему это важно для него.
Критерии INVEST
User story mapping
User story mapping - это метод визуализации и организации пользовательских историй в виде карты, который помогает командам разработки лучше понять потребности пользователей и определить приоритеты в разработке функций.
Сравнение с аналогами
Зачем вообще нужны требования
●Требование не записано — команда сделала то, что поняла, а заказчик ждал другого
●Требование без числа — «быстро» у каждого своё, и выясняется это на защите
●Требование не проверено с заказчиком — сделали не то, а переделывать некогда
●Требование без критерия приёмки — о готовности спорим, когда сдавать уже поздно
Про продукт
1.Что мы делаем и чего хотим достичь?
Vision, Mission
2.Зачем пользователю наш продукт?
User stories
3.Запланировать User stories
4.Обзор аналогов
Не фиксированно, может меняться
1.Что мы делаем и чего хотим достичь?
Vision, Mission
2.Зачем пользователю наш продукт?
User stories
3.Запланировать User stories
4.Обзор аналогов
Mission, Vision
Бизнес-требования
Пользовательские сценарии
Функциональные требования
Нефункциональные требования
Архитектура
Структура данных
Mission, Vision
Бизнес-требования
Пользовательские сценарии
Функциональные требования
Нефункциональные требования
Архитектура
Структура данных
Что такое бизнес-требования?
Бизнес-требования
Бизнес-требования
— это формулировка целей и ожидаемых результатов, которых нужно достичь при создании/развитии продукта.
«Что должен получить бизнес (компания, заказчик) в итоге, чтобы считать проект успешным?»
Примеры бизнес требований
1.«Снизить расходы на администрирование проектной деятельности на 20% за год».
2.«Сократить время подбора проекта студентом с 2 недель до 3 дней».
3.«Не менее 80% студентов должны выбрать проект через платформу».
4.«Преподаватели должны иметь возможность публиковать проекты и управлять заявками студентов».
5.«Система должна быть доступна пользователям не менее 99,5% учебного времени».
6.«Обработка персональных данных студентов должна соответствовать ФЗ-152».
7.«Через 2 года платформа должна использоваться в 3 других университетах»
Типы бизнес-требований
1.Финансовые
2.Временные
3.Пользовательские
4.Функциональные
5.Качественные
6.Регуляторные
7.Стратегические
Подходы написания бизнес-требований
1. SMART
Формулирует цели так, чтобы они были конкретные, измеримые, достижимые,
релевантные и ограниченные по времени.
●Пример: «Увеличить процент студентов, выбравших проект через платформу, с 60% до 90% за один учебный год».
2. OKR (Objectives and Key Results)
Разделяет цель на вдохновляющую формулировку (Objective) и измеримые показатели (Key Results).
Пример:
●Objective: Сделать платформу основным
способом подбора проектов.
●KR1: ≥ 80% студентов выбрали проект
через платформу.
●KR2: Среднее время подбора ≤ 3 дня.
Подходы написания бизнес-требований
Откуда берутся бизнес-требования
●Заказчик. Цели, деньги, сроки, критерий успеха проекта
●Пользователь. Сценарии, боль, обходные пути, которыми пользуется сейчас
●Регулятор. ФЗ-152, правила вуза, лицензии, стандарты
●Эксплуатация. Кто это будет поддерживать, на каком железе и за какие деньги
Пять вопросов заказчику
1.Как вы поймёте через год, что проект удался?
2.Что происходит сейчас, пока системы нет?
3.Кто ещё будет этим пользоваться, кроме вас?
4.Чего система не должна делать ни при каких условиях?
5.Сколько пользователей и как часто они приходят?
LLM играет заказчика
●Промпт: «Ты заказчик платформы подбора проектов в вузе. Отвечай коротко, сам требований не предлагай, отвечай только на заданный вопрос»
●Смысл в том, чтобы научиться спрашивать, пока картина не станет ясной
●Что модель делает плохо: соглашается со всем и выдумывает цифры
●Репетиция перед разговором с живым заказчиком
Бизнес-требования: как не надо
Как не надо
●«Сделать удобную платформу»
●«Снизить нагрузку на преподавателей»
●«Внедрить микросервисы»
Бизнес-требования: как не надо
Как не надо
●«Сделать удобную платформу»
●«Снизить нагрузку на преподавателей»
●«Внедрить микросервисы»
Как надо
●«Сократить время подбора проекта с 2 недель до 3 дней»
●«Снизить расходы на администрирование на 20 % за учебный год»
●«Выдержать рост до трёх вузов без переписывания системы»
Ступень пройдена: бизнес-требования
●Бизнес-требование говорит, что получит заказчик: цель, число, срок
●Берём у заказчика, пользователя, регулятора и тех, кто будет это эксплуатировать
●Пишем по SMART или OKR; без числа и срока это пожелание
Mission, Vision
Бизнес-требования
Пользовательские сценарии
Функциональные требования
Нефункциональные требования
Архитектура
Структура данных
Что такое функциональные требования?
Функциональные требования
— это описание того, какие действия и возможности должна предоставлять система пользователям или другим системам.
«Что должна делать система?»
В чем разница с бизнес-требованиями?
В чем разница с бизнес-требованиями?
Бизнес-требования
продукт
Функциональные требования
система
В чем разница с бизнес-требованиями?
Функциональные требования = что должна делать система (фичи).
Бизнес-требования = какие цели бизнеса должны быть достигнуты благодаря этим фичам.
Функциональные требования
●«Система должна позволять студенту вводить ФИО и номер группы при регистрации».
●«Система должна проверять, не превысил ли проект лимит участников при подаче заявки».
●«Система должна отображать список доступных проектов с фильтрацией по тегам».
●«Система должна поддерживать авторизацию через университетский SSO».
●«Преподаватель должен иметь возможность создавать и редактировать проекты».
Функциональные требования: как не надо
Как не надо
●«Удобный личный кабинет»
●«Система работает с файлами»
●«Быстрый поиск проектов»
Функциональные требования: как не надо
Как не надо
●«Удобный личный кабинет»
●«Система работает с файлами»
●«Быстрый поиск проектов»
Как надо
●«Студент видит статус каждой заявки: подана, принята, отклонена»
●«Преподаватель прикладывает к проекту до 5 файлов PDF или DOCX размером до 10 МБ»
●Это вообще не функциональное требование — это нефункциональное
У требования есть критерий приёмки
| Требование | Как проверяем | Кто проверяет |
|---|---|---|
| Студент подаёт заявку на проект | Сценарий в браузере: подал — статус «подана» | Тестировщик команды |
| Поиск отвечает за 200 мс | Замер на базе из 100 тысяч записей | Автотест в CI |
| Пароли не хранятся в открытом виде | Ревью кода и дамп таблицы пользователей | Ревьюер команды |
| Заявку видит только автор и преподаватель | Запрос чужого id возвращает 403 | Автотест |
Спека для агента = функциональное требование
●«Сделай форму подачи заявки удобной» — агент напишет любой код и отчитается об успехе
●«Форма подаёт заявку, показывает ошибку по каждому полю, после успеха ведёт на страницу статуса» — это проверяемо
●Требование без критерия приёмки одинаково бесполезно для человека и для агента
●Если по формулировке нельзя написать тест, агент напишет тест сам — под то, что получилось
Функциональные требования
1.Ввод данных
2.Обработка данных / бизнес-логика
3.Вывод данных
4.Интеграции / взаимодействие с внешними системами
5.Администрирование и управление
Упражнение: откуда взялось это требование
●Возьмите одно своё функциональное требование
●Поднимитесь вверх: из какой user story оно следует
●Ещё выше: из какого бизнес-требования следует история
●И ещё: какому пункту Vision это служит
●Не поднимается — либо требование лишнее, либо в Vision дыра
Ступень пройдена: функциональные требования
●Функциональное требование говорит, что система делает: ввод, обработка, вывод, интеграции, администрирование
●Каждое выводится из user story; не выводится — в проекте ему не место
●У каждого есть критерий приёмки: как проверяем и кто проверяет
Mission, Vision
Бизнес-требования
Пользовательские сценарии
Функциональные требования
Нефункциональные требования
Архитектура
Структура данных
Что такое нефункциональные требования?
Нефункциональные требования
— это характеристики системы, которые определяют как она должна работать, а не что именно делать.
«Насколько хорошо система выполняет свои функции?»
Нефункциональные требования
1.«Система должна обрабатывать не менее 1000 запросов в секунду при средней задержке < 200 мс».
2.«Система должна быть доступна не менее 99,5% учебного времени».
3.«Система должна поддерживать увеличение нагрузки в 5 раз без изменения архитектуры».
4.«Система должна хранить пароли только в зашифрованном виде (bcrypt, не менее 10 итераций)».
5.«Новый пользователь должен уметь зарегистрироваться и найти проект за ≤ 5 минут без обучения».
6.«Система должна корректно работать в Chrome, Firefox и Safari последних двух версий».
7.«Добавление нового типа проекта должно занимать не более 2 часов разработки».
8.«Система должна соответствовать требованиям ФЗ-152 по защите персональных данных».
Откуда берётся число в требовании
●400 студентов, каждый заходит примерно раз в день
●20 запросов за заход — это 8 000 запросов в сутки
●8 000 / 86 400 ≈ 0,1 запроса в секунду в среднем
●Пик в день дедлайна выше в 10–30 раз: 1–3 запроса в секунду
●«1000 запросов в секунду» промахивается на три порядка
Нефункциональные требования
1.Производительность
2.Надёжность и доступность
3.Масштабируемость
4.Безопасность
5.Юзабилити
6.Совместимость
7.Поддерживаемость и сопровождаемость
8.Соответствие нормам и стандартам
Три категории, которые дойдут до вашего проекта
| Категория | Пример с числом | Чем проверить |
|---|---|---|
| Производительность | Список проектов открывается за 1 с при 100 тысячах записей | Замер в CI на боевом объёме |
| Доступность | 99,5 % — это 3,6 часа простоя в месяц | Health-check и журнал инцидентов |
| Безопасность | Пароли argon2id; заявку видит только автор и преподаватель | Ревью и тест на чужой id |
Требование с числом определяет архитектуру
| Требование | Так уже нельзя | Значит, нужно |
|---|---|---|
| 99,5 % доступности | Держать один процесс и перезапускать руками | Health-check, автоперезапуск, резервная копия |
| Поиск за 200 мс по 100 тысячам проектов | Искать перебором в коде приложения | Индекс в базе или поисковый движок |
| Данные студентов хранятся в РФ | Взять зарубежное облако | Сервер вуза или российский хостинг |
| Файл до 100 МБ на проект | Класть файлы в саму базу | Объектное хранилище, в базе только ссылка |
Требования спорят друг с другом
●99,9 % доступности против команды из пяти человек и одного сервера
●Шифровать все поля против искать по ним
●Вход только через SSO вуза против регистрации за 30 секунд
●Что делать: назвать конфликт вслух, выбрать приоритет, записать решение и его цену
Функциональные требования = что система делает (функции).
Нефункциональные требования = как хорошо система это делает (качество, ограничения, стандарты).
Функциональные vs Нефункциональные
Что делаем сначала: MoSCoW
●Must. Без этого продукта нет
●Should. Важно, но продукт живёт и без этого
●Could. Сделаем, если останется время
●Won’t. Решили не делать в этом релизе — и записали это
LLM вычитывает ваши требования
●Промпт: «Вот список требований. Найди противоречия, требования без критерия приёмки, пропущенные сценарии ошибок и требования без числа»
●Находит хорошо: пропущенные сценарии, требования без числа, дубли
●Находит плохо: конфликт с бизнес-целью, которую вы ей не показали
●Проверяйте вывод: модель уверенно придумывает и требования, и цифры
Ступень пройдена: нефункциональные требования
●Нефункциональное требование говорит, насколько хорошо система работает, и всегда с числом
●Число считается от аудитории: пользователи, заходы, запросы, пик
●Каждое число вычёркивает часть архитектурных вариантов, а конфликты между требованиями называются заранее
Mission, Vision
Бизнес-требования
Пользовательские сценарии
Функциональные требования
Нефункциональные требования
Архитектура
Структура данных
Что такое архитектура системы?
Для чего нужна архитектура?
1.Обеспечить понимание системы всеми участниками (разработчики, менеджеры, заказчики).
2.Сделать систему поддерживаемой и расширяемой.
3.Учитывать нефункциональные требования (масштабируемость, надёжность, безопасность).
4.Снизить риски ошибок и затрат на переделки
Архитектура
1.Определение целей и ограничений
●Бизнес-требования (что система должна решать).
●Нефункциональные требования (скорость, надёжность, бюджет, сроки).
●Технологические ограничения (например, «обязательно использовать PostgreSQL», «должно работать в облаке Azure»)
Этапы составления
2. Выбор архитектурного стиля
●Монолит, микросервисы, слойная архитектура, событийно-ориентированная, клиент-сервер и т.п.
●Подбор подхода под задачи и ограничения
Этапы составления
3. Определение основных компонентов
●Какие крупные модули нужны (авторизация, база данных, API, фронтенд).
●Их ответственность (каждый отвечает за «своё»)
Этапы составления
4. Определение взаимодействия компонентов
●Какие протоколы и интерфейсы используются (REST, GraphQL, gRPC).
●Как хранится и передаётся информация.
●Синхронные и асинхронные взаимодействия
Этапы составления
5. Согласование с нефункциональными требованиями
●Масштабируемость → возможно нужны микросервисы или балансировщики.
●Безопасность → слои авторизации, шифрование.
●Надёжность → репликации баз данных, резервирование.
Этапы составления
6. Документирование и визуализация
●Диаграммы (часто используют C4-модель).
●Текстовое описание ключевых решений («почему выбран этот подход»).
●Принципы и правила (coding guidelines, правила интеграции).
Этапы составления
Ступень пройдена: архитектура
●Архитектура — это компоненты, связи между ними и ограничения
●Вход в неё — требования, которые мы только что написали
●Стили, критерии выбора, C4 и ADR разбираем на отдельном занятии
Mission, Vision
Бизнес-требования
Пользовательские сценарии
Функциональные требования
Нефункциональные требования
Архитектура
Структура данных
Что такое структура данных?
— это описание того, какие данные хранятся и обрабатываются в системе, как они организованы, связаны и где располагаются.
Структура данных
Для чего нужна структура данных?
●Чтобы понять, какие данные система обрабатывает и в каком виде.
●Чтобы спроектировать базы данных и API.
●Чтобы обеспечить корректность и целостность данных.
●Чтобы оптимизировать хранение и доступ (скорость работы, экономия ресурсов).
Для чего нужна структура данных?
1.Анализ предметной области → выявление сущностей.
2.Определение атрибутов каждой сущности.
3.Определение связей между сущностями.
4.Выбор модели хранения (SQL, NoSQL, граф).
5.Проектирование схемы данных (ER-диаграмма, JSON-схема и др.).
6.Уточнение ограничений и правил целостности.
Как составляется
●Описание. Что это за объект, какую роль играет в системе.
●Количество. Сколько таких объектов ожидается (например, пользователей — тысячи, логов — миллионы).
●Максимальное значение одного объекта. Размер в байтах/записях (например, у одного пользователя может быть до 100 проектов).
●Среднее значение одного объекта. Средняя «нагрузка» (например, в среднем у пользователя 3 проекта).
●Время жизни (lifecycle) Сколько объект живёт в системе: постоянные (например, пользователи), временные (например, сессии, токены), архивируемые (например, старые проекты через 5 лет).
●Доступы (permissions). Кто может создавать, читать, изменять, удалять. Уровни доступа: пользовательские, админские, публичные.
Что мы знаем про каждую сущность?
Паспорт сущности: «Заявка»
| Поле | Значение |
|---|---|
| Описание | Заявка студента на участие в проекте |
| Количество | 400 студентов × 3 заявки ≈ 1 200 записей за учебный год |
| Максимум на объект | До 10 заявок у одного студента |
| Среднее | 3 заявки на студента |
| Время жизни | Учебный год, дальше в архив |
| Доступы | Создаёт студент; читают студент и преподаватель проекта; статус меняет преподаватель |
●Объём данных растёт. Количество пользователей, заказов, логов увеличивается → нужны стратегии масштабирования (шардирование, архивирование, индексация).
●Структура данных может меняться Добавление новых атрибутов (например, «аватар» у пользователя). Изменение связей (например, раньше у проекта был 1 владелец, теперь может быть несколько). Удаление устаревших полей.
●Жизненный цикл. Часть данных «умирает» (сессии, временные файлы). Часть — уходит в архив (заказы старше 3 лет).
●Эволюция требований. Бизнес растёт → появляются новые сущности (например, система скидок → сущность «Купон»). Меняется бизнес-логика → изменяются ограничения и правила.
Как изменяется со временем
Ступень пройдена: структура данных
●Структура данных — сущности, их атрибуты и связи между ними
●По каждой сущности заполняется паспорт: объём, максимум, среднее, время жизни, доступы
●Данные растут и меняются, и это закладывается сразу, а не после запуска
Что из этого спросят на защите RAT-PoC
●RAT — проверка самого рискованного предположения проекта
●Риск почти всегда сидит в нефункциональном требовании с числом или во внешней интеграции
●На защите: какое требование проверяли, чем измеряли, что получилось
●Если все требования выглядят очевидно выполнимыми — риск просто не найден
Требования готовы, если
●Каждое функциональное требование выводится из user story
●У каждого требования есть критерий приёмки
●Каждое нефункциональное требование с числом, и число посчитано, а не придумано
●Приоритеты расставлены, конфликты названы вслух
●У каждой сущности заполнен паспорт
Mission, Vision
Бизнес-требования
Пользовательские сценарии
Функциональные требования
Нефункциональные требования
Архитектура
Структура данных
← → листать · F на весь экран · P режим докладчика · Esc выйти
О чём лекция
На прошлом занятии мы описывали продукт: зачем он, кому и чем отличается от аналогов. Сегодня спускаемся на уровень системы — что именно надо построить и по каким правилам.
- Цепочка документов. Mission и Vision → бизнес-требования → пользовательские сценарии → функциональные требования → нефункциональные требования → архитектура → структура данных. Каждый следующий пункт опирается на предыдущий, и ни один не фиксируется навсегда.
- Бизнес-требования. Цели и результаты, ради которых заказчик вообще затевает проект. Семь типов — от финансовых до регуляторных — и два способа формулировки: SMART и OKR.
- Функциональные требования. Что система делает: ввод, обработка, вывод, интеграции, администрирование. Чем они отличаются от бизнес-требований: бизнес — про продукт и цели, функциональные — про систему и фичи.
- Нефункциональные требования. Насколько хорошо система это делает: производительность, доступность, масштабируемость, безопасность, юзабилити, совместимость, поддерживаемость, соответствие стандартам. Все с числами, а не «быстро» и «надёжно».
- Архитектура. Компоненты, связи между ними и ограничения. Шесть шагов: цели и ограничения → архитектурный стиль → компоненты → взаимодействие → сверка с нефункциональными требованиями → документирование (C4 и текст решений).
- Откуда берутся требования. Четыре источника: заказчик, пользователь, регулятор, эксплуатация. Пять вопросов, с которых начинается разговор с заказчиком, и LLM в роли заказчика на репетиции.
- Числа и приёмка. Откуда берётся число в нефункциональном требовании и почему «1000 запросов в секунду» в учебном проекте промахивается на три порядка. Критерий приёмки у каждого требования: как проверяем и кто проверяет. Конфликты между требованиями и приоритеты по MoSCoW.
- Структура данных. Сущности, атрибуты, связи. Как её составлять и что фиксировать по каждой сущности: описание, количество, максимум и среднее на объект, время жизни, кто имеет доступ.
Что сделать сегодня
- Посмотреть колоду выше и выписать для своего проекта по три бизнес-требования, пять функциональных и три нефункциональных — последние обязательно с числами.
- Проверить, что каждое функциональное требование выводится из user story прошлого занятия, а каждое бизнес-требование — из Vision.
- Посчитать хотя бы одно своё нефункциональное требование от аудитории, а не на глаз.
- Набросать список сущностей будущей базы и связи между ними: это заготовка к защите следующего этапа.