Оценка стоимости системы по ТЗ на английском языке

M. Walker. Count the Shalls

Перевод: Мадорская Ю.М.
переведено и опубликовано с разрешения автора

«Считайте шелы!»  — это было одно из самых странных введений в «управление требованиями», которое я когда-либо слышал. Во-первых, как молодой инженер я не знал, что такое «shall», не говоря уже о том, почему я должен это считать.

Для тех, кто читая это думает «о чем это он», позвольте объяснить. Грубый метод определения размера проекта заключался в том, чтобы посчитать количество параграфов, содержащих слово «Shall». Это давало количество обязательных законтрактованных требований, которые должны быть реализованы в проекте. Параграфы, содержащие «should» или «may» могли игнорироваться, т.к. это были скорее пожелания, чем обязательства.

Ограничения

В этом подходе, конечно, есть некоторая логика, особенно если требования написаны атомарно, однако никогда не следует предполагать, что клиент написал требования на том уровне, на котором действительно можно считать «шелы». Например, эти два множества требований клиента сильно отличаются:

  1. Транспортное средство должно перевозить груз 500 кг
  2. Транспортное средство должно соответствовать требованиям законодательства для использования на дорогах Великобритании.

Или

  1. Изоляция труб должна быть длиной 1 м.
  2. Изоляция должна устанавливаться стандартными инструментами DIY, такими как ремесленный нож и завязки, и не требовать специального оборудования.
  3. Изоляция должна иметь теплопроводность 0,033 Вт / мК или ниже.
  4. Изоляция должна пройти BS EN11925-2 BL
  5. Ни один из компонентов не должен классифицироваться как опасный для здоровья в соответствии с правилами COSHH 2002
  6. Оптовая цена должна быть 20р / м или ниже

После подсчета «shall» первый проект кажется гораздо проще – всего два требования. Но серьезно, примите ли вы такой уровень требований для оценки стоимости проекта и насколько счастлив будет ваш клиент в результате?

– Возьмите Форд транзит, работа сделана, да?

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

В отличие от первого второй проект имеет SMART-требования:

  • S pecific — конкретные
  • M easurable — измеряемые
  • A ttainable — достижимые
  • ealisable — реализуемые
  • T raceable — трассируемые

Вы можете подсчитать shall в этом проекте и получите более осмысленную оценку.

Shoulds and Mays

Можете ли вы игнорировать «shoulds» и «mays»? По контракту можно утверждать, что они не имеют значения, но для создания значимых отношений с клиентом они также важны. Конечно, требование «Изоляция может быть приглушенного цвета» может быть реализовано как ярко красная пена, но вряд ли вы тогда получите повторный заказ.

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

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

Решения

Безусловно, есть выгода в том, чтобы «считать шелы». Если в вашем проекте 1678 требований и 1698 «shalls», очевидо, что некоторые требования не являются атомарными. Используя, например, Cradle Conformance Checker вы можете проверить семантику всего множества требований. Однако, что автоматизированные инструменты не могут делать, так это оценить логику и сложность требования. В этом случае декомпозиция требований вашего заказчика на ряд  предметных системных требований гарантирует, что  требования, относительно которых вы ведете расчет стоимости, проектирование и разработку, действительно отсмартованы.

Хотите сослаться на эту статью? Используйте правильную ссылку:

Волкер М. Подсчет требований в ТЗ на английском языке?//Практика проектирования систем.-2019. [электронный ресурс] — Режим доступа: http://reqcenter.pro/count-the-shalls/, свободный. — Загл. с экрана