Notes

----------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------
Классификация бизнес-требований может быть выполнена по различным критериям, в зависимости от контекста и целей проекта. Вот основные категории, в которые можно классифицировать бизнес-требования:
1. По типу требований
Функциональные требования: Описывают конкретные функции и возможности, которые система должна предоставлять. Например, возможность регистрации пользователей, обработка платежей, генерация отчетов и т.д.
Нефункциональные требования: Описывают характеристики системы, которые не связаны напрямую с ее функциональностью, но важны для ее успешной работы. Это могут быть требования к производительности, безопасности, удобству использования, надежности и т.д. Например, система должна обрабатывать 1000 запросов в минуту или быть доступной 99,9% времени.
2. По уровню детализации
Высокоуровневые требования: Общие и абстрактные требования, которые описывают цели и задачи бизнеса. Например, "Увеличить продажи на 20% в следующем квартале".
Детализированные требования: Конкретные и четкие требования, которые описывают, как именно будут достигаться высокоуровневые цели. Например, "Добавить функцию онлайн-заказа на сайте".
3. По источнику требований
Внутренние требования: Требования, исходящие от внутренних заинтересованных сторон, таких как менеджеры, сотрудники и другие участники проекта. Например, требования отдела продаж о необходимости улучшения интерфейса.
Внешние требования: Требования, исходящие от внешних заинтересованных сторон, таких как клиенты, партнеры или регуляторы. Например, требования к соблюдению стандартов безопасности данных.
4. По времени реализации
Краткосрочные требования: Требования, которые должны быть реализованы в ближайшем будущем, например, в рамках текущего релиза или проекта.
Долгосрочные требования: Требования, которые могут быть реализованы в будущем, но важны для стратегического планирования. Например, требования к расширению функциональности системы через год.
5. По приоритету
Критические требования: Требования, которые являются обязательными для успешного выполнения проекта. Без их реализации проект не сможет достичь своих целей.
Второстепенные требования: Требования, которые важны, но не являются критическими. Их реализация может быть отложена на более поздний этап.
6. По области применения
Требования к продукту: Описывают, что должно быть реализовано в конечном продукте или услуге.
Требования к процессам: Описывают, как должны быть организованы бизнес-процессы для достижения целей. Например, требования к процессу обработки заказов.
Эта классификация помогает лучше организовать и управлять бизнес-требованиями, а также обеспечивает ясность и понимание среди всех участников проекта.
----------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------
Классификация бизнес-требований включает следующие виды:
Верхнеуровневые. Определяют смысл проекта, основной список задач и рамки проекта, обосновывают его необходимость. Обычно фиксируются в формате BRD (business requirements document) и BPMN (для описания процессов). 21
Функциональные требования. Описывают непосредственно функционал, который необходимо реализовать в продукте или системе. 1
Нефункциональные требования. Описывают, как должна работать система или программный продукт, и какими свойствами или характеристиками она должна обладать. К ним относятся требования к документированию, дизайну, атрибуты качества (производительность, эффективность, надёжность и другие), ограничения (юридические, бизнес-правила, архитектурные и т. п.). 1
----------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------
1. https://docs.ensi.tech/analyst-guides/tools/classification
2. https://practicum.yandex.ru/blog/biznes-trebovaniya/
3. https://stotis.sakhalin.gov.ru/upload/medialibrary/215/93d2xfb4xvm3w08mooscxugdcv3b2hzc.pdf
4. https://business-analytics-russia.ru/formation-requirements-and-classification-requirements/
----------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------
Классификация бизнес-требований включает следующие виды:
Верхнеуровневые. Определяют смысл проекта, основной список задач и рамки проекта, обосновывают его необходимость. Обычно фиксируются в формате BRD (business requirements document) и BPMN (для описания процессов). 21
Функциональные требования. Описывают непосредственно функционал, который необходимо реализовать в продукте или системе. 1
Нефункциональные требования. Описывают, как должна работать система или программный продукт, и какими свойствами или характеристиками она должна обладать. К ним относятся требования к документированию, дизайну, атрибуты качества (производительность, эффективность, надёжность и другие), ограничения (юридические, бизнес-правила, архитектурные и т. п.). 1
----------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------
https://en.wikipedia.org/wiki/Comparison_of_EDA_software
----------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------
Формат файла BRD используется в программном обеспечении автоматизации электронного проектирования (EDA) для проектирования печатных плат (PCB). 2
Программное обеспечение для проектирования печатных плат, такое как Eagle, KiCad, Altium Designer и другие, использует этот формат файлов для хранения макета, соединений и другой информации, связанной с проектированием печатной платы. 2
Файл BRD создаётся с помощью редактора макетов EAGLE, который является компонентом программного пакета Autodesk EAGLE. Этот редактор позволяет пользователям проектировать макет печатной платы, включая размещение компонентов, трассировку трасс, определение правил проектирования и создание необходимых файлов для производства. 2
Файлы BRD служат шаблонами или чертежами для проектирования электронных схем на печатной плате. 2
----------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------
Нравственность и права, право и государство.
----------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------
Функциональные требования (ФТ)
+Описывают непосредственно функционал, который необходимо реализовать в продукте или системе. Часто используемые артефакты:
1. для функционала: User Story, Use Case;
2. для описания бизнес-процессов: BPMN;
3. для описания состояний и взаимодействий между системами и состояний: различные UML диаграммы и DFD
4. для моделей данных: ERD и UML диаграмма классов;
5. для описания ролей: ролевая матрица, например, в формате CRUD.
Нефункциональные требования (НФТ)
+Описывают, как должна работать система или программный продукт, и какими свойствами или характеристиками она должна обладать.
1. Требования к документированию (BRD, ФЗ, сценарии тестирования и их результаты, пользовательские инструкции);
2. Требования к дизайну, usability (соответствие брендбукам, прототипам, удобство использования);
3. Атрибуты качества:
- производительность (возможное количество одновременных операций в системе);
- эффективность (использование доступных вычислительных мощностей);
- надёжность (вероятность отказа системы);
- доступность (режим работы системы без простоев);
- информационная безопасность (исключение доступности данных системы неавторизованным лицам);
- масштабируемость (способность системы адаптироваться к увеличению нагрузки);
- требования к времени хранения данных;
Ограничения (юридические, бизнес правила, архитектурные и т.п.).
----------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------
Вот шпаргалка с подсказками для каждого из пунктов, касающихся функциональных и нефункциональных требований:

### Функциональные требования (ФТ)
**Определение**: Описывают непосредственно функционал, который необходимо реализовать в продукте или системе.

#### Часто используемые артефакты:
1. **User Story**:
- **Подсказка**: Формат "Как [тип пользователя], я хочу [действие], чтобы [цель]". Помогает понять потребности пользователей и их мотивацию.
2. **Use Case**:
- **Подсказка**: Описывает взаимодействие между пользователем и системой. Включает основные и альтернативные сценарии, а также пред- и постусловия.
3. **BPMN (Business Process Model and Notation)**:
- **Подсказка**: Используется для визуализации бизнес-процессов. Обратите внимание на события, действия и потоки.
4. **UML диаграммы (например, диаграммы последовательностей, диаграммы состояний)**:
- **Подсказка**: Помогают описать взаимодействия между объектами и состояния системы. Используйте для визуализации логики работы системы.
5. **DFD (Data Flow Diagram)**:
- **Подсказка**: Отображает потоки данных между процессами и хранилищами данных. Убедитесь, что все потоки четко обозначены.
6. **ERD (Entity-Relationship Diagram)**:
- **Подсказка**: Используется для моделирования данных. Определите сущности, их атрибуты и связи между ними.
7. **UML диаграмма классов**:
- **Подсказка**: Определяет классы, их атрибуты и методы, а также отношения между классами.
8. **Ролевая матрица (CRUD)**:
- **Подсказка**: Определяет, какие роли имеют доступ к каким данным и действиям (Create, Read, Update, Delete). Помогает в управлении доступом.

--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---

### Нефункциональные требования (НФТ)
**Определение**: Описывают, как должна работать система или программный продукт, и какими свойствами или характеристиками она должна обладать.

#### Часто используемые артефакты:
1. **Требования к документированию**:
- **Подсказка**: Убедитесь, что все документы (BRD, ФЗ, сценарии тестирования) четко описаны и доступны. Включите результаты тестирования и пользовательские инструкции.
2. **Требования к дизайну и usability**:
- **Подсказка**: Проверьте соответствие брендбукам и прототипам. Оцените удобство использования через тестирование с пользователями.
3. **Атрибуты качества**:
- **Производительность**: Определите максимальное количество одновременных операций, которые система должна поддерживать.
- **Эффективность**: Оцените, как система использует доступные вычислительные ресурсы.
- **Надежность**: Установите допустимый уровень вероятности отказа системы.
- **Доступность**: Определите режим работы системы (например, 24/7) и допустимые простои.
- **Информационная безопасность**: Убедитесь, что данные защищены от неавторизованного доступа.
- **Масштабируемость**: Определите, как система будет адаптироваться к увеличению нагрузки (например, добавление серверов).
- **Требования к времени хранения данных**: Установите, как долго данные должны храниться и в каком формате.

4. **Ограничения**:
- **Подсказка**: Определите юридические, бизнес-правила и архитектурные ограничения, которые могут повлиять на проект. Убедитесь, что все ограничения документированы и учтены в процессе разработки.
Эта шпаргалка поможет вам быстро ориентироваться в функциональных и нефункциональных требованиях, а также в артефактах, которые могут быть использованы для их описания и реализации.