Читаем статью «What does it mean to say ‘requirement’?»

Статья «What does it mean to say ‘Requirement’?» («Что значит сказать ‘требование’?») от Kim Lauenroth опубликована в первом номере журнала RE Magazine, издаваемого IREB.

В статье автор разбирает понятие «требование» (requirement) и его соотношение с такими понятиями как проблема (problem) или цель (objective) и решение (solution).

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

Требования зависят от избранного решения

Он начинает с определения термина требование по IEEE 610.12:

  1. Условие или способность необходимая пользователю для достижения цели или решения задачи.
  2. Условие или способность, которому должна удовлетворять или которой обладать система или её компонента чтобы выполнять контракт, спецификацию или другой формальный документ.
  3. Представление условия или способности в 1 и 2 в виде документа.

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

Итого, получаем треугольник, включающий задачу, решение и требования. Независимой переменной здесь является только задача — с неё всё начинается. Решение очевидно зависит от задачи — это решение именно для этой задачи. Требования зависят и от задачи и от решения. Это может казаться странным, но требование зависит от конкретного выбранного решения, поскольку требование задаёт некоторые свойства этого решения, происходящие из первоначальной задачи!

Автор приводит в пример такую задачу:

Предупредить водителя в случае падения давления воздуха в шинах.

Возможное решение (А) состоит в том, чтобы установить в каждое колесо датчики давления и сравнивать измеряемое давление с пороговым значением. Тогда требования могут выглядеть так:

  • Датчик давления должен измерять давление в диапазоне 0..50 PSI с точностью x%.
  • Давление необходимо измерять каждые y секунд
  • Система должна выдавать предупреждение если давление падает ниже порога z.

Но если подумать ещё, можно найти другие решения задачи, например, такое:
Если давление уменьшается, то уменьшается и диаметр шины, что приводит к увеличению скорости её вращения. Если измерять эту скорость и сравнивать между разными колёсами, также можно найти колесо с пониженным давлением. Если выбрать это решение, то требования нужно переформулировать:

  • ESP должна постоянно измерять скорость вращения всех колёс
  • Погрешность измерений не должна превышать x%
  • Предупреждение должно выдаваться если скорость вращения одного колеса отклоняется от других более чем на y% в течение z секунд.

Мы видим, что при той же задаче набор требований сильно зависит от избранного решения.

Дилема задача-решение

То, что мы считаем задачей, легко может стать решением если сменить точку зрения. В примере выше задача была «Предупредить водителя в случае падения давления воздуха в шинах». Но если спросить «Зачем?», то можно найти задачу более высокого уровня, к примеру, «Уменьшить подтребление горючего». С точки зрения этой новой задачи, наша первоначальная задача оказывается лишь одним из возможных решений. Есть и другие способы уменьшить потребление горючего. И наоборот, решение можно превратить в задачу, задав вопрос «Как?». Как экономить горючее? — Следить за уровнем давления в шинах. Как следить за давлением? — Измерять скорость вращения колёс. Как измерять скорость вращения колёс? И т.д.  Каждое решение порождает новую задачу если взглянуть на него с точки зрения реализации, а каждая задача есть решение более высокоуровневой задачи.

Как выбраться из этой дилемы? Здесь нет «правильного» ответа. В каждом конкретном случае нужно индивидуально решить где остановиться из соображений полезности. Какая-то задача просто принимается за «корневую» задачу, к которой уже не задаётся вопрос «зачем?», а принимается как факт что её нужно решить.

Модель PAL

В конце статьи автор предлагает модель PAL — Problem-Abstraction-Layer, которая применяет рассуждения, приведенные выше, к конкретной инженерии требований. Эта модель включает в себя три уровня рассморения системы:

  • Контекст системы
  • Логическая система
  • Техническая система

Вся информация, поступающая из разговоров с заказчиком, раскладывается по этим трём уровням, а на каждом уровне выделяются задача, решение и требования.

Наверное, можно выделять более трёх уровней, но уже имея три, очень интересно увидеть что на каждом из них существую задачи, решения и связывающие их требования.

 

 

 

2 ответ. на "Читаем статью «What does it mean to say ‘requirement’?»"

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход /  Изменить )

Google photo

Для комментария используется ваша учётная запись Google. Выход /  Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход /  Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход /  Изменить )

Connecting to %s