Классификация требований к системе 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+ с разработкой ТЗ по ГОСТ?