Требования Flashcards
(6 cards)
Какие три основных уровня требований существуют в процессе разработки программного обеспечения?
- Бизнес-требования — описывают цели организации или заказчика системы.
- Пользовательские требования — определяют набор пользовательских задач, которые должна решать программа, а также способы (сценарии) их решения в системе.
- Системные требования — описывают требуемое поведение системы в определённых условиях.
Почему нефункциональные требования не включены в иерархию основных уровней требований?
Нефункциональные требования не включают в основные уровни, потому что они описывают качество работы системы, а не что именно она должна делать. Бизнес, пользовательские и функциональные требования говорят о функциях и задачах системы, а нефункциональные — о том, как эти задачи выполняются (например, скорость, безопасность, надежность). Они касаются всей системы в целом, а не отдельных функций.
Что входит в нефункциональные требования?
- Производительность — Время отклика, пропускная способность, время загрузки и масштабируемость.
- Масштабируемость — возможность системы работать при увеличении нагрузки.
- Надежность — устойчивость системы к сбоям и её способность восстанавливаться после них.
- Безопасность — защита данных и доступ к системе (например, шифрование, аутентификация).
- Юзабилити — удобство использования системы для пользователей.
- Совместимость — работа с другими системами, платформами или устройствами.
- Поддерживаемость — простота исправления и обновления системы.
- Мобильность — работа системы на разных устройствах, включая мобильные.
Что такое переходные требования (Transition Requirements) и в каких случаях они могут понадобиться?
Переходные требования описывают условия, которые должны быть учтены, а также все возможности нового решения, чтобы осуществить переход от текущего состояния системы (AS-IS) в целевое состояние (TO-BE)
Когда могут понадобиться:
- При переходе на новую систему с устаревшей.
- При внедрении новой версии программного обеспечения.
- При миграции данных с одной платформы на другую.
- При изменении бизнес-процессов, которые затрагивают системы.
Примеры:
- Миграция данных: Все данные из старой системы должны быть перенесены в новую в течение 48 часов без потери целостности.
- Обучение персонала: Все сотрудники должны пройти обучение по использованию новой системы до её официального запуска.
Приходилось ли вам писать Use cases? Как пишутся Use cases?
В процессе их написания я определяю актора, описываю основной успешный сценарий, включаю альтернативные потоки, предусловия и ожидаемые результаты.
Например, для процесса оформления заказа: покупатель добавляет товар в корзину, вводит данные для доставки и оплаты, и завершает заказ. Альтернативные сценарии описывают возможные ошибки, такие как отсутствие товара.
Приходилось ли вам писать User story? Как они формулируются?
Да, мне приходилось писать User stories. Это короткие описания требований к функциональности системы с точки зрения пользователя.
Формулируются они по шаблону: “Как [роль], я хочу [функция], чтобы [цель/выгода]”. Например: “Как пользователь, я хочу видеть историю своих заказов, чтобы быстро находить и повторять прошлые покупки.” Такой формат помогает четко понять, что нужно реализовать и зачем это нужно пользователю.
