[소공] 요구분석

소프트웨어를 설계하고 구현할 때, 보통은 어떠한 서비스를 만들겠다는 목적을 가진다. 조직이라면 기획에서 요청이 올 수도 있고, 개인 프로젝트라도 방향성을 잡고 들어가기 마련이다. 이를 위해서 요구 사항을 문서화하고, 그걸 분석하고 설계하는 과정을 거친다.

요구 분석 과정

요구 분석 과정을 'what'에 관점을 두는 편이 좋다. 요약하면 아래와 같은 과정을 가진다.

1. 도메인 분석 : 문제의 배경과 성격, 범위를 파악
2. 요구 추출 : 사용자가 소프트웨어에 대하여 무엇이 필요한지 도출
3. 분석 및 명세화 : 도출된 요구사항을 문서로 정리
4. 검토 : 사용자가 요구하는 것인지 검토(수정이 필요한 경우 요구 추출로 되돌아감)

 

도메인 분석

도메인(Domain)은 보통 해당 분야의 비즈니스나 기술 등을 일컫는다. 개발자는 기술뿐만이 아니라 이런 도메인 지식을 가지고 이해해야 방향성을 알 수 있고, 더욱 빠르고 적합한 개발을 할 수 있다.
즉, 소프트웨어 엔지니어가 문제를 더 잘 이해하기 위해 도메인에 대해 알아가는 과정이 도메인 분석이다. 이를 통해서 상술했듯 개발 속도를 올릴 수 있고, 확장 가능한 구조를 갖출 수 있다.

소프트웨어 엔지니어가 평소에 습득할 수 있는 도메인 지식도 있고, 유관 부서의 PM이나 기획자 등, 다른 인원들이 전달해주는 도메인 지식도 있을 것이다.

이를 문서화하면 대략 아래와 같은 목차를 가진다.

1. 개요
2. 용어
3. 개괄적 지식
4. 고객과 사용자
5. 환경
6. 경쟁 소프트웨어
7. 도메인과 조직의 유사도

문제 정의와 범위 설정

문제가 발생하면서 개발의 필요성이 생기게 된다. 문제는 사용자나 서비스가 마주한 어려움이고, 이를 해결함으로써 생산성이나 매출을 증대할 수 있는 기회가 된다. 좋은 문제 정의는 짧고 간결하다.

문제를 정의하면, 구체적으로 범위를 산정하여 축소하는 과정을 거친다. 서비스가 할 수 있는 모든 일을 리스트 업 하고, 범위에 따라서 목표를 나누면 개발하기 용이하다.

요구 추출

요구란 제안된 서비스(시스템)가 무엇을 하는가를 나타낸 문장이다. 즉, 이전에 정의한 문제를 해결하기 위한 것이다.

마찬가지로 짧고 간결한 정의가 좋고, 서비스(시스템)가 무엇을 하는가를 나타내며 문제를 적절히 해결한 것이다.

• 기능적(functional) 요구 : 서비스(시스템)가 무엇을 하여야 하는지 기술한 것(외형적 기능)
• 비기능적 요구 : 개발 과정에 고수해야 하는 제약 조건(자원의 제약, SW 품질 등)
  ->ex) 사용성, 효율성, 신뢰성, 유지보수성, 재사용성, 플랫폼, 사용 스택(기술), 개발 프로세스 등

요구 추출 방법

요구 추출에도 여러 가지 방법이 있다. 복잡한 내용은 아니고, 다른 분야에서 취재를 하는 것과 비슷하다.

• 관찰 : 사용자의 업무를 관찰한다.
• 인터뷰 : 관련 사용자를 만나 질문/대답을 한다.
• 브레인스토밍 : 여러 사람이 모인 조직에서 아이디어를 도출한다.
• 프로토타이핑 : 시범적으로 시스템을 구현한다(PoC : Proof of Concept).
• 사용 사례 분석 : 시스템의 외부 기능을 파악한다.

요구 문서화

간략하게 추려서 몇 문단의 글 혹은 다어그램으로 개요를 정의한 요구 정의와, 굉장히 복잡하고 자세한 요구 명세서 둘로 극단적으로 나눌 수 있다.

또한, 시스템이 방대해질수록 요구 문서는 계층을 이루어 정리한다.

요구 분석서에는 보통 아래와 같은 목차가 들어간다.

• 문제
• 배경 지식
• 환경 및 시스템 모뎀
• 기능적 요구
• 비기능적 요구

요구 검토

마지막으로 요구가 잘 이루어졌는지 검토가 필요한데, 기준은 굉장히 다양하겠지만 예시로 아래와 같은 기준으로 평가한다.

• 개발 비용보다 이익이 큰지
• 현재 당면한 문제가 해결되었는지
• 명확하고 일관성 있는 표현인지
• 모호성이 없는지
• 논리적으로 일관성이 있는지
• 서비스(시스템)의 충분한 품질을 유도하는지
• 가용 자원으로 실현 가능한지
• 검증 가능한지
• 설계를 과도하게 제한하지 않는지

마지막으로, 설계 명세서의 근거는 요구 분석서에서 찾을 수 있어야 하고, 요구 분석서에는 그 근거와 원인이 명시되어 있어야 하는, 이른바 추적 가능해야 한다. 또한 실제 개발을 하다보면 굉장히 많이 마주하게 되겠지만, 기획과 비즈니스는 수시로 바뀌게 된다. 기술이 변경되기도 하고, 사업의 방향이 바뀔 수도 있다. 그렇기 때문에 요구 분석은 계속해서 진행되어야 한다.