SRS는 유용한가.. Methodoloy

둘러보다 SRS관련 글들을 보게 되었다.
SRS(Software Requirements Specification)의 중요성

요구공학은 요구사항개발과 요구사항관리 두가지 영역으로 분리된다.
SRS는 요구사항개발(도출-분석-명세-검증)중 명세에 해당된다.

SRS(IEEE 830-1993,4,8)는 complete, unambiguous 를 강조하는데..
(완전성이나, 커뮤니케이션 오류 최소화를 위한 readability 유지를 강조.
이러한 특성으로 인해 특정시점에 대한 정교한 스냅샷으로써는 나름 가치가 있다.
SRS는 프로덕트가 제공하는 것이 무엇인지 정교하게 규명하지만,
도출, 분석, 검증, 관리에서 요구사항을 제련하는 '과정'중
요구사항이 올바른 방향으로 발전할 수 있도록 돕기 위한 산출물, 체계와는 관련없다.

간혹 'SRS는 요구분석 산출물이다..'로 도출,분석,검증,관리 영역을
명세산출물로 집약시키거나 병합하려는 시도를 종종 보는데 위험하다.
특성상 필요이상 드릴다운을 하거나 완전성을 추구하는 경향을 갖게 되기 때문이고,
단계별 목적에 맞는 활동을 하기보다 결과문서에 맞는 활동에 집중하게 되기 때문이다.

측정은 행위를 유도한다.
산출물이 측정대상이 되면 활동에 우선해서 목적을 유도하는 경향을 지닌다는 얘기..
영역별, 단계별 수행 활동 중에 얻고자 하는 가치는 특정시점 스냅샨인 스펙과는 별개다.
그럼에도 영역과 단계, 이해관계자를 아우르는 스펙을 산출물로 활용하는 것은
현재 수행하는 활동의 목적보다 SRS완성이나 그에 근접하는 방향으로 활동을 유도하는 꼴이 되고 만다.

asset을 통제, 관리하는 체계들을 보면 좀 더 명확해 진다.
closed loop(design time,run-time) governance에서
끝을 공식화 할 수 없는 asset들에게 완전성이란 것은 그리 중요한 것이 아니다.
늘 변하는 것을 완전성을 갖추는 시점으로 무언가를 수렴하고 정체시키는 것 보다
올바른 방향성에 놓여서 흘러가도록 유도하는 것이 훨씬 더욱 중요하다는 것이기 때문..
따라서, 요구사항 spec을 작성하고 TBD(to be determined)를 없애도록
강제하거나 재촉하지도 않고 spec을 기준으로 통합하지도 관리하지도 않는다.
다시말하자면 요구사항을 개발, 관리시에 스펙완성을 기준으로 삼는 것이 그리 바람직하진 않다는 것...
(물론 SRS는 활용된다. 마일스톤찍을 때 현황파악시 SRS템플릿을 통합된 뷰 템플릿 정도로..

SRS가 공식 산출물이자 유일무이한 산출물이 되면
정작 중요한 요구사항을 파고들고 분석/정제하는 활동은 눈밖으로 밀려나고,
SRS를 채우거나 기준에 도달하기 위한 활동에 주력하게 된다.
단계나 상황상 TBD일 수 밖에 없는 것을 SRS기준으로 억지로 확정시키거나
'확정이라고 칩시다.. 술사죠'와 같이 정치나 투명성을 깨트리는 것을 유도하게 된다.
(요구분석과정이 지났는데 TBD가 100%에 육박하더라도 그게 잘못된 것은 아니다.


과거 IEEE 830-1993,4,8이 재정되었을 당시
조직이나 인프라, 패러다임상 확정후 미세관리란 개념은 나쁘지 않았다.
다시 말하자면 waterfall이나 spiral자체가 당시 환경기준으로 해악은 아니였다.
하지만 현재는 TBD의 완전성이란 기준이나 해석이 단계별 활동전략으로 바뀌었으니
완료를 목적으로 하는 SRS를 그대로 써먹기에는 많은 무리가 따른다는 것을 인지해야 하겠다.

p.s 추가로 간혹 요구사항과 그 이전의 traceability를
      이론에 따른 필요없는 활동으로 치부하는 경우를 가끔 보는데
      traceability는 이론상에서 중요해서 의례하는 행태가 아니라
      요구사항 검증기준이 되기 때문에 출처와 traceability를 명확히 해야 한다.
      가령, 출처가 고객이 되기 때문에 필요없는 활동이란 것은 에러.
      고객의 잘못된 요구사항을 밝히고 바로 잡아주기위해서 정책, 기준, traceability가 보장되어야 한다는 얘기..

     다음과 같은 자료들을 보면서 각자 요구공학이나 산출물에 대해 생각해 보길..
     - IEEE 830-1998 chacteristics
     - swebok sw requirement
     - cmmi ma
     - cmmi rd / rm
     - closed loop governance
     - 품질관련해서 많이 공부하길..

핑백

덧글

  • Ray 2008/11/24 13:39 # 삭제 답글

    Cavin님 안녕하세요.
    좋은 글 잘 읽었습니다. 그냥 읽으면 흘려버리기 쉬운 중요한 얘기들이 중간 중간 있군요.
    TBD와 SRS완성 시점에 대한 얘기도 참 좋은 경험에서 나온 얘기 인 것 같습니다.
    항상 소프트웨어 공학이라는 것이 목적 및 원리는 명확한데, 현실에 적용을 하면서, 오해를 하기도 하고 다양한 상황에 시의 적절하게 응용하지 못하는 경우도 많은 것 같습니다.
    Cavin님이 말씀하신 것과 같은 상황에서는 당연히 그렇게 대처를 해야 하고, 화상탐사선을 만들 때와 팩키지 제품을 만들 때와 시급한 프로젝트를 할 때는 각각 적절하게 대응을 해야 하는데, 그렇지 않은 경우가 많죠.
    물론 원칙과 원리는 매우 중요하고 원리를 알면 응용은 훨씬 더 잘 보이겠죠.
    Software Engineering에 대해서 조예가 있으신 것 같군요. 앞으로 좋은 정보 많이 기대하겠습니다.
    감사합니다.
  • cavin 2008/11/24 16:03 #

    Ray님 반갑습니다. 좋은 포스팅 잘 보고 있답니다. ^^
    가끔 떠오르는 개인적인 생각들을 메모하는 용도의 블로그라
    객관적이고 정교한, 또는 친절한 내용이 포스팅 되는 일은 없지 않을까 싶네요. T-T
    잘 부탁드려요~ 꾸벅~
댓글 입력 영역