Классификация требований к системе FURPS+ была разработана Робертом Грэйди (Robert Grady) из Hewlett-Packard и предложена в 1992 году. Сокращение FURPS расшифровывается так:
- Functionality, функциональность
- Usability, удобство использования
- Reliability, надежность
- Performance, производительность
- Supportability, поддерживаемость
- + необходимо помнить о таких возможных ограничениях, как:
- ограничения проектирования, design
- ограничения разработки, implementation
- ограничения на интерфейсы, interface
- физические ограничения, physical
Если применить к этой классификации популярное разделение требований на функциональные и нефункциональные, то к последним следует отнести все перечисленные выше группы кроме первой, т.е. URPS+.

Теперь давайте рассмотрим каждую группу требований подробнее.
F. Функциональные требования
Функциональные требования содержат основные свойства/функции системы. Однако не все они обязательно будут относиться к предметной области системы.
- Журналирование, аuditing — инструменты отслеживания действий пользователей и системы путем записи в журнал безопасности конкретных типов событий.
- Лицензирование, licensing — средства для отслеживания, приобретения, установки и контроля над использованием лицензий.
- Локализация, localization — средства поддержки различных естественных языков.
- Почта, mail — службы отправки и получения сообщений.
- Помощь, online help — возможность оказывать поддержку пользователей в реальном времени (например, «Необходима система online-помощи»).
- Печать, printing — средства для печати документов.
- Отчетность, reporting — инструменты создания и получения отчетов.
- Безопасность, security — средства защиты доступа к определенным ресурсам информации.
- Управление системой, system management — инструменты, позволяющие управлять приложениями в распределенной среде.
- Технологический процесс, workflow — поддержка документооборота, включая процессы проверки, визирования и утверждения.
U. Удобство использования
К удобству использования относятся следующие виды требований:
- эстетика и логичность пользовательского интерфейса,
- защита от человеческого фактора,
- эксплуатационная документация, ее состав (руководства пользователей, администраторов и др.), отраслевые и гос. стандарты оформления,
- квалификация пользователей и их обучение,
- справочная информация в системе.
R. Надежность
Надежности включает такие характеристики системы, как:
- сбои:
- допустимая частота/периодичность сбоев,
- среднее время сбоев и их серьезность,
- возможность восстановления системы после сбоев, в т.ч. возможность предварительного резервного копирования данных,
- предсказуемость поведения,
- время готовности системы к работе, режим работы или время доступности системы (например, «Система должна быть доступна 24 часа в сутки 7 дней в неделю»),
- точность вычислений.
P. Производительность
Производительность системы составляют следующие характеристики:
- скорость работы, время отклика системы,
- результативность/эффективность,
- пропускная способность, включая общее и допустимое количество одновременно работающих пользователей, количество пользовательских запросов, число обращений системы к БД и объем запрашиваемых/передаваемых данных в единицу времени,
- время, необходимое на восстановление — скорость восстановления (необходимо отличать эту характеристику P/производительности от характеристик R/надежности «возможность восстановления» и «время доступности»),
- время, необходимое для запуска и завершения работы — скорость запуска и завершения,
- потребление ресурсов.
S. Поддерживаемость
К поддержке относятся возможности:
- тестирования,
- расширения — наращивания дополнительного функционала системы,
- масштабирования — тиражирования, например, в филиалах/подразделениях организации,
- адаптации/приспособления к использованию в заданной среде, в т.ч. путем предварительной настройки,
- конфигурирования — оперативной, регулярной настройки, переопределения параметров,
- совместимости,
- сопровождения, поддержки работоспособности: исправление ошибок, обновление данных, частота архивации и резервного копирования,
- сервисного обслуживания и ремонта, их удобство,
- установки,
- локализации (например, «Продукт будет поддерживать несколько естественных языков»),
- портативность,
- соответствие международным стандартам.
+. Ограничения
Рассматриваемая классификация выделяет следующие 4 группы ограничений:
- Ограничения проектирования:
- ограничения на технологии (например, «Хранение необходимо реализовать с помощью реляционной БД»),
- процесс («RUP»),
- средства разработки («диаграммы должны создаваться в MS Visio, документация — в MS Word»),
- прочие.
- Ограничения реализации, разработки, построение, написания программного кода:
- стандарты разработки,
- стандарты качества ПО, в т.ч. кода,
- языки программирования (например, «Вся бизнес-логика должна быть реализована на языке Visual Basic»),
- средства разработки («В качестве СУБД должна быть использована Oracle 10g»),
- ресурсные ограничения,
- лицензионные ограничения,
- ограничения на техническое (аппаратное) обеспечение,
- прочие.
- Требования к интерфейсам — ограничения (например, на форматы, протоколы) накладываемые необходимостью взаимодействия с другими системами:
- форматы данных,
- протоколы взаимодействия,
- внешние системы,
- прочие.
- Физические ограничения, накладываемые на технические (аппаратные) средства и окружение системы:
- форма,
- размер,
- вес,
- температурный режим,
- влажность,
- ограничения на вибрацию,
- прочие.
При разработке системы могут накладываться и другие ограничения, в частности юридические:
- международные соглашения: единицы измерения, языки,
- авторское право,
- соглашения о лицензировании,
- законодательство,
- отраслевые стандарты.
Спасибо за структурированное описание требований к cистемам. Но как увязать классификацию FURPS+ с разработкой ТЗ по ГОСТ?