Формирование и уточнение требований происходит на всех этапах разработки программного обеспечения. тестирование требований начинается на этапе планирования, когда стоимость исправления ошибки минимальна. Еще одной причиной раннего тестирования документации, содержащей требования к проекту, является разное понимание задач клиентом, менеджером проекта, аналитиком и программистом. От своевременного уточнения функционала программы зависит скорость выполнения проекта и общий объем работ, т.к. в случае многочисленных переделок объем работ существенно возрастает.
Выявлением требований занимается, как правило, отдел маркетинга, бизнес-аналитики. Выделяют 9 основных способов сбора требований: интервью, анкетирование, работа с фокусными группами, семинары и мозговой штурм, моделирование процессов, прототипирование, наблюдение, анализ документов, самостоятельное описание. Затем выявленные требования фиксируются в документации или оформляются для дальнейшего обсуждения и уточнения.
Требования подразделяют на следующие основные категории: бизнес-требования, требования к качеству продукта, пользовательские требования, функциональные и нефункциональные требования, требования к интерфейсам, требования к данным. Бизнес-правила, спецификации и ограничения также относятся к требованиям, включают в себя стандартизированные атрибуты и методы, принятые в данном классе программных продуктов и отраженные в стандарте. Эта информация используется в дальнейшем для лицензирования продукта, если это необходимо.
Затем производится анализ полученной информации аналитиками проекта. Что делает на этом этапе тестировщик? Он проверяет требования на соответствие следующим характеристикам: непротиворечивость, корректность, завершенность, актуальность, атомарность, исключающая создание составных требований, недвусмысленность, прослеживаемость, модифицируемость, важность, обязательность, стабильность, срочность, выполнимость. Проверка каждого из этих свойств должна быть подкреплена соответствующими тестами.
Техники тест-дизайна, которые используются для тестирования требований, относятся к нефункциональному тестированию, и включают взаимный просмотр коллегами, специалистами разных областей и, в случае передачи проекта от одной команды разработчиков другой, инспекцию специалистами, отвечающими за качество продукта. В случае необходимости повторного выявления требований используется техника задавания вопросов. Вопросы можно формулировать заказчику, адресовать источникам справочной информации, коллегам.
Для проверки проверяемости требований составляют чек-листы и
тест-кейсы. Если их составить не удается, требуется уточнение требований. Возможно, требование составлено поверхностно, в процессе мозгового штурма, и требуется его доработка. По составленной тестовой документации проводится тестирование сценариев, включающее в себя прогнозирование последовательности действий пользователя при работе с программой. При этом тестировщик ищет не описанные ранее случаи поведения системы или неоднозначные случаи, если нарушена логика при построении системы. Эти недоработки нельзя выявить, тестируя требования по отдельности, поэтому тест проводится для группы требований и требует от тестировщика значительных знаний и опыта.
Для представления общей картины требований целиков используются рисунки, схемы, диаграммы, интеллект-карты. Графическое представление требований позволяет выявить недостающие требования и требования, которые при группировке перестают удовлетворять перечисленным ранее критериям.
Графическое представление облегчает понимание и совместную доработку требований с коллегами, помогает в создании прототипов пользовательских интерфейсов, для дальнейшего согласования требований с заказчиками. В случае, если ответы заказчика противоречивые, непоследовательные, необходимо задать уточняющие вопросы и прояснить все непонятные моменты, чтобы, по возможности, устранить противоречия.
Существуют также общие правила, относящиеся к формулированию и корректировке требований:
- формулировки требований должны быть простыми и однозначными для понимания;
- при внесении изменений в требования не допускается скрытое редактирование без уведомления автора документа и без выделения правок, если формат документа не предполагает режим просмотра внесенных изменений, с возможностью принять или отклонить предложенные правки в документ;
- не допускается чрезмерная техническая детализация бизнес-требований, рекомендуется использовать общие формулировки;
- при описании функциональных и нефункциональных требований наоборот, не допускается использование общих формулировок и рекомендуется использовать общепринятую терминологию, соответствующую уровню требований.
Таким образом, мы рассмотрели теоретические вопросы, касающиеся формирования и тестирования требований, на основе 3-го издания учебника Святослава Куликова, о котором я писала ранее, с моими комментариями и интерпретацией некоторых моментов, т.к. переписывать теорию нет смысла, но вспомнить основные моменты всегда полезно. Практические примеры разберем отдельно, на примерах широко известных интернет-ресурсов, поучимся их формулировать и тестировать.
Литература по теме разработки требований к программному обеспечению