요구사항 명세

요구사항 명세는 도출되고 분석된 요구사항을 설계, 구축 및 승인을 위한 합의된 기반으로 활용될 수 있도록 정확하고 일관되며 검증 가능한 형태로 문서화하는 활동입니다.

Definition

요구사항 명세는 각 요구사항이 모호하지 않고, 검증 가능하며, 추적 가능하도록 작성되고, 전체적으로 일관되고 완전한 시스템 요구사항의 문서화된 표현을 생성하는 것입니다.

Scope

이 주제는 소프트웨어 요구사항 명세의 구조와 내용, 구조화된 자연어부터 유스케이스, 사용자 스토리 및 형식 모델에 이르는 다양한 스타일, 명확성, 완전성, 일관성, 테스트 가능성 등 좋은 요구사항의 품질 속성, 그리고 명세 내용을 규정하는 ISO/IEC/IEEE 29148과 같은 표준을 다룹니다.

Core questions

• 자연어 요구사항을 어떻게 모호하지 않고 검증 가능하게 만들 수 있습니까?
• 형식 또는 모델 기반 명세는 언제 가치가 있습니까?
• 좋은 명세의 품질 속성은 무엇입니까?
• 기능 및 비기능 요구사항은 문서에서 어떻게 구성되어야 합니까?

Key theories

요구사항의 품질 속성

개별 요구사항은 모호하지 않고, 검증 가능하며, 실현 가능하고, 필수적이어야 하며, 전체 집합은 완전하고, 일관되며, 추적 가능해야 합니다. 이러한 속성들은 명세를 검토하기 위한 구체적인 기준을 제공합니다.

형식적 명세와 비형식적 명세

명세는 구조화된 자연어와 유스케이스부터 형식 수학적 표기법에 이르기까지 다양합니다. 형식성은 노력과 접근성이라는 대가를 치르면서 정밀도와 분석 가능성을 높이므로, 위험과 대상에 맞춰 수준을 선택해야 합니다.

Clinical relevance

명확한 명세는 이해관계자와 개발자 간의 계약이자 검증을 위한 참조 자료입니다. 명세의 모호성이나 누락은 결함 있는 설계와 약속된 내용에 대한 분쟁으로 이어질 수 있습니다.

Evidence & guidelines

ISO/IEC/IEEE 29148은 요구사항 명세의 권장 구조와 품질 특성을 정의하며, 그 내용을 규정하는 주요 표준입니다.

History

초기 명세는 주로 자유 형식의 산문이었으나, 1990년대 IEEE 830 표준이 소프트웨어 요구사항 명세를 공식화했으며, 이후 유스케이스, 사용자 스토리, 모델 기반 및 형식 표기법이 도입되어 ISO/IEC/IEEE 29148 표준으로 통합되었습니다.

Debates

무거운 문서 대 가벼운 사용자 스토리

계획 중심의 관행은 포괄적인 명세 문서를 선호하는 반면, 애자일 관행은 적시에 상세화되는 가벼운 사용자 스토리를 선호합니다. 이 선택은 철저함과 계약적 명확성을 적응성과 문서화 오버헤드 감소와 교환하는 것입니다.

Key figures

• Axel van Lamsweerde
• Michael Jackson
• Ian Sommerville

Seminal works

• iso29148
• vanlamsweerde2009
• sommerville2015

Frequently asked questions

요구사항을 테스트 가능하게 만드는 요인은 무엇입니까?

요구사항은 객관적인 절차를 통해 제공된 시스템이 이를 충족하는지 여부를 판단할 수 있을 만큼 충분히 정확하게 명시될 때 테스트 가능합니다. '빠른' 또는 '사용자 친화적인'과 같은 모호한 용어는 정량화되거나 측정 가능한 승인 기준이 부여되어야 합니다.

사용자 스토리가 요구사항 명세를 대체합니까?

사용자 스토리는 반복 개발에 적합한 경량 명세 스타일이지만, 여전히 승인 기준이 필요하며, 복잡하거나 규제된 시스템의 경우 완전성과 추적 가능성을 보장하기 위해 더 상세한 문서로 보완되는 경우가 많습니다.