| № | Этап | Исполнители | На входе | На выходе |
|---|---|---|---|---|
| 1 | Определение ценностей и потребностей |
|
|
|
| 2 | Сбор и формирование требований |
|
|
|
| 3 | Проектирование (архитектура, требования) |
|
|
|
| 4 | Разработка |
|
|
Сборки приложения. |
| 5 | Тестирования |
|
|
Приложение, удовлетворяющее требованиям, без критических ошибок и готовое к эксплуатации |
| 6 | Развёртывание |
|
|
Развёрнутое на мощностях приложение, готовое к эксплуатации |
| 7 | Эксплуатация, поддержка и развитие |
|
|
Сборки приложения. |
| 8 | Вывод из эксплуатации |
|
|
void |
Требование (requirement) = утверждение (statement), которое выражает нужды (needs) и связанные с ними обстоятельства (conditions) и ограничения (constraints).
Требование это описание того, какие функции и с соблюдением каких условий должно выполнять приложение в процессе решения полезной для пользователя задачи.
Бизнес-требования (business requirements) выражают цель, ради которой разрабатывается Продукт/Услуга (зачем вообще нужен, какая от него ожидается польза, как заказчик с его помощью будет получать прибыль).
| Код цели | Приоритет | Цель |
|---|---|---|
| П.Ц.01 | 1 | Обеспечение ... |
| П.Ц.02 | 2 | Реализация ... |
| П.Ц.03 | 1 | Мониторинг ... |
| Код БТ | Код цели, покрываемой требованием | Приоритет | Бизнес-требование |
|---|---|---|---|
| П.БТ.01 | СП.Ц.01 | 1 | Приложение должно давать возможность ... |
Стейкхолдеры (stakeholders, заинтересованная сторона, причастная сторона) = физическое лицо или организация, имеющая права, долю, требования или интересы относительно системы/проекта/продукта или её свойств, удовлетворяющих их потребностям и ожиданиям ( ISO/IEC 15288:2015, ISO/IEC 29148:2018).
Иными словами, это те, кто оказывает воздействие (affects) на Систему/Проект/Продукт/Услугу либо подвергается воздействию Системы (affected by) каким-либо образом.
| № | Роль | Исполнитель | Комментарий |
|---|---|---|---|
| № | .. | .. | .. |
Use case = последовательность действий в диалоге между Актором и Компонентом/Системой с получением значимого результата, где Актором может быть пользователь или что-то, что может обмениваться информацией с Системой.
| UC | БТ |
|---|---|
| П.UC.01 | П.БТ.01 |
| П.UC.01.02 | П.БТ.02 |
| П.БТ.03 | |
| П.БТ.04 | |
| П.UC.04 | П.БТ.05 |
| Use case | Клиент сервиса | Поток событий | Комментарий |
|---|---|---|---|
| .. | .. | .. | .. |
Ограничения (limitations, constraints) представляют собой факторы, ограничивающие выбор способов и средств (в том числе инструментов) реализации продукта.
| Код | Связь с БТ | Приоритет | Ограничение / зависимость |
|---|---|---|---|
| П.ОГ.01 | П.БТ.09 | 1 |
Средствами devops должны быть:
1. ... |
Функциональные требования (functional requirements) описывают поведение системы, т.е. её действия (вычисления, преобразования, проверки, обработку и т.д.) В контексте проектирования функциональные требования в основном влияют на дизайн системы. Стоит помнить, что к поведению системы относится не только то, что система должна делать, но и то, что она не должна делать (например: "приложение не должно выгружать из оперативной памяти фоновые документы в течение 30 минут с момента выполнения с ними последней операции").
| Код ФТ | Код покрываемого UC | Приоритет | Критерии | Функциональное требования |
|---|---|---|---|---|
| П.ФТ.01 | П.UC.04 | 1 | compliance | В случае проведения таких-то операций — подключён контроль по ... |
Требования к данным (data requirements) описывают структуры данных (и сами данные), являющиеся неотъемлемой частью разрабатываемой системы. Часто сюда относят описание базы данных и особенностей её использования.
Требования к внешним интерфейсам (external interfaces requirements) описывают особенности взаимодействия разрабатываемой системы с другими системами и операционной средой.