페이퍼요약 - 업계의 요구사항 검증 관행 by Fanmuy

제목: 업계의 요구사항 검증 관행(Requirements verification in the Industry)

저자: Gauthier Fanmuy 외 2인, 프랑스

문서유형: 페이퍼(총 12페이지)

 

2010년 말에 전세계 다양한 산업 분야의 22개 업체와 인터뷰 및 질문지를 통해 업계의 현 요구사항 엔지니어링 관행(특히, 요구사항 V&V)을 조사한 자료

---

 

RAMP 프로젝트

• 자연어(natural language)로 작성된 요구사항은 제품 개발 프로세스에서 종종 결함의 원인이 됨. 많은 경우 수백, 수천 개의 요구사항이 관리되므로 사람에 의한 검토(human-visual review) 만으로는 요구사항의 일관성과 완전성을 확보하기가 어려움
• 이런 문제를 공통적으로 인지한 프랑스의 산업체, 대학 연구실, 요구사항 솔루션 제공 업체가 모여 2009년 9월 RAMP(Requirement Analysis and Modeling Process)라는 연구 프로젝트를 시작함
• RAMP 프로젝트는 시스템 생명 주기 전반에 걸쳐 자연어로 표현된 요구사항의 효율성과 품질을 개선하는 것을 목표로 하며, 아래를 주요 연구 과제로 함
  - 자연어로 쓰여진 요구사항 정의(Requirements definition) 관행 개선: 요구사항 작성을 지원. 예, 어휘 분석(lexical analysis), 구문 분석(syntactical analysis), 모델 등
  - 요구사항 분석(Requirements analysis) 관행 개선: 비일관성, 중복, 불완전성 발견을 지원. 예, 모델링(modeling), 온톨로지와 일치(compliance to an ontology) 등
  - 문맥 분석(context analysis) 지원: 해당 문맥(context)에서 요구사항 추출 및 정의(requirements elicitation and definition)가 가능하도록 시나리오에서 데이터 식별을 지원, 레가시 시스템의 진화 문맥에서 영향(impacts)을 식별하도록 지원

 

업계의 요구사항 V&V 관행

• RAMP 프로젝트의 첫 걸음으로 여러 산업 분야(우주, 항공, 에너지, 자동차 등)의 주요 업체들을 인터뷰하여 2010년 업계의 요구사항 공학 관행(industrial practices in Requirements Engineering)을 조사함
• 요구사항 공학의 다양한 주제들이 조사되었지만 본 논문은 요구사항의 V&V(Verification and Validation)에 대한 조사 결과를 기술함

 

1) 요구사항에서 가장 공통적인 결함(Most common defects in Requirements)

• 요구사항에서 가장 자주 나타나는 결함으로 '니즈(needs)를 솔루션 형태로 표현'과 '모호성(ambiguity)'을 들 수 있음
• 요구사항의 '일관성(consistency)'과 '완전성(completeness)'도 다루기 어려운 문제임
• 특히 신규 시스템이나 혁신 시스템의 경우 시스템의 입력 데이터(니즈, 시나리오, 미션 프로파일 등)가 항상 완전하거나 구체적이지 못함

 

[요구사항에서 가장 흔한 결함]

 

 

 

2) 인스펙션에 의한 요구사항 V&V

• 인스펙션은 요구사항을 검증(verify)하고 확인(validate) 하는데 가장 흔히 사용되는 수단이며 여러 형태를 취할 수 있음. 예, 크로스리딩(cross readings), 동료검토(peer reviews), 사전 정의된 기준으로 QA에 의한 인스펙션 등
• 대부분의 조직이 전사 차원과 프로젝트 차원의 요구사항 품질 규칙(requirements quality rules)을 가지고 있지만 이 규칙이 올바르게 적용되는 경우가 적음(올바르게 적용됨 15%, 적용되지 않음 35%, 일정치 않게 적용됨 50%)
• 검토 프로세스는 부담이 되기는 하지만 좋은 전문가의 개입이 있는 경우 효과적임. 니즈의 분석은 검토(reviews)에 최종 고객의 참여가 없는 경우 여전히 어려움이 남게 됨

 

3) 모델 사용을 통한 요구사항 V&V

• 요구사항 V&V를 위해 모델을 사용하는 것은 요구사항 검토(requirement reviews) 보다는 흔하지 않은 관행이지만 엔지니어링 프로젝트 개선의 추가 가치를 주는 것으로 판단됨
• 모델 사용의 예로 ‘일관성과 완전성 분석 지원’, ‘요구사항의 영향 및 타당성 수준 평가’, ‘주어진 아키텍쳐에서 시스템 동작 평가’ 등을 들 수 있음
• 자주 사용되는 모델 타입으로 UML, BPMN, Simulink, SysML, Performance 모델, Costs 모델, CAD 모델 등이 있음(순서에 먼저 나온 것이 더 자주 사용되는 모델)

 

4) 요구사항 검증을 위한 도구 지원(Tools assistance for requirements verification)

• 소수의 조직만이 요구사항을 검증하는데 있어 엔지니어나 QA를 지원하는 도구를 사용함
• DOORS나 IRQA 같은 RMS(Requirements Management System) 도구로 요구사항을 검토하는 방법이 가장 많이 사용됨. 즉, 도구의 일부 애트리뷰트나 토론 기능을 사용하여 리뷰 코멘트를 수집하고, 추적성(Traceability) 체크를 통해 요구사항 간의 불완전성과 비일관성 그리고 테스트 커버리지를 확인함. RMS 도구에 추가 기능(add-ons)을 개발하여 의미적으로 취약한 용어(예, fast, quick, at least 같은 단어)를 식별하는 사례도 있음
• 추적성 및 영향 분석(traceability and impact analysis)을 수행하는 특수한 도구는 두 번째로 자주 사용됨. 이런 도구는 어떤 소스로부터 요구사항과 기타 엔지니어링 가공물(artifacts)을 캡쳐하고, Rules checker(예, 결여된 요구사항을 참조, 테스트에서 커버되지 않은 요구사항)를 수반한 추적 매트릭스를 생성함. 취약한 용어 식별이나 문서 검증 속성(예, 테이블의 컬럼에 콘텐츠가 없음)을 위한 스크립트가 개발된 사례도 있음
• 요구사항의 어휘 및 구문 분석(lexical and syntactical analysis)을 수행하는 특수한 도구는 가장 드물게 사용됨. 자연어로 된 요구사항이 불명확하거나 모호할 수 있으므로 이런 도구를 가지고 ‘SMART(Specific, Measurable, Attainable, Realizable, Traceable) 품질 기준’에 대하여 요구사항을 체크함. 이 도구는 비즈니스 리뷰나 프로젝트 리뷰 전에 잘못된 용어 사용(예, weak words), 나쁜 문법의 문장(예, 수동태, 대명사를 주어로 사용), 다수의 요구사항(예, 문장 길이) 등을 찾아내어 수정할 수 있게 해 줌