요구사항 작성 원칙 및 가이드라인

요구사항은 명확하고 일관되며, 오해의 여지가 없게 작성해야 합니다. 명확성, 검증 가능성, 추적 가능성, 일관성, 간결성 등이 기본 원칙입니다. 한 문장에는 한 가지 요구만 담고, “누가, 무엇을, 어떤 조건에서, 어떻게”를 빠짐없이 기술하는 것이 좋습니다.

만약, 하나의 요구사항에 내용을 많이 포함해야 한다면, 한 번의 테스트로 Pass/Fail을 판단할 수 있는지 여부를 확인하는 것이 좋다.

실무 가이드라인

• “해야 한다” 또는 “되어야 한다”와 같이 의무적 표현 사용
• “가능하면”, “적절하게”, “빠르게”와 같은 모호한 표현 금지
• 조건, 예외, 범위를 명확히 명시
• 결과가 측정 가능하도록 작성

명확하지 않은 표현의 위험성

모호한 요구사항은 개발자, 테스터, 고객 모두 각기 다른 해석을 하게 만들어 기능 누락, 품질 저하, 일정 지연, 품질 클레임의 직접적인 원인이 됩니다.

예시)

“빠르게 반응해야 한다” → 얼마나 빠르게?

“적절한 에러 메시지를 표시한다” → 적절하다는 기준은?

이처럼, 명확하지 않은 표현은 누가, 언제, 어떻게 책임질지 불분명하게 하며 프로젝트 전체 품질과 신뢰성을 떨어뜨립니다.

잘못된 예시 vs 바람직한 예시

이처럼 명확한 수치, 조건, 동작 대상, 결과를 구체적으로 작성하는 것이 바람직합니다.

자주 사용하는 문장 패턴 및 샘플

• “시스템은 [동작]을 [조건/제한] 내에 수행해야 한다.”
• “사용자가 [행위]를 하면, [결과]가 [얼마나 빨리/어떻게] 발생해야 한다.”
• “[에러/이벤트]가 발생하면, 시스템은 [구체적 동작/표시]를 해야 한다.”
• “시스템은 [성능/품질/안정성] 기준을 [수치] 이상 유지해야 한다.”

샘플)

• “시스템은 정상 동작 중 입력 신호를 500ms 이내에 처리해야 한다.”
• “비정상 신호가 감지되면, 2초 이내에 오류 로그를 기록하고 알람을 발생해야 한다.”
• “모든 로그 파일은 30일간 보관되어야 한다.”
• “사용자는 인증 성공 후 5초 이내에 메인화면을 볼 수 있어야 한다.”