Почему ошибки в требованиях так дорого обходятся?

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

Применяются ли методы управления требованиями в гибких проектах?

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

Управление требованиями

Управление требованиями — это дисциплина, охватывающая выявление, анализ, документирование, валидацию и управление тем, что должна выполнять программная система, а также ограничениями, в которых она должна функционировать.

Найти тему в PaperMindСкороFind papers & topics

Tools & resources

Скачать слайды

Learn & explore

ВидеоСкоро

Definition

Управление требованиями — это систематический процесс выявления, анализа, спецификации, валидации и управления услугами, которые должна предоставлять программная система, а также ограничениями на ее функционирование и разработку.

Scope

Эта область охватывает выявление потребностей заинтересованных сторон; анализ и согласование противоречивых целей; различие между функциональными и нефункциональными (качественными) требованиями; методы спецификации, от формулировок на естественном языке до формальных моделей; валидацию посредством обзора и прототипирования; а также управление изменениями требований и их отслеживаемостью на протяжении всего жизненного цикла.

Sub-topics

Core questions

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

Key theories

Функциональные и нефункциональные требования: Требования делятся на функциональные утверждения о том, что система должна делать, и нефункциональные (качественные) ограничения, такие как производительность, безопасность и удобство использования, которые часто охватывают всю систему и определяют архитектуру.
Целеориентированное управление требованиями: Системы анализируются с точки зрения целей заинтересованных сторон, которые уточняются в подцели и операционализируются в требования, обеспечивая обоснование, обнаружение конфликтов и отслеживаемость от высокоуровневого намерения до функций системы.

Clinical relevance

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

Evidence & guidelines

ISO/IEC/IEEE 29148 определяет процессы управления требованиями и содержание спецификаций требований, а область знаний SWEBOK Software Requirements предоставляет консенсусную справочную информацию.

History

Управление требованиями выросло из методов структурного анализа 1970-х годов и стало признанной поддисциплиной в 1990-х годах, что ознаменовалось появлением специализированных конференций (RE) и журналов, развитием целевого и сценарного моделирования, а также растущим вниманием к нефункциональным требованиям и переговорам с заинтересованными сторонами.

Debates

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

Key figures

Axel van Lamsweerde
Bashar Nuseibeh
Steve Easterbrook
Michael Jackson

Seminal works

vanlamsweerde2009
nuseibeh2000
sommerville2015

Frequently asked questions

Почему ошибки в требованиях так дорого обходятся?: Неправильно понятое или отсутствующее требование часто обнаруживается только на поздних этапах, после того как на его основе были разработаны дизайн и код, поэтому его исправление требует отмены последующей работы; эмпирические исследования постоянно показывают, что стоимость исправления дефекта резко возрастает по мере его позднего обнаружения.
Применяются ли методы управления требованиями в гибких проектах?: Да, но по-другому. Гибкие проекты выявляют, анализируют и валидируют требования непрерывно с помощью пользовательских историй, уточнения бэклога и частой обратной связи, а не создают большой документ спецификации заранее.