요구 분석은 문제 해결의 첫 번째 단계이고, 시스템 소프트웨어가 무엇을 요구하는지를 자세하게 설명하는 것이다.

왜 요구 분석을 정형화하는가?
1. 명확한 요구 분석은 명확한 프로그램을 만들수 있게 해주기 때문이다.

2. 논쟁을 피하는데 도움을 준다.
(이 논쟁이 프로그래밍에 있어서 사소하다고 생각하면 나중에 상처입거나 입힐수 있다는 점이 떠오른다;;)

3. 요구 분석에 기울이면 개발을 시작한 이후에 시스템 수정을 최소화 하는데 도움을 준다.
(이 부분도 막강하게 좋다, 초기 요구에 대해서 생각해두지 못하고 개발을 하게 되면, 나중에 요구가 생겼을때 힘들어지게 되었다.)

입증된 자료
대표적인 사례들을 예로 들며, 요구분석을 지나

아키텍처 단계에서 요구분석 에러가 발생되면 5배 정도의 비용 손해
코드 작성 단계에서 발견되면 10배 정도의 비용 손해
유지보수단계에서 발견되면 100배 정도의 경비가 소요된다고 한다.

다음은 요구 분석을 명세화 하는 방법이 아닌, 요구 사항들이 잘 작성되었는지와 필요한 요구 사항을 잘 이용하는 방법을 서술한다.

- 비유 -
요구 사항은 물과 같아서 얼어 있는 상태에서 만들기가 쉽다  - 아논 -
(비유 한번 ... 최강이다..)


입증된 자료
일반적으로 IBM에서는 지시사항이 개발과정중 평균 25% 요구 분석을 수정한다고 한다.

부연 설명으로, 산타크로스와 이빨 요정을 믿지 않는다면, 요구 사항의 수정은 반드시 있다.
(이런 설명 좋구나~)

컨스트럭션 동안에 요구 분석의 수정
컨스트럭션의 단계에서 요구 분석 수정을 하는 최선의 방법이 있다.
(최선의 방법은 요구 분석 중 요구들이 올바른지 봐야 한다고 필자는 말했었다)

1. 요구 분석을 평가할 때 요구 분석 체크리스트를 사용 한다.
예) 부산가는 KTX를 타고 있고 현재 대구까지 왔는데, 부산에 가야하는게 충분하지 않다면, 우선 대구에서 멈쳐서, 올바른 방향으로 가고 있는지 체크해 봐라.

2. 모든 사람이 요구 분석 수정에 드는 비용을 확실히 알게 한다.
예) .. 기껏 요구했던 사항을 설계해서 만들고 있는데, 요구사항이 바뀌였다. 환장할 노릇. 그때는 고용주에게 말해서 수정계획가 비용을 보여주어, 결정하게 한다. 물론 비용이 더 나오니, 불만을 없을것이다.

3. 변경을 컨트롤하는 절차를 설정한다.
예) 너무 잦은 요구사항 변경이 일어나면, 지치므로, 변경 자체를 특정 시간에만 할수 있도록 합의 보는것이라고 한다.

4. 변경을 적용하는 개발 접근법을 사용한다.
예)조금씩 작성하고 사용자의 의견을 듣고, 설꼐를 약간 수정하고 약간의 변경을 거친후 조금 더 작성하고 반복..

5. 프로젝트를 취소한다.
예) 취소하기 전에 취소시켜야 할 경우가 있다면 적어도 취소시키는 경우와 계속 진행하는 경우 사이에 얼마나 많은 차이점이 있는지 스스로 점검해 보아야 한다.


부연적인 체크리스트
요구 분석 내용
1. 시스템에 대해 소스와 정확도 값의 범위 빈도를 포함한 모든 입력이 지정되었는가?
2. 시스템의 모든 출력은 목적지와 정확도, 값의 범위 빈도 형식등을 포함해서 지정되었는가?
3. 모든 리포트 형식은 지정되었는가?
4. 외부 하드웨어와 소프트웨어 인터페이스가 지정되었는가?
5. 핸드 셰이킹, 에러체크, 통신 프로토콜을 포함해서 통신 인터페이스를 지정되었는가?
6. 처리 시간, 데이터 전송 비율, 시스템 처리량과 같은 시간에 대해 고려했는가?
...
..
.

등등으로 설명하고 있다.











  • 네이버 블러그 공유하기
  • 네이버 밴드에 공유하기
  • 페이스북 공유하기
  • 라이프코리아트위터 공유하기
  • shared
  • 카카오스토리 공유하기