Подготовка документа, содержащего определения требований

• Документ, содержащий определения требований, составлен на естественном языке, вполне понятном заказчикам, пользователям, коллективам разработчиков и специалистам по тестированию

• Воспользуйтесь статическим тестированием для проверки полноты, непротиворечивое™,

•) Пересмотр требований осуществимости и контролепригодноститребований и подтвердите, что требования удовлетворяют потребностям пользователя

-• На стадию проектирования

Рис. 13.1. Процесс формулирования требований

В главе 2 упоминалось о том, что определениям требований присущи следующие характеристики:

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

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

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

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

Структура документа определения требований может основываться на специфи­ кациях, определенных в стандарте IEEE Standard 830: The IEEE Guide to Software Require­ ments Specifications (дополнительные сведения по применению этого стандарта можнонайти в главе 2).

Сейчас мы предлагаем приступим к изучить пример документа определения тре­ бований, который был подготовлен для вымышленного набора инструментальных средств управления тестированием (Test Management Toolkit, ТМТ). Это приложение позволяет менеджерам и инженерам, специалистам в области тестирования управ­ лять планами тестирования, отчетами о дефектах, результатами тестирования, а так­ же другой информацией, связанной с тестированием программного обеспечения. ТМТ представляет собой Web-приложение, благодаря чему несколько географически удаленных пользователей могут одновременно участвовать в нескольких проектах по тестированию. Проект разработки приложения ТМТ приводится в качестве приме­ ра, который рассматривается на протяжении всей третьей части книги. В следующей главе содержится пример плана тестирования, который основан на требованиях к приложению ТМТ, определенных в данной главе.

Определение требований ТМТ TMT-RD-10

Идентификатор документа: TMT-RD-10

Версия: 0.8

Автор: Крис Браун (Chris Brown)