정보처리기사 요구공학 — 분석의 경계와 검토·명세 원칙

요구사항 분석은 고객의 니즈를 파악해 ‘무엇을 만들어야 하는지(What)’를 정의하고 문서화하는 단계다. 타당성 조사, 비용과 일정의 제약 설정, 요구사항 정의 문서화가 이 단계의 활동에 포함된다. 설계 명세서 작성은 요구사항이 확정된 뒤 시스템의 구조나 알고리즘을 구체화하는 ‘어떻게(How)’의 설계 단계 산출물이므로 분석 단계와 구분한다.

사용자 요구사항 분석이 어려운 이유는 여러 가지다. 개발자와 사용자의 전문 용어·지식 수준이 달라 소통이 어렵고, 사용자가 원하는 것이 명확하지 않거나 모호한 경우가 많으며, 시스템이 복잡할수록 요구사항도 함께 복잡해진다. 여기에 다양한 예외 상황과 특수한 경우가 많아 이를 모두 찾아 열거하고 구조화하기가 어렵다. 따라서 ‘요구사항에는 예외가 거의 없다’는 설명은 분석이 어려운 이유로 성립하지 않는다.

요구사항 명세서는 여러 사람이 검토해 결함을 줄인다. 동료검토(Peer Review)는 요구사항을 작성한 사람이 내용을 직접 설명하고, 이를 들은 이해관계자가 질문하거나 지적하며 결함을 찾는 상호작용적 검토 기법이다. 리팩토링은 코드의 구조를 개선하는 행위이고, 인스펙션은 문서를 체계적으로 점검하는 방식이며, CASE 도구는 자동화 도구라는 점에서 서로 구분한다.

명세 기법에는 해석을 하나로 모으는 원칙이 있다. 명확성(Clarity)은 해당 기능을 일관되게 이해하고 한 가지로만 해석될 수 있도록 중복과 모호한 표현을 배제하는 원칙이다. 상호작용성·독립성·내용성은 모듈의 결합도·응집도·명세의 충실도처럼 다른 차원을 다루므로, ‘해석의 일관성’을 묻는 자리에는 명확성을 고른다.