![]() Главная страница Случайная страница КАТЕГОРИИ: АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатикаИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханикаОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторикаСоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансыХимияЧерчениеЭкологияЭкономикаЭлектроника |
Определение требований 1 страница
Документ определения требований содержит все требования, предъявляемые к сис теме и сформулированные на естественном языке, благодаря чему они становятся понятными и заказчику, и тем, кто принимает участие в разработке проекта. В пер спективе тестирования мы заинтересованы в получении из этого документа инфор мации, достаточной для того, чтобы иметь возможность приступить к планированию и разработке тестов. Для наших целей определения требований должны обладать следующими свойствами:
• Каждое требование должно быть снабжено уникальным идентификатором, чтобы можно было однозначно ссылаться на него при планировании тестового покрытия, при проектировании тестовых случаев и в отчетах по результатам тестирования.
• Требования должны быть представлены с точки зрения пользователя системы. Системные и приемочные испытания должны быть спроектированы на основе определений требований, следовательно, эти определения должны быть сфор мулированы в перспективе системного уровня. Этот принцип препятствует по явлению требований, затрагивающих внутренние свойства системы и требую щих детальных знаний программного кода для успешного тестирования. Такие требования должны возникать на поздних стадиях разработки и охватываться модульным тестированием и проверкой взаимодействия и функционирования компонентов системы.
• Должны быть включены как функциональные (functional), так и нефункциональные (nonfunctional) требования. Функциональные требования суть требования, описывающие услуги и функции, которые должна выполнять разрабатываемая сис тема. Нефункциональные требования описывают ограничения, накладываемые на работу системы, например, количество одновременно работающих пользо вателей, и стандарты, которым должна соответствовать система.
• Документ определения требований должен находится под управлением конфи гурациями. Это, по меньшей мере, означает, что данный документ подпадает под управление версиями и что все версии документа должны быть помещены в безопасное хранилище, подобное, например, каталогу, содержимое которого обычно дублируется. Если требования подвергаются изменениям, мы должны иметь возможность проследить, чтобы соответствующие изменения были вне сены в тестовые случаи системных и приемочных испытаний.
Оглавление одного из возможных вариантов документа, содержащего системные требования, представлено на рис. 2.3. Это оглавление соответствует стандарту IEEE Standard 830: The IEEE Guide to Software Requirements Specifications [23] — Руководящие принципы IEEE по составлению спецификации требований к программному обеспе чению. Пример документа определения требований, соответствующего рис. 2.3, при водится в третьей части книги. Этот пример может принести определенную пользу, если вы окажетесь в ситуации, когда необходимо будет составить собственный доку мент определения требований. Кроме того, он может оказаться полезным при прове дении статического тестирования различных документов, основанных на определе нии требований.
|