[시스템 엔지니어링] 요구 사항을 잘 쓰는 방법

 

How to Write a Good Requirement Checklist

Appendix C: How to Write a Good Requirement - NASA

 

 

프로젝트를 진행하는 것에 있어서 가장 중요한 것은 이해관계자들의 요구 사항을 정확히 파악하고, 이를 수행자들에게 전달하는 것입니다.

 

모호한 요구 사항은 모호한 공학으로 이어지고, 이것은 모호한 제품으로 시장에 전달되어버립니다.

이에, <NASA System Engineering handbook>에서는 다음의 체크리스트를 만들어  확인할 수 있도록 했습니다.

 

다만 영어의 조동사 표현과 한국어의 표현에서의 강조 방법이 상이하여, 그 뜻을 전부 담지는 못했습니다.

요구 사항을 잘 쓰는 방법에 대한 체크리스트

1. 정확한 용어 사용하기

• Shall(~일 것 이다./ ~하기로 되어있다.) - 요구 사항을 작성할 때 사용할 것
• Will (~할 것이다.)- 사실 또는 목적의 공표를 작성에 사용할 것
• Should (~해야한다.) - 목표를 작성할 때 사용할 것

2. 글 작성에 대한 체크리스트

 

2-1 사람에 대한 요구 사항

•  "[책임자(그룹)]이 [이런 저런 일을 수행]한다"
  • 수동적인 표현보다 능동적인 표현으로 작성한다.
  • 요구 사항은 누가 (무엇을 수행하거나 제공할 것인지 등)를 명시한 후에 수행되어야 할 작업에 대한 설명을 포함해야한다.

2-2 프로덕트에 대한 요 구사항

• "프로덕트 ABC는 XYZ 해야한다."
  • 프로덕트 요구 사항은 다음처럼 작성해야한다.
    "프로덕트 A는 되어야하는 바에 따라 B를 해야한다.
• 요구 사항에 용어를 사용할 때에는 프로덕트에서 사용한 용어 뜻 그대로 그를 구성하는 요소들에도 일관적으로 사용합니다.
• 질적, 성능적 수치에서는 허용치를 사용하여 완성합니다.
  • Ex) 보다 크거나, 같거나, +-오차 등의 표현을 사용.
• 요구 사항이 구현에서 자유로운가?
  • 요구 사항은 "무엇을"을 나타내는 것이지, "어떻게"를 나타내는 것이 아닙니다.
  • 문제점을 명시하지만, 해결책을 나타내면 안됩니다.
  • 이 때에는 요구 사항이 왜 필요한지 물어봅니다. 그러면 실제 요구 사항이 나타납니다.
• 운영에 대한 설명이 없는가?
  • 제품이 충족해야 하는 필요사항인지, 아니면 제품과 관련된 활동인지 구분합니다.
  • '오퍼레이터는 ...해야한다'와 같은 문장은 대부분 운영에 대한 표현은 요구 사항이 아닙니다.

예시

• 시스템은 ...의 파워 수준에서 작동해야한다.
• 소프트웨어는 ...에서 데이터를 수집해야한다.
• 구조물은 ...의 하중을 견뎌내야한다.
• 하드웨어는 ...의 중량을 가져야한다.

3. 좋은 체크리스트

• 요구 사항은 문법적으로 정확하다.
• 요구 사항은 오타, 틀린 철자, 구두점의 오류가 없다.
• 요구 사항은 프로젝트에서 사용하는 템플릿과 스타일 규칙에 부합한다.
• 요구 사항은 긍정 표현으로 기술한다. ('하지 않아야한다.'라는 표현을 지양한다)
• 미정 상태(TBD - To Be Determined) 표현은 지양한다.
  이보다 그 값에 대한 최상의 추정치를 사용하고 그 값을 '해결되야 하는 것'(TBR - To Be Resolved')로 표시하는 것이 더 좋다.
  그리고 TBR을 제거하기 위한 근거와 TBR을 제거하기 위해 무엇을 해야 하는지, 그 제거의 책임자는 누구인지, 그리고 제거해야 하는 기한은 언제인지를 명시해야 한다.
• 요구 사항은 가정을 포함한 이해하기 쉬운 설명을 동반한다. 
• 요구 사항은 문서의 적절한 구획에 위치한다.
  (부록을 의미하는 것은 아니다.)

 

4. 요구 사항 검증 체크리스트

 

명확성

 

하나의 요구 사항은 하나의 문장으로 완료되고, 하나의 사고만 담겨져 있어야한다는 것을 나타냅니다.

• 요구 사항이 명료하고 모호성이 없는가?
  • 모든 요구 사항은 이해 가능해야하고, 오해를 일으키지 않아야한다.
  • [이것, 저것]과 같은 부정대명사 사용이 없어야하고, [등등, 와 유사한, 혹은, 필요한 경우, 에 제한되지 않음]과 같은 모호 표현이 없어야한다.
• 요구 사항이 간단하고 간결한가?
• 하나의 요구 사항은 하나의 사고를 표현하는가? 
  하나의 요구 사항이 여러 진술이 통합된 것이 아닌가?
  요구 사항과 근거가 함께 담긴 문장이 아닌가?
• 요구 사항 문장이 하나의 주어와 하나의 술어만 가지는가?

완전성

• 요구 사항이 최대한 완전하게 표현되었는가?
  만약 그렇지 않은 불완전 요구 사항의 경우,  TBD 혹은 TBR로 표현되고, 하나의 목록으로 관리가 되고 있는가?
• 놓친 요구 사항이 있는가?
  예시 -
  기능, 성능, 인터페이스,
  환경 (개발, 제조, 테스트, 운송, 저장 및 운영),
  시설 (제조, 테스트, 저장 및 운영),
  운송 (제조, 조립, 전달 지점 간, 저장 시설 내, 적재),
  교육, 인력, 운용성, 안전, 보안, 외관 및 물리적 특성, 디자인
• 모든 가정들이 명시적으로 표현되었는가?

준수 여부

• 모든 요구 사항들이 적절한 계층에 위치하는가?
  (시스템, 부분, 요소, 서브 시스템)
• 요구 사항에 구현 세부 정보가 없는가?
  요구 사항은 무엇을 해야 하는지 명시해야 하며, 어떻게 해야하는 지를 나타내는 것이 아니다.
• 요구 사항에 운영에 관한 기술이 없는가?
  운영을 요구 사항에 섞지 말고, 운영 컨셉 시나리오에 작성하라.
• 요구 사항은 인력이나 작업 명세와 분리되어있는가?
  인력에 대한 내용 혹은 작업 내용을 제품 요구 사항과 혼합하지 말아야 한다.
  SOW(작업 범위서) 또는 업무 명령에 작성하라.

조화성

• 요구 사항은 일관되게 명시되었으며 요구 사항들 간이나 관련 시스템의 요구 사항과의 모순이 없는가?
• 작성된 용어들이 사용자, 이해 관계자들이 사용하는 것과 부합하는가?
• 용어들이 문서 내 일관성있게 사용되는가? 핵심 용어들이 프로젝트 용어집에 포함되있는가?

추적 가능성

• 모든 요구 사항이 필요한가?
  각 요구 사항이 상위 요구 사항을 충족하기 위해 필요한가?
  각 요구 사항이 필요한 기능 또는 특성인가?
  • 필요성(Needs)과 욕구(Wants) 사이를 구별해야한다.
    필수가 아니면, 이는 요구 사항이 아니다.
    이 경우, '해당 요구 사항이 포함되지 않았을 경우 어떤 최악의 결과가 발생할까요?'라고 물어라.
• 모든 요구 사항(기능, 구조, 제약사항)이
  상위 요구 사항이나 최종 목표 또는 관심 대상 시스템(즉, 필요성, 목표, 목적, 제약 사항 또는 운영 개념)과 양방향으로 추적 가능한가?
• 각 요구 사항이 다른 부속 고유 문서에서 참조될 수 있도록 명시되어 있는가?
  (예: 각 요구 사항에는 고유한 번호가 부여함으로 문서가 해당 요구 사항을 가리킬 수 있도록 함)

 

정확성

• 요구 사항이 정확한가?
• 명시된 가정이 정확한가?
  가정에 대한 내용은 해당 문서가 프로젝트의 기초로 나타나기 전에 검사를 받고 승인되어야한다.
• 요구 사항들이 기술적으로 실현 가능한가?

 

기능성

• 기술된 기능들이 필요하고 최종 목표와 시스템의 목적과 목표에 도달하기에 충분한가?

성능

• 모든 요구된 성능 사양과 성능 마진을 나타내는가?
  (시간 조절, 처리량, 저장량, 지연 시간, 정확성, 정밀성 고려할 것)
• 각 성능적 요구 사항이 실현 가능한가?
• 성능적 허용 오차가 지나치게 엄격한가?
  허용 오차가 비용 효율적이고 합리적인가?
  만약 허용 오차가 2배, 3배가 될 때, 어떤 최악의 상황이 생길지 물어볼 것.

인터페이스

• 외부적 인터페이스가 명료하게 정의되었는가?
• 내부적 인터페이스가 명료하게 정의되었는가?
• 모든 요구 사항들이 필요하고, 충분하며, 다른 것들과 부합하는가?

유지보수성

• 시스템의 유지보수성 요구 사항이 측정 가능하고 검증 가능한 방식으로 나타나는가?
• 요구 사항이 변경으로 인한 파급 효과를 최소화할 수 있도록 작성되는가?
  (즉, 요구 사항들이 최대한 독립되어있는가?)
   

신뢰성

• 명확하게 정의되고 측정 가능하며 검증 가능한 신뢰성 요구 사항이 명시되어 있는가?
• 에러 검출, 에러 리포팅, 에러 핸들링, 에러 회복에 대한 요구 사항이 있는가?
• 원치 않은 사건이 고려되고 그런 것에 대한 응답이 있는가?
  (Single-event upset - 단일 입자의 에너지가 전자 기기에 영향을 미치는 현상, 데이터 손실 또는 왜곡, 운영 인원 실수 등)
• 기능의 의도된 순서에 대한 가정이 명시되었는가? 이러한 순서가 필요한가?
• 요구 사항들이 하드웨어, 소프트웨어, 운영, 인력 및 절차의 관점에서 소프트웨어 또는 하드웨어 장애 후 시스템의 생존 가능성을 충분히 다루는가?

실증가능성과 시험가능성

• 시스템을 테스트, 시연, 검사 또는 분석하여 요구 사항을 충족시키는지 보여줄 수 있는가?
  이것이 해당 요구 사항이 명시된 시스템 수준에서 가능한가?
  요구 사항의 달성을 측정하고 준수 여부를 검증할 방법이 있는가?
  검증의 기준을 명시할 수 있는가?
• 요구 사항이 명확하게 명시되어 시스템 테스트 성공 기준과 요구 사항을 지정하는 것을 쉽게 하도록 만들었는가?
• 요구 사항에 검증할 수 없는 용어가 없는가?
  (유연한, 쉬운, 충분한, 안전한, 적응 가능한, 사용자 친화적인, 사용 가능한, 필요할 때, 적절한, 빠른, 휴대용, 가벼운, 작은, 큰, 최대화, 최소화, 충분한, 견고한, 빠르게, 쉽게, 명확하게 등 제외할 것)

 

데이터 사용

• 해당하는 경우, "Don't Care" 조건이 진짜 "Don't Care" 조건인가?
  (Don't care" 조건은 특정 값, 조건에 대해 무시될 수 있는 것으로, 준수 여부가 아무 상관 없다는 뜻)
  "Don't Care" 조건이 명시적으로 나타나 있는가?

 

요구사항 검증 행렬

이런 내용을 준수하는 요구 사항을 만들었다면, 아래와 같은 요구사항 검증 행렬을 생성하여 검증이 진행될 수 있습니다.

해당 내용에 대한 자세한 것은 후에 기술하도록 하겠습니다.

Requirements Verification Matrix @ https://www.nasa.gov/reference/appendix-d-requirements-verification-matrix/