Вывод: чем конкретнее требование, тем лучше.
Теперь давайте подробно разберемся с каждым из этих требований, начиная с уровня Atomic.
Атомный
Таким образом, каждое ваше требование должно быть атомарным, а это значит, что оно должно быть на очень низком уровне детализации, чтобы его нельзя было разделить на компоненты. Здесь мы увидим два примера требований: атомарный и однозначно идентифицированный уровень требований.
Итак, продолжим с примером построения системы для сферы образования. Здесь плохое требование: «Студенты смогут поступить на курсы бакалавриата и магистратуры». Это плохое требование, потому что оно не атомарно, потому что в нем говорится о двух разных сущностях: бакалавриате и аспирантуре. Таким образом, очевидно, что это плохое требование, поэтому хорошим требованием соответствия было бы разделение его на два требования. Итак, один говорит о зачислении на курсы бакалавриата, а другой говорит о зачислении в аспирантуру.
Однозначно идентифицировано
Точно так же следующее требование к качеству – это проверка на однозначную идентификацию, здесь у нас есть два отдельных требования, но у них обоих одинаковый ID # 1. Итак, если мы ссылаемся на наше требование со ссылкой на ID #, но неясно, на какое именно требование мы ссылаемся, поскольку оба имеют одинаковый ID # 1. Таким образом, зачисления на курс за счет выделение с помощью уникальных идентификаторов должно иметь два требования: 1.1 id – это зачисление на курсы бакалавриата, а 1.2 id – зачисление на курсы последипломного образования.
Полный
Все требования должны быть выполнены в полном объеме. Например, здесь неверное требование гласит, что «профессор-пользователь войдет в систему, указав свое имя пользователя, пароль и другую соответствующую информацию». Здесь другая важная информация не ясна, поэтому другая важная информация должна быть изложена в хорошем требовании, чтобы сделать требование полным.
Последовательный и однозначный
Далее, каждое требование должно быть последовательным и недвусмысленным, поэтому здесь, например, у нас есть требования: «У студента будут либо курсы бакалавриата, либо курсы последипломного образования, но не оба сразу». Это одно требование, но есть еще одно требование, которое гласит: «Некоторые курсы будут быть открытыми как для студентов, так и для аспирантов».
Проблема в этом требовании заключается в том, что из первого требования кажется, что курсы разделены на две категории: курсы для аспирантов и курсы для аспирантов, и студент может выбрать любой из двух, но не оба. Но когда вы читаете другое требование, оно противоречит первому и говорит о том, что некоторые курсы открыты как для аспирантов, так и для студентов.
Таким образом, очевидно, что это плохое требование можно преобразовать в хорошее таким образом: «У студента будет либо курс бакалавриата, либо курсы последипломного образования, но не то и другое одновременно». Это означает, что каждый курс будет отмечен как курс бакалавриата или курс аспирантуры.
Прослеживаемый
Каждое требование должно быть отслеживаемым, потому что существуют разные уровни требований. Мы уже видели, что наверху у нас есть бизнес-требования, а затем у нас есть требования к архитектуре и дизайну, за которыми следуют требования системной интеграции.
Теперь, когда мы преобразуем бизнес-требования в требования к архитектуре и дизайну или преобразуем требования к архитектуре и дизайну в требования системной интеграции, необходима прослеживаемость. Это означает, что мы должны быть в состоянии взять все бизнес-требования и сопоставить их с одним или несколькими требованиями к архитектуре и дизайну программного обеспечения. Итак, вот пример неверного требования, в котором говорится: «Сохранять информацию о студенте - сопоставлена с идентификатором требования BRD?». Пример идентификатора требования здесь не приводится.
Таким образом, преобразовав его в хорошее требование, оно говорит то же самое, но отображает идентификатор требования 4.1. Так что отображение должно быть для каждого требования. Точно так же, как у нас есть требования к высокоуровневому и низкоуровневому сопоставлению, сопоставление также существует между требованиями системы и интеграцией с кодом, который реализует это требование, а также существует сопоставление между системой и требованиями интеграции с тестовым примером, который проверяет это конкретное требование .
Таким образом, отслеживаемость осуществляется на всех уровнях проекта.
Приоритет