Определение требований 1 страница

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

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

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

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

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

Оглавление одного из возможных вариантов документа, содержащего системные требования, представлено на рис. 2.3. Это оглавление соответствует стандарту IEEE Standard 830: The IEEE Guide to Software Requirements Specifications [23] — Руководящие принципы IEEE по составлению спецификации требований к программному обеспе­ чению. Пример документа определения требований, соответствующего рис. 2.3, при­ водится в третьей части книги. Этот пример может принести определенную пользу, если вы окажетесь в ситуации, когда необходимо будет составить собственный доку­ мент определения требований. Кроме того, он может оказаться полезным при прове­ дении статического тестирования различных документов, основанных на определе­ нии требований.