Типы требований

Все темы Systems Analyst

Какие группы требований вы знаете?

В процессе разработки программного обеспечения и систем встречаются различные группы требований:

1. Функциональные требования: Описывают функции, сервисы или задачи, которые система должна выполнять. Например, функции пользовательского интерфейса или бизнес-процессы.

2. Нефункциональные требования: Определяют атрибуты качества системы, такие как производительность, надежность, безопасность, масштабируемость и удобство использования.

3. Бизнес-требования: Связаны с бизнес-процессами и целями организации, включая требования к бюджету, времени и ресурсам.

4. Требования к интерфейсам: Определяют способы взаимодействия пользователя с системой, включая требования к пользовательскому интерфейсу, API и внешним системам.

5. Требования к данным: описывают структуру, хранение, доступ и управление данными системы.

6. Требования к производительности: Определяют требования к скорости работы системы, времени отклика и загрузке.

7. Законодательные и стандартные требования: Включают требования, которые система должна соблюдать в соответствии с законодательством или стандартами отрасли.

Что входит в нефункциональные требования?

Нефункциональные требования определяют атрибуты качества системы, которые не связаны непосредственно с её функциональностью, а определяют её общие характеристики, производительность и способность удовлетворять потребности пользователей. Они включают:

1. Производительность: Требования к времени отклика, скорости обработки данных или пропускной способности системы.

2. Надежность: Ожидаемое время безотказной работы системы, степень устойчивости к сбоям и восстановление после сбоев.

3. Безопасность: Требования к защите данных, аутентификации пользователей, контролю доступа и защите от угроз.

4. Удобство использования ( Usability ): Требования к интерфейсу пользователя, уровню обучаемости, удобству навигации и общей доступности.

5. Масштабируемость: Способность системы масштабироваться для поддержки увеличения объёма данных или пользовательской нагрузки.

6. Совместимость: Требования к совместимости с другими системами, программным и аппаратным обеспечением.

7. Модифицируемость и расширяемость: Способность системы быть легко модифицированной и расширяемой для внесения изменений и добавления новой функциональности.

Нефункциональные требования помогают определить общую эффективность и пригодность системы для решения бизнес-задач, а также её способность соответствовать ожиданиям пользователей и стандартам отрасли.

Как вы будете различать функциональные и нефункциональные требования?

Функциональные и нефункциональные требования различаются по своей сути и тому, на какие аспекты системы они ориентированы:

1. Функциональные требования:

   • Определяют конкретные функции и задачи, которые система должна выполнять.

   • Описывают, что система должна делать относительно входных данных.

   • Часто выражаются через действия, которые пользователь или другие системы могут выполнить с помощью системы.

   • Примеры: «Система должна позволять пользователям создавать новые аккаунты», «Система должна автоматически отправлять уведомления о новых сообщениях».

2. Нефункциональные требования:

   • Определяют качественные атрибуты или ограничения, которые должны характеризовать систему.

   • Описывают атрибуты, такие как производительность, безопасность, надежность и удобство использования.

   • Часто описываются как ограничения или качественные характеристики, которые не связаны напрямую с конкретными функциями системы.

   • Примеры: «Система должна обрабатывать запросы пользователей в течение 2 секунд», «Доступ к административной части системы должен быть защищен паролем и двухфакторной аутентификацией».

Какие требования собирает и анализирует системный аналитик?

Системный аналитик должен собирать и анализировать различные типы требований для успешной разработки информационной системы. Эти требования могут включать:

1. Функциональные требования: Определяют конкретные функции и задачи, которые система должна выполнять.

2. Нефункциональные требования: Определяют качественные атрибуты и ограничения системы, такие как производительность, безопасность и удобство использования.

3. Бизнес-требования: Отражают бизнес-цели и ожидания от системы, выраженные на языке бизнеса.

4. Требования к пользовательскому интерфейсу: Определяют способы взаимодействия пользователей с системой.

5. Требования к интеграции и интерфейсам: Определяют, как система должна взаимодействовать с другими системами или компонентами.

6. Требования к безопасности и доступу: Определяют требования к защите данных и контролю доступа к системе.

7. Требования к производительности: Определяют ограничения и требования к времени отклика и обработки данных системы.

8. Требования к поддержке и обслуживанию: Определяют требования к технической поддержке, документации и обновлениям системы.

Анализ требований включает в себя их детализацию, уточнение и документирование, чтобы обеспечить полное понимание всех сторон разработки и внедрения информационной системы.

Как сформулировать измеримое нефункциональное требование?

Измеримое NFR содержит объект измерения, метрику, порог, условия и допустимую долю нарушений. Например: «При профиле 300 запросов в секунду и 50 одновременных пользователях 99-й перцентиль времени ответа операции оплаты не превышает 800 мс в течение 30 минут, доля 5xx меньше 0,1%». Нужно зафиксировать среду, размер данных, географию или канал, период и инструмент измерения. Среднее значение обычно скрывает редкие медленные ответы. Формулировка должна давать одинаковый результат проверки разным командам и связываться с пользовательским или бизнес-риском.

Когда нужны переходные требования?

Переходные требования нужны для временного состояния между старой и целевой системой. Они описывают миграцию и проверку данных, обучение пользователей, параллельную эксплуатацию, обратную совместимость, переключение трафика, откат и поддержку старых процессов. У каждого требования должен быть владелец, срок действия, условие включения и измеримый критерий завершения. Например, старую систему отключают только после сверки контрольных сумм, успешной работы нового контура заданный период и закрытия критичных ошибок. Такие требования удаляют после перехода, поэтому их не следует смешивать с постоянными функциями продукта.