Функциональные требования описывают поведение (функции или службу) системы, которое отвечает нуждам пользователей [MAL2001].

Хотя многие функциональные требования занесены в варианты использования, некоторые из них нельзя отнести к отдельным вариантам использования.  Такие функциональные требования касаются отчетов, контроля, печати, безопасности, лицензирования, идентификации и т.д.  Их следует занести в  дополнительную спецификацию.   

При наличии большого количества функциональных требований, касающихся системы в целом, необходимо уделить достаточно внимания их фиксации.  Обычно их объединяют по функциям или наборам функций, но можно использовать и другие критерии.  Например, их можно группировать по пользователям или подсистемам.

В сокращении "FURPS+" функциональные требования представляют букву "F".  Дополнительная информация о сокращении "FURPS+" приведена в разделе Концепция: Требования.

Нефункциональные требования включают качества и ограничения [MAL2001]. В этом шаге рассмотрены качества.  Ограничения описаны в отдельном шаге.

[Системные] качества - это свойства или характеристики системы, необходимые заинтересованным лицам для работы с системой, и определяющие уровень ожидаемого удобства работы с системой. [MAL2001]

В сокращении "FURPS+" качества представляют сочетание букв "URPS".  Ниже перечислены критерии требований этих категорий:

• Удобство использования Удобство и слаженность работы пользовательского интерфейса.
• Надежность  Доступность (объем доступного "машинного времени" системы), точность системных вычислений и способность системы восстанавливаться после сбоев.
• Производительность: производительность, время ответа, время восстановления, время запуска и время завершения работы.
• Удобство в обслуживании: возможность тестирования, адаптации, настройки, установки, обновления и локализации продукта, а также его совместимость и расширяемость.

Дополнительная информация о "FURPS+", а также о фиксации нефункциональных требований приведена в разделе Концепция: Требования.

В зависимости от числа качеств системы можно создать подразделы для каждого типа качеств.

В следующих разделах приведены примеры данных, которые можно использовать для каждого из этих качеств:

Удобство использования

В описании требований к удобству использования можно указать следующую информацию:

• Время, необходимое для обучения рядовых и опытных пользователей эффективному выполнению некоторых операций
• Временные рамки для типичных задач
• Требования соответствия принятым стандартам, например, спецификациям CUA, разработанным компанией IBM, или требованиям к графическим интерфейсам, разработанным компанией Microsoft

Надежность

В описании требований к надежности можно указать следующую информацию:

• Доступность - укажите объем доступного времени в процентах (xx.xx%), часах работы, время доступа для обслуживания, время работы в режиме с сокращенным набором ресурсов и т.д.
• Средняя продолжительность бесперебойной работы - обычно указывается в часах, но может измеряться и в днях, месяцах или годах.
• Среднее время восстановления работоспособности системы - отрезок времени, когда система не работает после сбоя.
• Точность – укажите уровень детализации и точности (в соответствии с известным стандартом) выходных данных.
• Максимальное количество неполадок или уровень неисправности системы - обычно выражается в количестве неполадок на тысячу строк кода или на число реализуемых функций.
• Количество неполадок или уровень неисправности системы - классификация неполадок на незначительные, умеренные и критические: в требованиях должно быть указано, что значит "критическая" неполадка. Например, полная потеря данных или полный отказ части системы.

Производительность

В описании требований к производительности можно указать следующую информацию:

• Время ответа операции (среднее, максимальное значение)
• Производительность (количество операций в секунду)
• Возможности системы (например, количество пользователей, которые могут работать с системой, или количество операций, которые система может выполнить)
• Режимы работы системы с сокращенным набором ресурсов (приемлемый режим работы при сокращенных ресурсах)
• Использование ресурсов: память, диск, соединение и т.д.

При фиксации требований к производительности обязательно включите требуемое время ответа для разных операций. При необходимости укажите ссылку на имя соответствующего варианта использования.

Удобство в обслуживании

В описании требований к удобству обслуживания можно указать следующую информацию:

• Стандарты кодирования
• Соглашения об именах
• Библиотеки классов
• Доступ для обслуживания
• Функции обслуживания

На этом шаге необходимо определить и зафиксировать ограничения для будущей системы. В общем случае ограничение - это сужение рамок свободы при выборе решения [LEF2000].  Ограничения к проектированию - это заранее принятые решения, которые нужно обязательно выполнять.  

В сокращении "FURPS+" ограничения представляют "+". Их можно разделить на следующие категории:

• Ограничения к проектированию: Предписывают или ограничивают варианты создания архитектуры и/или проекта системы. Например, требование использовать  реляционную базу данных для хранения информации.
• Ограничения к реализации: Предписывают или ограничивают варианты кодирования или построения системы. Например, требования придерживаться определенных стандартов, ограничений ресурсов (объем памяти или диска), следовать указанным процессам, использовать указанные инструменты, языки реализации, аппаратные платформы, операционные системы, компоненты других производителей, библиотеки классов.
• Ограничения к интерфейсам: Определяют внешний элемент, с которым должна взаимодействовать система, или ограничивают форматы или другие аспекты такого взаимодействия.  Например, установление связи с внешней системой с помощью очереди сообщений.
• Физические ограничения: Налагают физические ограничения на аппаратное обеспечение системы, например, форма, размер или вес.

В зависимости от числа ограничений системы можно создать подкатегории для каждого типа ограничений. Кроме того:

• Если требования включают покупку компонентов других компаний, зафиксируйте все ограничения, связанные с лицензированием или использованием, а также все стандарты, касающиеся совместимости или интерфейсов. Данные о компонентах других компаний рекомендуется заносить в отдельный раздел.
• Если требования касаются интерфейсов, рекомендуется создать отдельные разделы для разных типов интерфейсов (например, пользовательские, аппаратные и программные). Для каждого интерфейса обязательно включите описание его характеристик, протоколов, портов, логические адреса и другую информацию, чтобы можно было учесть требования интерфейсов при разработке программного обеспечения. Например:
  • Для пользовательских интерфейсов: добавьте описание тех интерфейсов, которые будут реализованы в программном обеспечении.
  • Для аппаратных интерфейсов: добавьте описание логической структуры, ожидаемого поведения, физические адреса и другую информацию.
  • Для программных интерфейсов: добавьте описание этих интерфейсов в другие компоненты системы. Это могут быть компоненты других компаний, повторно используемые компоненты других приложений или компоненты, разрабатываемые для системы за ее рамками, но с которыми данное приложение должно взаимодействовать.

Дополнительная информация о "FURPS+", а также о фиксации ограничений приведена в разделе Концепция: Требования.

По соответствием понимается соответствие стандартам (включая регулятивные нормы, стандарты кодирования или руководства по стилям интерфейсов), а также заявлениям об ограничении ответственности, гарантиям, авторским правам, патентам, графическим изображениям названий компаний, товарным знакам и/или логотипам.

Требования соответствия можно реализовать в виде других требований (функциональных, нефункциональных требований и ограничений).  В таких случаях подробности этих требований нужно занести в соответствующие разделы дополнительной спецификации, как описано в предыдущих шагах.  Важно подвести итог стандартам и стратегиям, которых должна придерживаться система.  Сформулированные таким образом требования соответствия можно связать с другими подробными применимыми требованиями.

В зависимости от числа требований соответствия можно для каждого типа таких требований создать отдельные подразделы.

В следующих разделах приведены примеры данных, которые можно использовать для каждого из этих типов соответствия:

Требования к лицензированию

Определите все требования к лицензированию программного обеспечения или другие требования, ограничивающие права использования компонентов.

Правовые документы, авторские права и т.д.

Добавьте информацию о соответствии любым заявлениям об ограничении ответственности, гарантиям, авторским правам, патентам, графическим изображениям названий компаний, товарным знакам или логотипам.

Применимые стандарты

Опишите (указав ссылки) любые применимые стандарты и их подробности, которым должна соответствовать система. Это могут быть правовые и регулятивные нормы, стандарты качества, отраслевые стандарты удобства использования, стандарты совместимости (например, касающиеся операционных систем), стандарты интернационализации и т.д.

На этом шаге опишите требования к документации, если они существуют. Они могут включать требования к электронной справке или к документации для конечных пользователей (например, к руководствам по установке, руководствам пользователя, обучающим материалам).  

Как и требования соответствия, требования к документации являются основой для требований других видов.  Прежде всего это относится к функциональным требованиям (система должна предоставлять доступ к электронной справке), а также к требованиям к удобству использования (доступ к информации по использованию системы определяет общий уровень удобства работы с системой).  

Также, как и требования соответствия, подробные требования к документации необходимо занести в соответствующие разделы дополнительной спецификации, как указано в предыдущих шагах. Не менее важно подвести общий итог требованиям к документации системы и зафиксировать их. Сформулированные таким образом требования соответствия можно связать с другими подробными применимыми требованиями.

В зависимости от числа требований к документации можно для каждого типа таких требования создать отдельные подразделы.