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

Требование к программному обеспечению также может быть нефункциональным, это может быть требование к производительности. Например, нефункциональное требование заключается в том, что каждая страница системы должна быть видна пользователям в течение 5 секунд.

Итак, в основном требования к программному обеспечению – это

• Функциональные или
  
• Нефункциональный
  
  

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

В этом уроке мы узнаем,

• Типы требований
  
• Другие источники требований
  
• Как анализировать требования
  
• Атомный
  
• Однозначно идентифицировано
  
• Полный
  
• Последовательный и однозначный
  
• Прослеживаемый
  
• Приоритет
  
• Проверяемый
  
• Заключение

Типы требований

Бизнес-требования: это требования высокого уровня, взятые из бизнес-целей проекта. Например, система мобильного банкинга предоставляет банковские услуги. Бизнес-требование, которое решено, это – сводка счета и оплата счета решаются как бизнес-требование (конечная цель, чтобы пользователь совершил транзакцию).
Требования к архитектуре и дизайну: эти требования более подробны, чем бизнес-требования. Он определяет общий дизайн, необходимый для реализации бизнес-требований. Для образовательной организации сценариями использования архитектуры и дизайна будет вход в систему, детали курса и т. д. Требования будут такими, как показано ниже.

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

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

Другие источники требований

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

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

Как анализировать требования

Рассмотрим пример образовательной программной системы, в которой студент может зарегистрироваться на разные курсы.

Давайте изучим, как анализировать требования. Требования проявляются на разных уровнях:

• Атомный
  
• Однозначно идентифицированный
  
• Полный
  
• Последовательный и недвусмысленный
  
• Прослеживаемый
  
• Приоритет
  
• Проверяемый

Давайте разберемся с этим на примере, в таблице, показанной здесь, есть три столбца:

1. В первом столбце указан – «тип требования».
   
2. Во втором столбце указано – «некачественно сформулированное требование».
   
3. В третьем столбец указано – «требование из второго столбца в удобоваримом варианте».
   

Вывод: чем конкретнее требование, тем лучше.

Теперь давайте подробно разберемся с каждым из этих требований, начиная с уровня Atomic.

Атомный
Таким образом, каждое ваше требование должно быть атомарным, а это значит, что оно должно быть на очень низком уровне детализации, чтобы его нельзя было разделить на компоненты. Здесь мы увидим два примера требований: атомарный и однозначно идентифицированный уровень требований.

Итак, продолжим с примером построения системы для сферы образования. Здесь плохое требование: «Студенты смогут поступить на курсы бакалавриата и магистратуры». Это плохое требование, потому что оно не атомарно, потому что в нем говорится о двух разных сущностях: бакалавриате и аспирантуре. Таким образом, очевидно, что это плохое требование, поэтому хорошим требованием соответствия было бы разделение его на два требования. Итак, один говорит о зачислении на курсы бакалавриата, а другой говорит о зачислении в аспирантуру.

Однозначно идентифицировано
Точно так же следующее требование к качеству – это проверка на однозначную идентификацию, здесь у нас есть два отдельных требования, но у них обоих одинаковый ID # 1. Итак, если мы ссылаемся на наше требование со ссылкой на ID #, но неясно, на какое именно требование мы ссылаемся, поскольку оба имеют одинаковый ID # 1. Таким образом, зачисления на курс за счет выделение с помощью уникальных идентификаторов должно иметь два требования: 1.1 id – это зачисление на курсы бакалавриата, а 1.2 id – зачисление на курсы последипломного образования.

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

Последовательный и однозначный
Далее, каждое требование должно быть последовательным и недвусмысленным, поэтому здесь, например, у нас есть требования: «У студента будут либо курсы бакалавриата, либо курсы последипломного образования, но не оба сразу». Это одно требование, но есть еще одно требование, которое гласит: «Некоторые курсы будут быть открытыми как для студентов, так и для аспирантов».

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

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

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

Теперь, когда мы преобразуем бизнес-требования в требования к архитектуре и дизайну или преобразуем требования к архитектуре и дизайну в требования системной интеграции, необходима прослеживаемость. Это означает, что мы должны быть в состоянии взять все бизнес-требования и сопоставить их с одним или несколькими требованиями к архитектуре и дизайну программного обеспечения. Итак, вот пример неверного требования, в котором говорится: «Сохранять информацию о студенте - сопоставлена с идентификатором требования BRD?». Пример идентификатора требования здесь не приводится.

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

Таким образом, отслеживаемость осуществляется на всех уровнях проекта.

Приоритет

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

Проверяемый

Каждое требование должно быть проверено. Здесь плохое требование – «каждая страница системы будет загружаться в приемлемый период времени». Тут есть две проблемы с этим требованием: во-первых, каждая страница означает, что может быть много страниц, что может ввести в заблуждение тестирование. Другая проблема заключается в том, что в нем говорится, что страница будет загружаться в приемлемые временные рамки, а какие временные рамки являются приемлемыми? Приемлемыми для кого? Таким образом, мы должны преобразовать непроверяемый аргумент в проверяемый аргумент, который конкретно говорит о том, о какой странице мы говорим «страницы регистрации студента и записи на курсы», и также указаны приемлемые временные рамки, которые составляют 5 секунд.

Заключение

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

Источник →