Определение требований к разработке

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

С. Орлик, известный российский специалист по программной инженерии, приводит следующую классификацию требований к программному обеспечению:

• Потребности отражают проблемы бизнеса, персоналии или процесса, которые должны быть соотнесены с использованием или приобретением системы.
• Группа функциональных требований определяет набор задач, которые система должна выполнять. Часто функциональные требования представляют в виде сценариев использования (Use Cases).
  • Бизнес-требования – определяют высокоуровневые цели организации или клиента (потребителя) – заказчика разрабатываемого программного обеспечения.
  • Пользовательские требования – описывают цели/задачи пользователей системы, которые должны достигаться/выполняться пользователями при помощи создаваемой программной системы. Эти требования часто представляют в виде вариантов использования (Use Cases).
  • Функциональные требования (как таковые) – определяют функциональность (поведение) программной системы, которая должна быть создана разработчиками для предоставления возможности выполнения пользователями своих обязанностей в рамках бизнес-требований и в контексте пользовательских требований.
• Группа нефункциональных требований задает условия, в которых система должна функционировать (например, время отклика при максимальной расчетной нагрузке).
  • Бизнес-правила – включают или связаны с корпоративными регламентами, политиками, стандартами, законодательными актами, внутрикорпоративными инициативами, учетными практиками, алгоритмами вычислений и т.д. Они подразумевают организацию структуры бизнеса, контролируют или влияют на поведение бизнеса. Бизнес-правила часто определяют распределение ответственности в системе, отвечая на вопрос «кто будет осуществлять конкретный сценарий использования» или диктуют появление некоторых функциональных требований.
  • Внешние интерфейсы – часто подменяются «пользовательским интерфейсом». На самом деле вопросы организации пользовательского интерфейса безусловно важны в данной категории требований, однако, конкретизация аспектов взаимодействия с другими системами, операционной средой (например, запись в журнал событий операционной системы), возможностями мониторинга при эксплуатации – все это не столько функциональные требования (к которым ошибочно приписывают иногда такие характеристики), сколько вопросы интерфейсов, так как функциональные требования связаны непосредственно с функциональностью системы, направленной на решение бизнес-потребностей.
  • Атрибуты качества – описывают дополнительные характеристики продукта в различных “измерениях”, важных для пользователей и/или разработчиков. Атрибуты касаются вопросов портируемости, интероперабельности (прозрачности взаимодействия с другими системами), целостности, устойчивости и т.п.
  • Ограничения – формулировки условий, модифицирующих требования или наборы требований, сужая выбор возможных решений по их реализации. В частности, к ним могут относиться параметры производительности, влияющие на выбор платформы реализации и/или развертывания (протоколы, серверы приложений, баз данных и т.п.), которые, в свою очередь, могут относиться, например, к внешним интерфейсам.
• Системные требования иногда классифицируются как составная часть группы функциональных требований. Описывают высокоуровневые требования к программному обеспечению, содержащему несколько или много взаимосвязанных подсистем и приложений. При этом, система может быть как целиком программной, так и состоять из программной и аппаратной частей. В общем случае, частью системы может быть персонал, выполняющий определенные функции системы, например, авторизация выполнения определенных операций с использованием программно-аппаратных подсистем.

Простой пример

Вместе со студентами сформулировать набор требований к программе «Калькулятор» (рис. 1).

Рис. 1. Калькулятор KCalc, как пример, иллюстрирующий недоработки в пользовательском интерфейсе

CC-BY-CA Анатольев А.Г., 15.10.2014