Требования к системе: классификация FURPS+

Классификация требований к системе FURPS+ была разработана Робертом Грэйди (Robert Grady) из Hewlett-Packard и предложена в 1992 году. Сокращение FURPS расшифровывается так:

  1. Functionality, функциональность
  2. Usability, удобство использования
  3. Reliability, надежность
  4. Performance, производительность
  5. Supportability, поддерживаемость
  6. + необходимо помнить о таких возможных ограничениях, как:
    • ограничения проектирования, design
    • ограничения разработки, implementation
    • ограничения на интерфейсы, interface
    • физические ограничения, physical

Если применить к этой классификации популярное разделение требований на функциональные и нефункциональные, то к последним следует отнести все перечисленные выше группы кроме первой, т.е. URPS+.

Классификация требований FURPS+
Классификация требований FURPS+

Теперь давайте рассмотрим каждую группу требований подробнее.

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»),
    • ресурсные ограничения,
    • лицензионные ограничения,
    • ограничения на техническое (аппаратное) обеспечение,
    • прочие.
  • Требования к интерфейсам — ограничения (например, на форматы, протоколы) накладываемые необходимостью взаимодействия с другими системами:
    • форматы данных,
    • протоколы взаимодействия,
    • внешние системы,
    • прочие.
  • Физические ограничения, накладываемые на технические (аппаратные) средства и окружение системы:
    • форма,
    • размер,
    • вес,
    • температурный режим,
    • влажность,
    • ограничения на вибрацию,
    • прочие.

При разработке системы могут накладываться и другие ограничения, в частности юридические:

  • международные соглашения: единицы измерения, языки,
  • авторское право,
  • соглашения о лицензировании,
  • законодательство,
  • отраслевые стандарты.

Один комментарий

Оставить ответ