Функциональные и нефункциональные инженерные требования

http://software-engineering-book.com/web/requirements-reviews/
Ряд методов проверки требований может использоваться отдельно или в сочетании друг с другом:

1. 
   Обзор требований Требования систематически анализируются группой рецензентов, которые изучают ошибки и несоответствия.
   
2. 
   Прототипирование включает в себя разработку исполняемой модели системы и ее использование конечными пользователями и заказчиками для проверки ее соответствия их потребностям и ожиданиям ­. Заинтересованные стороны будут экспериментировать с системой и возвращать изменения запроса команде разработчиков.
   
3. 
   созданию тестового режима должны быть протестированы. Если тесты требований разрабатываются как часть процесса утверждения, это часто выявляет проблемы с требованиями. Если тест сложно или невозможно спроектировать, это обычно означает, что требования будет сложно реализовать и их нужно будет пересмотреть ­. Разработка тестов на основе пользовательских требований до того, как будет написан какой-либо код, является неотъемлемой частью разработки на основе тестирования.
   

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


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

1. 
   Проверки пригодности Убедитесь , что эти требования ­отражают фактические потребности пользователей системы. По мере изменения обстоятельств требования пользователей могли измениться с момента первоначального объявления .
   
2. 
   Проверка соответствия Требования в документе не должны противоречить друг другу. То есть одна и та же системная функция не должна иметь противоречивых ограничений или разных описаний.
   
3. 
   Проверка полноты Документ «Требования» должен включать требования, определяющие все функции и ограничения, предусмотренные пользователем системы.
   
4. 
   Проверка реалистичности Используя знание существующих технологий, необходимо убедиться, что требования могут быть выполнены в рамках предлагаемого бюджета для системы. Эти проверки также должны учитывать бюджет и график разработки системы.
   

проверки Чтобы свести к минимуму разногласия между Заказчиком и Исполнителем, системные требования должны быть написаны таким образом, чтобы их всегда можно было ­перепроверить . Это означает, что вы должны написать набор тестов, которые покажут, что поставляемая система соответствует каждому заданному требованию.