요구사항 도출하기

요구사항을 작성하는 것은 늘 어렵다. 왜냐하면 제대로 배워본 적이 없고, 남들이 쓴 요구사항을 볼 때마다 형식이 다 제각각이기 때문이다. 따라서 요구사항을 작성하는 그 이유에 대해 주목하기로 하였다.

분석단계는 요구사항이 무엇인지(what) 정의하는 과정이고, 설계 단계는 요구사항을 어떻게(how) 구현하는지를 정의하는 과정이고, 개발 단계는 요구사항을 시스템이 이해할 수 있는 언어로 변환(conversion)하는 과정이고, 테스트 단계는 요구사항이 제대로 구현되었는지를 검증(verification)하고 확인(validation)하는 과정이다.
실용주의 소프트웨어 개발 37P

그렇다. 요구사항을 작성하는 것이 개발 프로젝트를 진행하는데 있어서 중요하다는 것을 알았지만 그 이유에 대해서는 알지 못했다. 그렇기 때문에 요구사항을 작성할 때마다 잘 작성해야 한다는 생각을 하지 않았던 것이다. 그리고 이는 추상적이고 모호한 표현으로 범벅된 요구사항 분석 산출물을 낳게 된다. 요구사항을 도출한다는 것은 사용자 관점에서 해야하는 것이 무엇인지를 정의해야하는 것이다. 이는 곧, 개발자가 해결해야할 문제, 구현해야할 것이 무엇인지를 정의하는 것이기도 하다.

 

요구사항을 정의할 때, 쉽게 저지르는 오류

1) 소프트웨어 개발의 전체 범위를 명시하지 않는다.

• 요구사항은 시스템으로 구현해야할 내용 뿐만 아니라 비기능(품질 관리)과 같은 내용까지 구체적으로 명시하여야 한다.
• 누락된 것을 나중에 찾게될 경우, 개발비용이 매우 증가하게 된다.

2) 요구사항을 what이 아니라 how 중심으로 기술한다.

• 무엇을 할 지에 대해 고민하는 것은 설계 단계에서 하는 것이다.
• 방법의 관점에서 요구사항을 정의할 경우, 내용이 복잡해진다.

요구사항을 누락하지 않는 방법

비즈니스 프로세스 모델링, 유스 케이스 모델링 기법을 활용하여 도출하라.

요구사항을 도출할 수 있는 기법을 수행하면 요구사항의 누락을 막을 수 있다.

 

유스 케이스 모델링 기법을 활용하면 사용자 관점에서 요구사항을 도출하기 쉽다.
UML 도구나 포스트 잇 등을 활용하여 사용자(Actor) 관점에서 구체적인 요구사항을 뽑아서 커뮤니케이션을 진행한다.
실용주의 소프트웨어 개발 57P

 

직접 만들어본 유스케이스 다이어그램

 

현재 진행하는 팀 프로젝트에서도 위와 같은 UML을 만들고 소통하다보니 요구사항을 직관적으로 확인할 수 있었고,

사용자의 입장에서 프로그램의 흐름을 정의하다보니 누락된 요구사항을 보다 쉽게 확인할 수 있었다.

 

 

 

 

출처 :

https://search.shopping.naver.com/book/catalog/32466960639?cat_id=50010921&frm=PBOKPRO&query=%EC%8B%A4%EC%9A%A9%EC%A3%BC%EC%9D%98+%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4+%EA%B0%9C%EB%B0%9C&NaPm=ct%3Dlsgr2idk%7Cci%3Db56568050a237f2f9c7228f16a7d559ec3cd1809%7Ctr%3Dboknx%7Csn%3D95694%7Chk%3Dc06e6120dbd95a4d64ca2a6a35ae69812a02670b

실용주의 소프트웨어 개발 : 네이버 도서