Подходы к управлению требованиями в IBM OpenUP и FURPS+

Страница разрабатывается

Contents

Описание методологии

Инфраструктура разработки программного обеспечения, которая строится на методах гибкой разработки с использованием унифицированного процесса Rational (Rational Unified Process). OpenUP — это экономичный унифицированный процесс, использующий принципы итеративности и инкрементальности в рамках структурированного жизненного цикла.

FURPS — классификация требований к программным системам. Требования были разработаны и представлены Hewlett-Packard. В настоящее время используется аббревиатура FURPS+.

Описание типов требований

Уровни требований

Три уровня требований:
1. Уровень концепции
Модель бизнес-процесса
Потребности заинтересованных лиц
Словарь предметной области
Бизнес-правила (ограничения)

2. Уровень пользователя
Функции системы
Варианты использования
Нефункциональные требования

3. Уровень системы
Эскизы интерфейса пользователя
Раскадровка

Требования в модели FURPS+

Модель «FURPS+» — функциональные, нефункциональные и вспомогательные требования:

Функциональные требования
— Функции системы
— Требования по аудиту системы
Есть ли необходимость в том, чтобы отслеживать, кто, когда и как использует систему?
— Требования по лицензированию
Будет ли система или её части лицензироваться? Если в системе будет использоваться
открытое ПО, то все ли соглашения могут быть соблюдены?
— Требования к функции печати
Будет ли доступна функция печати?
— Требования к отчетности
— Требуется ли функция генерации отчётов?
— Требования по безопасности
Будет ли контролироваться вход в систему? — аутентификация пользователей
Требуется ли защита системы или ее данных?

Нефункциональные требования
— Требования удобства использования
— Требования надежности
— Требования производительности

— Требования по обеспечению технической поддержкой
— Ограничения

Вспомогательные требования

Модель FURPS+ (Robert Grady at Hewlett-Packard):
— Функциональные требования (Functionality)
— Требования удобства использования (Usability)
— Требования надежности (Reliability)
— Требования производительности (Performance)
— Требования возможности сопровождения (Supportability)

Символом «+» обозначены дополнительные условия, к которым относятся:
— проектные ограничения
— требования управления системой
— требования к графическому интерфейсу пользователя
— физические требования
— юридические требования

Дополнительные требования:
— Требования к лицензированию
— Требования к документированию

Architect’s Checklist: A Guide to FURPS+

Functionality

  • The value added purpose of the product. Also…
  • Connectivity – protocols (e.g. Bluetooth), or re-sync of offline clients
  • Interoperability – inter-app platform and language independence
  • Extensibility, Expandability – plugins, late binding
  • Composability – service or message oriented considerations, governance
  • Manageability – administration of fielded product
  • Licensing

Usability

  • Ergonomics – human factors engineering
  • Look and Feel – along with branding instancing
  • Accessibility – special needs accommodation
  • Localization — adding language resources
  • Documentation

Reliability

  • Accuracy – the correctness of output
  • Availability – mean time between failures
  • Recoverability – from partial system failures
  • Verifiability – (contractual) runtime reporting on system health
  • Survivability – continuous operations through disasters (earthquake, war, etc.)

Performance

  • Efficiency – of space (bandwidth, RAM, etc)
  • Responsiveness – time constraints
  • Scalability – well handling under increased load
  • Speed — Throughput. Latency.

Supportability:

  • Maintainability (i.e. “build-time” issues)
  • Testability – at unit, integration, and system levels
  • Buildability – fast build times, versioning robustness
  • Portability – minimal vendor or platform dependency
  • Reusability – of components
  • Brandability — OEM and partner support
  • Internationalization – prep for localization

Serviceability (i.e. “run-time” issues)

  • Continuity – administrative downtime constraints
  • Configurability/Modifiability – of fielded product
  • Installability, Updateability – ensuring application integrity
  • Deployability – mode of distributing updates
  • Restorability — from archives
  • Logging – of event or debug data

Security: Confidentiality Preservation, Access Control, Non-repudiation (Integrity Verification, Authenticity Verification – PKI), Identity Verification (logon paradigm), Availability of Service, Auditing Evidence.

Методы сбора требований

  • Мозговой штурм
  • Интервьюирование пользователей
  • Погружение в среду пользователя
  • Изучение аналогов
  • Изучение «книги жалоб и предложений»
  • Разговор с командой поддержки
  • Изучение усовершенствований, сделанных пользователями
  • Совместный семинар
  • Демонстрация прототипа заинтересованным лицам
4 2 Голоса
Рейтинг статьи
Posted in Обзор всех методик работы с требованиями.
Подписаться
Уведомление о
guest

0 комментариев
Встроенные Обратные Связи
Просмотр всех комментариев