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

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

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

38 Часть I. Процесс быстрого тестирования

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

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

Первым на рис. 2.2 показан опрос заказчика с целью выявления требований, ко­ торые он предъявляет к программному продукту. Выявление требований выполняет­ ся в форме вопросов и ответов. С использованием слайдов, макетов и прототипов заказчику предлагаются различные варианты. Сбор пожеланий со стороны заказчика может осуществляться в виде серии интервью или путем использования технологии FAST (Facilitated Application Specification Techniques - технология упрощенной спе­ цификации приложения), представляющей собой специальный тип собеседований с заказчиком, который облегчает выявление его требований.

По мере получения от пользователя, требования должны фиксироваться в виде документа, известного как документ определения требований (requirements definition docu­ ment). Этот документ оформляется в виде списка требований, сформулированных врезультате собеседований с заказчиком. Он представляет собой соглашение между заказчиком и организацией, выполняющей разработки, о том, что должно создавать­ ся. Определение требований представляет собой письменный документ на естест­ венном языке, вполне понятный как заказчику, так и коллективам, которые занима­ ются разработкой и сопровождением системы.

Достоинство документа определения требований состоит в том, что его легко по­ нять, но в то же время ему не хватает точности и технических деталей, необходимых для проектирования и разработки программного продукта. В силу этого обстоятель­ ства должен быть подготовлен другой документ, известный как спецификация требова­ ний (requirement specification) или функциональная спецификация (functional specification).

Хорошим пособием для первого знакомства с основными понятиями и терминологи-

ей, используемой при подготовке спецификаций требований, могут служить публи­ кации [47], [43] и [42].

Как только документ определения требований и спецификации требований будут готовы, можно приступать к построению матрицы прослеживаемости требований (re­ quirements traceability matrix). Назначение этой матрицы состоит в том, чтобы поставитьв соответствие каждому требованию тесты, компоненты проекта и программный код. В идеальном случае в этой работе принимают участие коллективы разработчиков и специалистов по тестированию, в результате чего со временем появятся связанные с каждым требованием проектные компоненты, тесты программных модулей, тесты комплексных и приемочных испытаний. При правильном использовании матрица прослеживаемости требований представляет собой инструментальное средство, ко­ торое помогает каждому специалисту, принимающему участие в процессе разработ­ ки, выполнять работу, непосредственно связанную с потребностями заказчика, и не тратить понапрасну время на решение ненужных задач. С точки зрения группы тес­ тирования этот инструмент может с успехом использоваться для планирования тес­ тирования и проектирования тестов, обеспечивающих хорошее тестовое покрытие.

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