Определение нефункциональных требований

17.01.2010 10:36

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

 

Принято разделять нефункциональные требования (или атрибуты качества) на две большие категории, соответствующие структурным и поведенческим аспектам приложения. Первая категория (runtime) содержит атрибуты, имеющие значение при исполнении приложения, то есть в режиме его работы. Вторая категория (designtime) определяет атрибуты, относящиеся к аспектам проектирования приложения. Далее мы приведем таблицу основных критериев качества, которые вам необходимо учитывать при описании или проектировании архитектуры.

 

Атрибуты качества в runtime

Название атрибутаОписание

Availability

Доступность - требования ко времени непрерывной работы приложения, например, 24x7, минимальное время простоя и т.п.

Reliability

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

Durability

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

Scalability

Масштабируемость - требования к горизонтальному или вертикальному масштабированию приложения

Usability

Требования к удобству использования приложения с точки зрения использования, поддержки

Security

Требования к безопасности работы или использования приложения, связанные с разграничением доступа, работой с приватными данным, снижения подверженности рискам от внешних атак

Configurability

Требования к конфигурируемости работы приложения, взаимодействия и расположения компонентов

Performance

Требования к производительности решения, количество одновременно работающих пользователей, обслуживаемых транзакций, времени реакции, продолжительности вычислений, скорости и пропускной способности каналов связи

Restrictions

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

Атрибуты качества в design time

Название атрибутаОписание

Reusability

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

Extensibility

Требования к расширяемости приложения в связи с появлением новых функциональных требований

Portability

Требования к портируемости (переносимости) приложения на различные платформы

Interoperability

Требования к взаимодействию между компонентами решения, между внешними компонентами, использование стандартных протоколов и технологий взаимодействия

Supportability

Требования к различным аспектам поддержки приложения, таким как дешевизна и скорость разработки, прозрачность поведения приложения, простота анализа ошибок и проблем в работе

Modularity

Требования к разделению приложения на модули

Testability

Требования к возможности автоматического и ручного тестирования приложения, наличие необходимого инструментария

Localizability

Требования к возможности и простоте локализации приложения, перечень языков, на которые предполагается локализация приложения

Compatibility

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

 

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

Еще интересные статьи на эту тему: