7. Свойства, правила и атрибуты для формулировок требований согласно iso/iec/ieee 29148. [Условие] [Субъект] [Действие] [Объект] [Ограничение]

ПРИМЕР: Когда сигнал х получен [Условие], система [Субъект] должна установить [Действие] разряд x сигнала [Объект] в течение двух секунд [Ограничение].

или

[Условие] [Действие или Ограничение] [Значение]

ПРИМЕР: В состоянии моря 1 [Условие], Радиолокационная система должна определить цели в радиусе [Действие или Ограничение] 100 морских миль [Значение].

или

[Субъект] [Действие] [Значение]

ПРИМЕР: Система выставления счетов [Субъект], должна выводить клиентские счета, находящиеся на рассмотрении [Действие] по возрастанию, в порядке, [Значение] в котором счета должны быть выплачены.

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

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

К примерам ограничений относятся:

• интерфейсы уже существующих систем (например, формат, протокол или содержание), в которых интерфейс менять нельзя,

• ограничения физических размеров (например, контроллер должен помещаться в ограниченном пространстве крыла самолета),

• законы определенной страны,

• доступные сроки или бюджет

• уже существующая технологическая платформа,

• ограничения или возможности пользователя или оператора.

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

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

• Независимость от выполнения. Требование не только указывает, что является необходимым и достаточным для системы, но и избегает наложения ненужных ограничений на архитектурный проект. Его задача - быть независимым от реализации. Требование описывает, что требуется сделать, а не как это требование должно выполняться.

• Однозначность. Требование излагается таким образом, что может интерпретироваться только однозначно. Оно должно быть простым и легким для понимания.

• Непротиворечивость. Требование не должно противоречить другим требованиям.

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

• Уникальность. В изложенное требование входит только одно требование, без использования сочетаний.

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

• Отслеживаемость. Требование можно отследить до нужного задокументированного утверждения о потребностях правообладателя в требовании более высокого уровня или в других источниках (например, торговые и проектные исследования). Требование можно также отследить до нужного утверждения в спецификации требований более низкого уровня или других артефактах определения системы. Иными словами, все связи "родитель-потомок" для требования идентифицируются при отслеживании таким образом, чтобы требование можно было отследить как в сторону его источника, так и в сторону реализации.

• Проверяемость. Существуют средства, доказывающие, что система удовлетворяет заданному требованию. Могут быть собраны доказательства, свидетельствующие о том, что система удовлетворяет заданному требованию. Проверяемость улучшается, если требование можно измерить.

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

Требования должны формулировать "что" необходимо сделать, а не "как". В требованиях должны быть указаны нужды рассматриваемой системы, а не ее проектные решения. Однако требования назначаются и распределяются по уровням системы, а значит на более высоких уровнях будет присутствовать распознавание заданных проектных/архитектурных решений. Это часть итеративного и рекурсивного применения анализа требований и процессов построения архитектуры.

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

Далее приводятся типы неоднозначных терминов:

• Прилагательные в превосходной степени (такие как "лучший", "самый")

• Субъективные формулировки (такие как "удобный для пользователя", "простой в использовании", "экономически эффективный")

• Неясные местоимения (такие как "он", "оно", "это", "то")

• Неоднозначные наречия и прилагательные (такие как "почти всегда", "существенный", "минимальный")

• Бессрочные и непроверяемые термины (такие как "предоставить поддержку", "но не ограничиваясь", "как минимум")

• Сравнительные фразы (такие как "лучше, чем", "более высокого качества")

• Лазейки (такие как "если возможно", "в случае необходимости", "в зависимости от обстоятельств")

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

• Негативные высказывания (такие как "возможность системы не может быть предоставлена")

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

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

Наглядные примеры атрибутов требований:

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

• Приоритет правообладателя. Приоритет каждого требования должен быть идентифицирован. Это может быть установлено путем достижения консенсуса между потенциальными правообладателями. Соответственно, для идентификации приоритета каждого требования могут использоваться шкала 1-5 или простое деление "высокий, средний, низкий". Приоритет не подразумевает, что некоторые требования не являются необходимыми, но может указывать, какие требования представляют интерес для торговых площадок, если решения относительно альтернатив являются обязательными. Приоритизация должна учитывать интересы правообладателей, которым нужны эти требования. Это облегчит нахождение компромиссных требований и сбалансирует влияние изменений на правообладателей.

• Зависимость. Если существует взаимная зависимость требований, ее необходимо задать. Некоторые требования могут иметь низкий приоритет с точки зрения правообладателя, однако иметь существенное значение для системы. Например, требование «измерять наружную температуру окружающей среды» может влиять на другие требования, такие как «поддержка температуры внутри салона». Такая взаимосвязь должна быть определена, чтобы при удалении основного требования дополнительное требование тоже можно было исключить.

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

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

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

• Степень сложности. Должна быть указана предполагаемая степень сложности осуществления каждого требования (например, легко, сложно, стандартно). Это служит дополнительной информацией для оценки масштабов и доступности требования, и используется при моделировании затрат.

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