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

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

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

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

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