2월 1일부터 3일까지 3일간 요구공학에 관한 교육을 받고 왔습니다.
요구공학이라 함은 한마디로 고객의 요구사항을 이해하고 이를 프로젝트에 반영하는 방법에 대한 이론입니다.
일반적인 소프트웨어공학, CBD 개발 방법론이나, 정보공학에서도 많이 나오는 내용으로 현실에는 참 적용되기 힘든 이론중 하나입니다.
하지만, 교육을 받으면서 새롭게 느낀 부분이 몇 가지 있어 공유하려고 합니다.
(SM 보다는 SI에 해당하는 내용이기에 요구사항을 Service Request로 보기는 힘드니 감안하시고 이해해주세요.)
첫째, 요구사항은 반드시 그 종류를 구분하여 이해하여야 한다.
사용자가 원하는 요구사항을 Use-Case를 표현하기 시작하면, 왠지 표현이 되기 힘든 요구사항들을 경험하셨을것이라고 생각됩니다.
그 이유가 바로 요구사항도 그 종류가 있음을 무시하고 억지로 Flow형태로 표현하려고 하였기 때문이라 생각됩니다.
요구공학에서는 사용자의 요구사항을 다음과 같이 구분/분류합니다.
위와 같이 분류를 해놓고 보면 시나리오로 표현 될 수 있는 것은 따로 존재함을 알수 있습니다.
물론 분류 하기 애매모호한것도 있겠지만, 실상황을 잘 대입해보시면, 나름대로 명확하게 분리 될 수 있었습니다.
그리고, 이렇게 요구사항을 분류/분리하는 작업이 결국에는 각종 문서를 만드는 기본이 됨으로 힘이 들어도 한번 해놓는 것이 좋을듯합니다.
예> 데이터정의 요구사항 => 데이터 정의서
품질특성 요구사항 => Service Level Agreement
기능요구사항 => Function 리스트
시나리오 요구사항 => USE-CASE Diagram
외부 I/F 요구사항 => 인터페이스 정의서
이렇게 분류 해놓고 보면, 개발을 하는 입장에서도 어떤 부분의 요구사항이 부족한지가 확연히 보이는 장점도 있습니다.
둘째, USE-CASE의 고정관념을 깨라!
이 부분은 교육을 받는 사람들 사이에서도 논의가 많았던 부분입니다.
즉, CBD방법론으로 공부 하신분 들은 실제로 USE-CASE가 없으면, 다음 단계를 진행할 수 없습니다.
(실제로 Rational Rose같은 프로그램으로 개발할때는 Use-Case로 그린 것이 그대로 Package나 Class로 자동 생성됩니다.)
강사가 말하는 요구공학상에서의 USE-CASE는 관련자(요구사항 요청자/개발자/시험자)가 요구사항을 이해 하기 쉽게 Diagram으로 표현한것이다.
즉, 뻔한 내용을 USE-CASE로 그리는 것은 시간낭비다. 모호한 시나리오에 대한 의사소통 수단으로 사용되어져야한다.
결론적으로 어떤 방법이 맞는 것인가는 여러분이 결정할 몫이지만, 게시판마다 Use-Case는 그리는 것은 왠지 아닌듯합니다.
또, 보통 우리가 생각하는 Use-Case는 Diagram을 많이 생각합니다.
하지만, Use-Case는 텍스트 형태로도 작성되어야 합니다.
위가 Text형태로 작성된 Use-Case입니다.
상당히 좋은 Templete인 듯합니다. 향후 저희 파트에서도 SI 프로젝트 진행 시 사용해 보았으면 합니다.
셋째, 요구공학은 이론이지만, 꽤 괜찮은 이론이다.
실제로 요구공학 수업을 들으면서 계속해서 느낀 것입니다.
여러가지 중복되는 부분도 많고 단계도 참 많습니다. 요구개발 단계에서만 약 16단계가 있습니다.
이것들을 모두 실행하려면, 결국에는 프로젝트를 위한 방법론이 아닌 방법론을 위한 프로젝트로 주객이 전도될 위험이 상당히 많습니다.
하지만, 결론적으로 제공하는 여러가지 Template이라던지 굵직한 Flow는 상당히 현실 적합한 부분이 많습니다.
이에, 실제로 교육 기회가 없으셨던 분들도 한번은 훑어 볼만한 이론이라 생각됩니다.
강의문서도 상당한 양이고, 실습도 많았지만, 모든 내용을 보실 필요는 없을 듯 하고 요구개발쪽 모듈만 한번 보시면 될 듯합니다.
실제로 예제가 많아, 이해하시는데에는 크게 무리 없을듯합니다. 혹시라도 질문있으시면 해주시고, 꼭 한번 훑어봐 주세요 ^^;;;;
(0) 
(0)Posted by akiss4u
