Как правильно декомпозировать требования и какие
примеры правильных требований существуют?
Вот на данном слайде мы видим перечень
требований к космической миссии в соответствии с
стандартами действия европейских производителей.
Здесь очень большой спектр функций,
под каждой из которых существует свой набор требований
и их соотнесение необходимо строго соблюдать.
Мы уже говорили, что требования декомпозируются с помощью
функциональной архитектуры, пример которой был приведен на предыдущем слайде,
и в этом смысле мы видим,
что эти требования именно возникают как вторичный поток,
зависящий от специфики выполняемой функции.
Ну например: чтобы автомобиль мог иметь диапазон скоростей от 0 до 100 км/ч,
необходимо выполнить требования наличия
максимальной массы и минимальной мощности двигателя.
В противном случае, указанное требование соблюдено не будет.
Или есть другие варианты,
которые тоже можно рассмотреть.
Очень важный аспект: часто разработчики
путают понятия «требования» и «пожелания».
Вот «пожелание» – это нечто такое,
что было бы хорошо иметь, но необязательно достигать в реалии.
А «требование» – это как раз то,
что обязательно должно быть сделано для того,
чтобы созданная система была успешной.
Поэтому потребители и участники часто,
не различая, что необходимо, и что желательно,
путают эти понятия, а путать их ни в коем случае нельзя.
Еще одно важное обстоятельство: при формулировке проблем
необходимо абстрагироваться от возможного
пути решения данной проблемы.
И подобный подход
гарантирует вас от того, что вы,
рассматривая возможность решения,
можете сделать не очень правильную формулировку постановки задачи.
И в этом смысле, призыв,
который часто обращается к разработчикам, звучит так: будьте предельно
аккуратны при выборе идеи для реализации,
потому что пользователи и заказчики часто могут иметь хорошую идею,
но быстро предложенное решение далеко не всегда оптимальное и может выявить,
в том числе, невозможность реализации,
а также непрактичность и неоптимальность.
Разобравшись в деталях, отбирайте только то,
что необходимо для достижения реального успеха и только потом
разрабатывайте конкретное решение, удовлетворяющее
подтвержденной необходимости ее реализации.
Требования также подразделяются на конкретные типы.
Наиболее частые из них включают в себя функциональные требования к системе,
определяющие что данный элемент должен делать.
Точностные требования, которые определяют количественные
параметры соответствующих функций, выполняемых системой.
Ограничительные требования, которые вытекают из ограничений
решений в процессе эксплуатации системы.
Верификационные требования, которые обеспечивают то,
что можно доверять принятым решениям,
и что они выполнены и полностью соответствуют предъявляемым требованиям.
Далее мы приводим некоторые примеры,
которые возникают при неправильном формулировании требований.
Ну вот здесь показано, что три основные ошибки,
которые предъявлены в данной формулировке,
это: неопределенность, избыточность и незаконченность фразы.
Вот и первого, и второго, и третьего нужно избегать,
и на втором слайде уже представлены
скорректированные варианты этих определений,
где присутствуют и законченность требования, и конкретность требования,
и в этом смысле такое требование уже, безусловно, может быть выполнено.
На сегодняшний день существует большое количество программных продуктов,
обеспечивающих управление требованиями.
И, безусловно, разработчики очень часто их применяют.
К сожалению, далеко не все они легкодоступны,
но, тем не менее, они существуют.
Теперь посмотрим на примере гипотетического самолета
как должны быть требования к нему правильно сформулированы.
Вот давайте разберем: в левой колонке приведены 4 различных требования.
Самолет такой-то должен перевозить 200 пассажиров и багаж.
Самолет такой-то никогда не должен попадать в аварии.
Может везти 2 000 литров топлива и,
наконец, должен быть максимально комфортным в обслуживании самолетом,
начиная с 2010 года.
Вот давайте разберем: правильные требования или неправильные?
Требование № 1: самолет должен перевозить 200 пассажиров и багаж.
Правильное требование.
Потому что означает кто должен,
и данное требование легко проверить простой инспекцией.
Второе требование: никогда не должен попадать в аварии.
Неправильное требование, потому что использует при своем написании отрицание.
А мы говорили, что ни в коем случае формулировка требования
не должна содержать отрицания.
Может везти 2 000 литров топлива – тоже неправильное требование.
Потому что использование глагола «может»
означает цель, а не требование.
И наконец, последнее: должен быть максимально комфортным.
Также неправильная формулировка.
Комфорт определить нельзя.
Комфортабельно для кого?
Каким образом это проверить?
Как же правильно эти требования переделать?
Ну, первое требование, мы уже говорили,
что оно правильное и его переделывать не нужно.
Второе требование должно быть переписано так: самолет должен быть оборудован
системой предупреждения о сближении с землей для уменьшения риска
контролируемого полета на местности.
Третье требование.
Глагол «может» должен быть заменен на глагол «должен»,
и тогда оно становится правильным.
И, наконец, последнее требование: самолет такой-то должен
обеспечить на 50 %,
больше пространства, для чего минимально требуется,
что минимально требуется
для перевозки 90 % американских мужчин.
Вот то, как должны выглядеть правильные требования к системе.
