|
|
@@ -4,20 +4,20 @@
|
|
|
Все требования делятся на несколько ключевых категорий.
|
|
|
Функциональные требования описывают, какие именно задачи должна решать система: способы обработки данных, формирование отчётности, реализацию алгоритмов. Проще говоря, они отвечают на вопрос «что делает система?».
|
|
|
Нефункциональные требования определяют свойства и ограничения системы. Сюда входят:
|
|
|
-### • производительность (время отклика, пропускная способность);
|
|
|
-### • надёжность (бесперебойная работа, восстановление после сбоев);
|
|
|
-### • безопасность (защита от несанкционированного доступа, целостность данных).
|
|
|
+#### • производительность (время отклика, пропускная способность);
|
|
|
+#### • надёжность (бесперебойная работа, восстановление после сбоев);
|
|
|
+#### • безопасность (защита от несанкционированного доступа, целостность данных).
|
|
|
Эргономические требования и требования к интерфейсу — это удобство для конечного пользователя: интуитивная навигация, соответствие стандартам юзабилити, минимизация ошибок и сокращение времени на обучение.
|
|
|
Технические требования определяют программно-аппаратную платформу: характеристики серверов, рабочих станций, сетевого оборудования, совместимость с ОС и базами данных, а также масштабируемость (возможность расширяться при росте нагрузки).
|
|
|
Все собранные требования фиксируют в Техническом задании (ТЗ). Этот документ служит планом для разработчиков и инструментом контроля для заказчика.
|
|
|
## Процесс формирования требований
|
|
|
Формирование требований — это циклический многоступенчатый процесс, определяющий, что именно должна делать система и в каких условиях.
|
|
|
-### 1. Предварительное обследование — погружение в предметную область: интервью с руководством и сотрудниками, анкетирование, наблюдение, изучение документооборота и нормативно-правовой базы.
|
|
|
-### 2. Бизнес-требования — определение высокоуровневых целей: какую бизнес-проблему решает система и какую выгоду приносит (например, сокращение времени обработки заявок на 30%).
|
|
|
-### 3. Функциональные требования — описание конкретного поведения системы: какие данные принимает, как обрабатывает, какие отчёты формирует. Часто используют сценарии использования (Use Cases).
|
|
|
-### 4. Нефункциональные требования — уточнение системных ограничений: производительность, надёжность, безопасность, масштабируемость, удобство интерфейса.
|
|
|
-### 5. Документирование и моделирование — систематизация требований в ТЗ, построение ER-диаграмм и диаграмм потоков данных (DFD) для визуализации архитектуры.
|
|
|
-### 6. Проверка и утверждение — проверка требований на полноту, непротиворечивость и реализуемость. После согласования с заказчиком изменения вносятся только через официальную процедуру.
|
|
|
+#### 1. Предварительное обследование — погружение в предметную область: интервью с руководством и сотрудниками, анкетирование, наблюдение, изучение документооборота и нормативно-правовой базы.
|
|
|
+#### 2. Бизнес-требования — определение высокоуровневых целей: какую бизнес-проблему решает система и какую выгоду приносит (например, сокращение времени обработки заявок на 30%).
|
|
|
+#### 3. Функциональные требования — описание конкретного поведения системы: какие данные принимает, как обрабатывает, какие отчёты формирует. Часто используют сценарии использования (Use Cases).
|
|
|
+#### 4. Нефункциональные требования — уточнение системных ограничений: производительность, надёжность, безопасность, масштабируемость, удобство интерфейса.
|
|
|
+#### 5. Документирование и моделирование — систематизация требований в ТЗ, построение ER-диаграмм и диаграмм потоков данных (DFD) для визуализации архитектуры.
|
|
|
+#### 6. Проверка и утверждение — проверка требований на полноту, непротиворечивость и реализуемость. После согласования с заказчиком изменения вносятся только через официальную процедуру.
|
|
|
Значение требований для успешной реализации АИС
|
|
|
• Минимизация рисков и затрат — чёткие требования позволяют обнаружить ошибки на ранних стадиях, когда их исправление стоит дёшево, и предотвращают переделки готовых модулей.
|
|
|
• Основа для планирования — на базе требований рассчитывают бюджет, сроки и ресурсы, избегая хаотичного расширения проекта.
|
