좋은 요구사항의 특성


 

  • Atomic – 각 요구사항은 단일 요구사항이어야 한다.
  • Complete – 각 요구사항은 원하는 시스템의 기능성을 정의하는데 필요한 정보를 모두 포함해야 한다. 각 요구사항은 더 이상의 확대 없이 단독으로 가능해야 한다.
  • Concise – 각 요구사항은 단순하고 명확하게 무엇이 처리되어야 하는지에 대하여 언급해야 한다. 이것은 시스템에 대해 기술적으로 모르는 사용자도 쉽게 읽고 이해할 수 있어야 한다. 일반적으로 텍스트 요구사항은 30~50 단어 이상을 포함할 수 없다. 그래픽을 사용하여 표현한 요구사항 또한 간결해야 한다.
  • Consistent—요구사항은 다른 요구사항들과 모순 또는 중복되면 안 된다. 일관된 요구사항(consistent requirements)은 또한 명세 전반에 걸쳐 동일한 용어를 사용해야 한다. 요구사항은 창의적 글쓰기를 연습할 수 있는 곳이 아니다.
  • Correct—각 요구사항은 시스템을 정의되고자 하는 올바른 요구사항이어야 한다. 이것은 정확한 정보를 전달해야 한다. 이 속성은 요구사항 확인(requirements validation) 노력에 의해 보장된다.
  • Implementation free—각 요구사항은 구현방법에 대한 식별 없이 무엇이 요구되는지를 언급해야 한다. 일반적으로, 요구사항은 설계 또는 구현을 기술해서는 안 된다. 그러나, 인터페이스 또는 파생 시스템 요구사항(derived system requirements )과 같은 몇 가지 예외가 있을 수 있다.
  • Necessary—각 요구사항은 필수 기능, 특성 또는 품질 요소를 언급해야 한다. 요구사항이 제거되는 경우, 결핍(deficiency)이 존재해야 한다.
  • Traceable— 각각의 요구 사항은 낮은 수준의 요구 사항, 설계, 테스트를 통해 고유하게 식별하고 쉽게 추적 할 수 있어야 한다.
  • Unambiguous— 각각의 요구 사항은 하나의 해석이 있어야 한다.
  • Verifiable—각 요구사항의 구현 검증이 가능해야 한다. 그러므로, 요구사항은 정량화되고 허용 오차를 포함해야 한다. 각 요구사항은 리뷰, 분석 또는 테스트에 의해 검증될 수 있도록 작성되어야 한다. 드문 경우를 제외하고, 검증 중에 관찰될 수 없는 동작의 경우, 요구사항은 다시 쓰여져야 한다. 예를 들어, 부정적인 요구사항은 일반적으로 검증되지 않고 재작성이 필요하다.
  • Viable—각 요구사항은 구현이 가능해야 하고 구현되었을 때, 사용가능하며 전체 시스템 구축에 도움이 되어야 한다.

 

Advertisements

“좋은 요구사항의 특성”에 대한 3개의 생각

답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Google+ photo

Google+의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

%s에 연결하는 중