Требования – основа качества ПО

Для тех, кто в индустрии, давно знакомы проблемы с описанными требованиями в стиле «Без внятного ТЗ результат ХЗ». Увы, это так, часто постулат из Agile-манифеста, который гласит, что «работающий продукт важнее исчерпывающей документации» слишком вольно интерпретируют, вплоть до уровня «работающий продукт важнее документации». Как следствие, без сформулированных требований ПО очень часто изобилует ошибками, которые не только сложно обосновать, так как в требованиях не описаны ожидаемые результаты, но и стоимость исправления которых бывает кратно выше, чем на этапе формирования требований в самом начале SDLC. А потому наличие требований – один из важнейших гарантов качества и производственной эффективности команды, к слову, повлиять на который может не только QA, но и вся команда!

Плюсы при проектировании

Документируя требования на этапе проектирования мы имеем возможность комплексно взглянуть на предстоящее решение, не упустив как общих его элементов, так и деталей. Сохраняя требования, мы упрощаем работу по проектированию будущих доработок, ссылаясь на более ранние требования или изменяя их осознанно.

Плюсы для разработки

Наличие требований серьезно снизит не только стоимость разработки (так как не нужно будет согласовывать требования по ходу реализации), но и стоимость исправлений ошибок (многих багов в коде можно будет вообще избежать еще на этапе тестирования требований, о котором расскажу в одном из ближайших постов подробнее), а также будущей поддержки ПО (ведь при последующих доработках будет легче понять как ПО работало перед стартом новых решений в нём).

Плюсы для тестирования

Более того, наличие требований к ПО упрощает и делает работу тестировщика более прозрачной и четкой. Так, например, появляется возможность производить верификацию самих требований, как вариант, с помощью матрицы трассибилити. А это в свою очередь упрощает управление тестовым покрытием, ведь на основе требований можно подобрать наиболее оптимальный состав испытаний, как тестирования отдельно взятой задачи, так и регрессионного тестирования, в том числе risk-based.

Кроме того, существенно упрощается вышеупомянутое обоснование дефектов, которые будет легче фиксировать и проверять их исправления, руководствуясь сформулированными требованиями к ПО.

Плюсы для эксплуатации

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

Вывод

Итого, мы имеем целый букет полезных аспектов сформулированных требований в разрезе качества и стоимости ПО на их основе. Надеюсь заметка будет полезна для тех, кто хочет обосновать формулирование требований в своей работе.

PS: как повлиять на наличие требований?

Например, сформулировав DoR (definition of ready) к началу разработки таким образом, чтобы в поставленной задаче были расписаны ключевые требования к будущему функционалу. И наладить процесс таким образом, чтобы в работу брались только те задачи, что имеют сформулированные требования. Часто такое предложение воспринимают в штыки, руководствуясь потребностью в скорости доставки изменений. Хорошим контраргументом будет констатация того факта, что без ТЗ команда может получить выгоду в краткосрочной перспективе (и иногда это правда имеет решающее значение, например, если речь идет об MVP для проверки гипотезы), но в среднесрочной и долгосрочной перспективе дальнейшая поддержка, эксплуатация и доработка данного ПО будет увеличиваться по срокам. А потому даже для быстрых решений «здесь и сейчас» рекомендую ставить отсроченную задачу на описание требований, если гипотеза будет подтверждена и ПО не уйдёт в корзину.

——-

А как у вас обстоят дела с требованиями к ПО, над которым Вы трудитесь?