요구사항 공학
요구사항 공학은 소프트웨어 시스템이 수행해야 할 기능과 작동해야 하는 제약 조건을 발견하고, 분석하고, 문서화하고, 검증하고, 관리하는 학문 분야입니다.
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 소프트웨어 요구사항 지식 영역은 합의된 참조 자료를 제공합니다.
History
요구사항 공학은 1970년대의 구조적 분석 방법에서 발전하여 1990년대에 독립적인 하위 분야로 인정받았습니다. 이는 전용 컨퍼런스(RE) 및 저널의 등장, 목표 기반 및 시나리오 기반 모델링의 부상, 그리고 비기능적 요구사항 및 이해관계자 협상에 대한 관심 증가로 특징지어집니다.
Debates
- 선행 요구사항 정의 대 점진적 요구사항 정의
- 계획 중심의 관행은 구축 전에 요구사항을 철저히 명세화하는 것을 선호하는 반면, 애자일 관행은 요구사항을 반복을 통해 점진적으로 발생하고 정제되는 것으로 간주합니다. 이러한 절충은 변동성, 계약적 제약 조건, 그리고 늦은 변경의 비용에 따라 달라집니다.
Key figures
- Axel van Lamsweerde
- Bashar Nuseibeh
- Steve Easterbrook
- Michael Jackson
Related topics
Seminal works
- vanlamsweerde2009
- nuseibeh2000
- sommerville2015
Frequently asked questions
- 요구사항 오류는 왜 그렇게 비용이 많이 드는가?
- 오해되었거나 누락된 요구사항은 종종 설계 및 코드가 이미 그 위에 구축된 후에야 뒤늦게 발견됩니다. 따라서 이를 수정하려면 후속 작업을 되돌려야 합니다. 경험적 연구에 따르면 결함을 발견하는 시점이 늦어질수록 수정 비용이 급격히 증가한다는 것을 일관되게 보여줍니다.
- 애자일 프로젝트도 요구사항 공학을 수행하는가?
- 네, 하지만 다르게 수행합니다. 애자일 프로젝트는 대규모 명세서 문서를 미리 작성하는 대신, 사용자 스토리, 백로그 정제, 그리고 빈번한 피드백을 통해 요구사항을 지속적으로 도출하고, 분석하고, 검증합니다.