Начало карьеры системного аналитика
Требование (англ. requirement) — описание функции и/или условия, которое должно соблюдаться приложением в процессе решения пользовательской задачи.
Пример
"План, что и говорить, был превосходный: простой и ясный, лучше не придумать. Недостаток у него был только один: было совершенно неизвестно, как привести его в исполнение"
© Алиса в стране чудес, Льюис Кэрролл
Если требования проекта сформулированы в двух предложениях, то может показаться, что все просто. Пока не начнешь задавать вопросы заказчику.
Пример
Зачем нужны требования?
Требования необходимы, потому что они:
🔸Позволяют понять что система должна делать
🔸Являются основой для формирования плана проекта
🔸Помогают предотвращать и разрешать конфликтные ситуации
🔸Упрощают расстановку приоритетов
🔸Дают возможность оценить масштаб изменений
🔸Позволяют оценить степень прогресса в разработке
Требования — это “скелет” каждого проекта. Проект без требований, превращается в битву экстрасенсов, в которой нет победителя.
Пример: нужно какую-то конкретику, когда делаем без требований, а когда с ними
Типы требований
Выделяют два основных уровня требований: верхнеуровневые и низкоуровневые.
Верхнеуровневые, они как вершина айсберга, описывают, то что на поверхности, к ним относят:
🔸Бизнес-требования (Business Requirements)
В БТ должна быть отражена цель, зачем создаётся продукт и какие проблемы он решает.
Кому и какие возможности нужно предоставить.
Пример: Необходимо в два раза повысить количество заявок, обрабатываемых одним оператором за смену.
🔸Пользовательские требования (User Requirements) описывают задачи, которые пользователь может выполнять с помощью разрабатываемого продукта, а также способы (сценарии) их решения в системе (реакция продукта на действия пользователя, сценарии работы пользователя).
Пример: У пользователя должна быть возможность зарегистрироваться.
Низкоуровневые требования, это то что скрыто от глаз обычного пользователя. Логика и детальное описание работы системы.
🔸Функциональные требования (functional requirements) описывают ЧТО система должна делать или не должна в каждый момент времени взаимодействия с пользователем.
Пример: Когда пользователь нажимает кнопку «Обработать заказ», система сохраняет данные заказа в БД и определяет его статус как «В очереди на обработку
🔸Нефункциональные требования (non-functional requirements) описывают КАК система должна взаимодействовать с пользователем (как должен выглядеть интерфейс, лёгкость и простота использования, какие есть ограничения, устойчивость к сбоям) .
Пример: система должна быть доступна 99,9% времени
Требования к требованиям
Требования должны быть простыми и понятными!
Чтобы они стали таковыми, необходимо перечитывать, то что ты написал и представлять как буд-то ты первый раз видишь эти требования.
✔️Упрощайте сложные формулировки
Пример хорошо и плохо
✔️ Разбивайте составные требования на несколько простых требований
Пример хорошо и плохо
✔️ Используй форматирование текста, нумерацию пунктов
Пример хорошо и плохо
✔️Описывай требования последовательно от общего к частному
Пример хорошо и плохо
✔️Используй таблицы, схемы
Пример хорошо и плохо
Требования также должны быть:
🔸Завершенными, т.е чётко описывающими каким образом мы достигнем цели
Пример хорошо и плохо
🔸Непротиворечивыми, т.е не должно быть нескольких требований, которые противоречат друг другу
Пример хорошо и плохо
🔸Реализуемыми в рамках сроков проекта. Помним, что ни при каких условиях "9 женщин не родят одного ребёнка за месяц"))
Пример хорошо и плохо
🔸Проверяемыми, т.е можно создать такой тест-кейс, при котором однозначно будет понятно, что требование реализовано верно.
Пример хорошо и плохо
Нужно какое-то заключение :)
Наталья Золотова,
Системный аналитик
https://www.instagram.com/cacaovmacao/
https://t.me/cacaovmacao
Контакты
+7 (499) 686-15-46
*Instagram — запрещенная на территории РФ организация
Практический опыт здесь, 2021-2024
Мы используем файлы cookie, для персонализации сервисов и повышения удобства пользования сайтом. Если вы не согласны на их использование, поменяйте настройки браузера.