방법론 요구공학 - 주요점,적용,의견

요구공학은 소프트웨어 개발의 초기 단계로, 사용자나 시스템의 요구사항을 식별, 분석, 문서화하고 이해관계자 간의 의사소통을 원활하게 하는 과정입니다. 이는 소프트웨어가 실제로 필요로 하는 것이 무엇인지를 명확히 파악하고 이를 기반으로 효과적인 시스템을 개발하기 위한 핵심 과정입니다.

 

요구공학은 프로젝트 초기에 중요한 역할을 하며, 잘 수 행 되지 않을 경우 나중에 문제가 발생할 수 있습니다. 

[목차]

• 주요점
• 적용 방법
• 의견

주요점

• 요구사항 식별 및 분석 
  • 사용자 및 시스템 요구사항을 파악하고 문서화하여 명확하고 일관된 요구사항을 정의합니다. 
• 요구사항 관리 
  • 요구사항을 추적, 변경 및 관리하여 프로젝트의 전반적인 흐름을 유지하고 범위 변화에 대응합니다. 
• 의사소통과 협업
  • 이해관계자들 간의 의사소통을 원활히 하고, 요구사항에 대한 이해를 도모하여 오해나 차이를 최소화합니다. 
• 검증 및 확인 
  • 정의된 요구사항이 실제 시스템에 적합한지 확인하고 검증하여 완전하고 정확한 시스템을 보장합니다. 

적용 방법

1. 요구사항 수집 방법
   • 인터뷰, 설문조사, 워크샵 등 다양한 방법을 통해 요구사항을 수집하고 문서화합니다. 
2. 요구사항 분류 및 우선순위 설정
   • 수집된 요구사항을 분류하고 중요도에 따라 우선순위를 부여하여 관리합니다. 
3. 요구사항 문서화 
   • 요구사항을 명확하고 이해하고 쉬운 형태로 문서화하여 개발자들과 이해관계자들이 공통된 이해를 갖도록 합니다. 
4. 요구사항 검증 및 승인 
   • 개발된 시스템이나 제안된 요구사항이 실제 요구사항과 잘 부합하는지 검증하고 승인 절차를 거쳐야 합니다.

의견

개인적으로는 요구공학이 방법론 보다 더 중요하다고 생각합니다. 

꽤 오랜 시간동안 개발 업무를 해오면서 가장 어려웠던 점은 고객의 요구사항을 정리하는 것이었습니다. 

여기서 고객은 고객사를 뜻하기도 하지만, 조직의 상사나 유관부서의 동료들도 포함될 수 있습니다. 

 

보통 고객들은 실제 동작되는 소프트웨어를 보면 생각이 달라지던가 아니며 무엇을 요구했는지 기억하지 못하는 경우가 많습니다. 

그래서 문서화가 중요하고, 공통된 이해를 갖는 게 굉장히 중요합니다. 

많이 보셨을 만한 그림을 하나 넣었습니다. ( 불편한 진실입니다. )

이런 불편함을 줄이기 위해 애자일 방법론이 만들어졌는지도 모르겠습니다. 

 

요즘의 개발 업무에서 문서들이 많이 줄어들었는데, 개인적으로 요구사항에 대한 문서는 반드시 만들어야만 하는 문서 중에 하나라고 생각합니다. 

모든 방법론의 시작은 요구사항을 수집하고 분석하는 것부터 시작합니다. 그만큼 중요합니다. 

아무리 스프린트 리뷰를 통해 의견을 듣는 것도 요구사항 수집의 하나일 수 있습니다. 요구사항 수집과 분석은 언제나 진행하는 것이지만, 

정확하게 분석하고 정리하는 일은 소홀하기 쉽습니다. 

불필요한 업무의 시작은 잘 못된 요구사항 정리라고 볼 수 있습니다. 

 

문서는 글자로만 만들어진 것을 말하는게 아닙니다. 

서로 다른 경험을 가진 사람들과 공통된 이해를 갖는다는 게 얼마나 힘든지 아시는 분들이라면, UML을 한 번쯤은 생각하셨으리라 생각합니다. 

다음엔 UML에 대해 알아보도록 하겠습니다.