주요 품질 속성(신뢰성, 보안, 가용성 등) 설명

비기능 요구사항은 시스템의 품질을 결정하는 핵심 요소입니다. 다음은 대표적인 품질 속성입니다.

제약조건의 유형과 정의 방법

제약조건은 시스템이 반드시 따라야 하는 외부적 또는 내부적 제한 사항입니다.

다음은 주요 제약조건 유형입니다.

• 기술적 제약: 특정 하드웨어, OS, 플랫폼, 네트워크 등 기술적 한계
  • 예) “Linux 18.04에서만 동작해야 한다.”

• 표준/법규 준수: 산업 규격, 법적 요구 등
  • 예) “ISO 26262 준수 필수”

• 환경적 제약: 온도, 진동, 전원 등 환경적 제한
  • 예) “–20℃~50℃ 범위 내에서 정상 동작”

• 인터페이스 제약: 외부 시스템, API, 통신 포맷 등
  • 예) “CAN 2.0B 프로토콜을 사용해야 한다.”

제약조건 정의 시에는 "누가 봐도 명확하게" 그리고 "반드시 따라야 할 것"만을 포함하는 것이 실무의 핵심입니다.

신규/리버스 상황에서의 현실적 적용 방

• 신규 개발
  • 고객 요구, 표준, 환경 조건 등을 기반으로 프로젝트 초기부터 비기능 요구사항과 제약조건을 상세하게 명시·합의하는 것이 중요합니다.

• 리버스 엔지니어링
  • 기존 시스템의 동작, 코드, 운용 기록을 분석하여 “현실적으로 확인 가능한 비기능 요구사항”만 우선 정리합니다.
  • 불확실하거나 추정된 내용은 ‘임시 제약’ 또는 ‘가정’으로 구분하여 기록합니다.

실무적 주의사항 및 체크리스트

• 비기능 요구사항과 제약조건은 ‘측정 가능하고, 근거가 명확해야’ 합니다.
• 현실적으로 관리·테스트·확인할 수 없는 조건은 요구사항이 아닌 ‘운영 가이드’ 등 별도 문서로 분리하는 것이 효율적입니다.
• 변경이 자주 일어나는 품질/환경 조건은 반드시 변경관리 프로세스와 연동해야 합니다.
• 산출물(테스트 케이스, 코드, 검증 리포트)와 추적 가능하게 관리합니다.

실무 체크리스트 예시

• 각 비기능 요구사항에 대해 측정 기준이 명확한가?
• 제약조건이 객관적으로 검증 가능한가?
• 불확실하거나 논란의 여지가 있는 항목은 ‘가정’ 또는 ‘참조’로 별도 구분했는가?
• 모든 품질/제약 요구사항이 요구사항 문서에 추적 가능하게 연결되어 있는가?
• 고객, 개발, 품질, 테스터 모두가 이해할 수 있는 수준으로 정리되어 있는가?