요구사항 추적성

Requirements traceability

요구사항 추적성은 소프트웨어 개발 및 시스템 엔지니어링 내에서 요구사항 관리의 하위 분야다. 이력 추적에 관한 일반적인 용어로 IEEE및 소프트웨어 공학 Vocabulary[1]에 의해 특히 제품이 predecessor-successor 또는primary-subordinate 관계를 맺는 관계는 개발 과정의 제품을 둘 이상 사이에 설정될 수 있는(1)이 PH으로 하고, 식별(2)[2]정의된다. 그리고 삭제끌어 내기 보도의 Ocumentation(위로)및 할당과 일 중 제품 계층 구조에서 작업 제품의flowdown 경로(아래로);[3]을 소프트웨어 개발 제품에 각 요소와 요건 등과 같은 두개 또는 논리적 실체,, 시스템 요소 중 식별할 수 있는 협회(4)기존의 이유를 규정하는 정도(3).s 검증 또는 태스크.

특히 요구 사항 추적성,"능력고 따른 앞으로 하고 뒤로 방향으로 요구 사항의 삶을 묘사하기 위해(즉, 그 기원, 개발과 규격을 통해, 다음의 구축과 사용에 진행 중인 세련됨과 반복의 이런 단계에서 기간을 통해 1"로 정의된다.[4][5] 요구사항 엔지니어링 분야에서 추적가능성은 높은 수준의 요구사항(목표, 목표, 목표, 목표, 포부, 기대, 비즈니스 요구)이 개발 준비성이 낮고 낮은 요구사항으로 어떻게 변환되는지를 이해하는 것이다. 따라서 주로 정보 계층 간의 만족 관계(일명 아티팩트)와 관련이 있다.[6] 그러나 추적가능성은 요구사항, 규격서, 설계, 시험, 모델 및 개발된 구성요소와 같은 많은 종류의 개발유물 간의 관계를 문서화할 수 있다.[7] 예를 들어, 요구사항이 특정 테스트 아티팩트에 의해 검증된다는 것을 입증하기 위해 검증 관계를 포착하는 것이 일반적인 관행이다.

추적성은 특히 안전에 중요한 시스템을 개발할 때 관련되므로 DO178C, ISO 26262 및 IEC61508과 같은 안전지침으로 규정된다. 이 지침의 일반적인 요건은 중요한 요건이 검증되어야 하며 이 검증은 추적가능성을 통해 입증되어야 한다는 것이다.[8]

요구 사항 및 그 이상의 추적

사전 요구 사항 추적성.[4] 요구사항은 제품을 주문하는 비즈니스 담당자, 마케팅 관리자, 실제 사용자 등 다양한 출처에서 온다. 이 사람들은 모두 제품의 요구 조건이 다르다. 요구사항 추적성을 사용하여 구현된 기능은 요구사항 도출 중 원하는 사용자 또는 그룹으로 추적할 수 있다. 이는 개발 프로세스 중에 요구사항의 우선순위를 정하여 요구사항이 특정 사용자에게 얼마나 중요한지 결정하는 데 사용될 수 있다. 배포 후 사용자 스터디 중에 발견된 특정 미사용 기능이 왜 필요한지 처음부터 확인할 수 있다.

사후 요구 사항 추적성.[4] 요구사항 자체는 추적되어야 할 뿐만 아니라 모델, 분석 결과, 시험 사례, 시험 절차, 시험 결과 및 모든 종류의 문서화 등 그와 관련된 모든 아티팩트와의 요건 관계를 추적해야 한다. 요구사항과 관련된 사용자 및 사용자 그룹도 추적 가능해야 한다. 요구사항은 설계 아티팩트로 실현되고 구현되며 최종적으로 검증된다. 후반 단계에 연결된 아티팩트는 요구 사항까지 추적해야 한다. 이것은 일반적으로 요구사항 추적성 매트릭스를 통해 수행된다.

요구사항을 넘어 설계, 구현, 검증 아티팩트로 추적성을 확립하는 것은 어려워질 수 있다.[9] 예를 들어 소프트웨어 요구사항을 구현할 때 요구사항은 요구사항 관리 툴에 있을 수 있으며 설계 아티팩트는 MagicDraw, Mathworks Simulink, Rational Rhapsody 및 Microsoft Visio와 같은 툴에 있을 수 있다. 더욱이 구현 아티팩트는 다양한 범위에서 다양한 방법으로 설정될 수 있는 소스 파일의 형태로 이루어질 가능성이 높다. 내부 테스트 또는 공식 검증 도구(예: LDRA 테스트베드 제품군, Parasoft DTP, SCADE)에 의해 생성된 검증 아티팩트

리포지토리 또는 툴 스택 통합은 동적 시스템에서 추적성을 유지하는 데 중요한 문제를 일으킬 수 있다.

추적가능성 정보의 사용

특히 툴 체인에 위치한 모든 아티팩트에 대한 요구 사항을 넘어 추적할 때 추적성을 사용하면 다음과 같은 몇 가지 이점을 얻을 수 있다.[10][11]

  • 영향 분석 변경 – 요구사항이 변경되는 경우 추적 링크에서 관련 및 종속 아티팩트에 대해 알림 이러한 유물은 쉽게 검증할 수 있으며 필요한 경우 조정할 수 있다. 관련 유물을 간과할 확률은 감소한다.
  • 적용 범위 분석 – 추적가능성을 통해 어떤 요구사항도 간과되지 않도록 보장 특히 안전에 중요한 제품을 인증할 때는 모든 요건이 실현된다는 것을 증명할 필요가 있다.
  • 프로젝트 현황 분석 – 프로젝트 현황 추적 가능: 추적성 데이터를 분석하여 요구사항의 완료 상태를 확인할 수 있다. 링크 없이 또는 불완전한 추적 체인이 있는 요건(예: 구현하지만 테스트가 없는 요건)은 추가 작업이 필요하다는 것을 나타낸다. 누락된 고리는 어떤 콘크리트 유물이 빠졌는지를 보여주고 있으며, 이를 실현해야 한다.
  • 제품 구성 요소의 재사용 – 요구 사항과 패키지에 연결된 아티팩트를 구조화할 수 있음 이 패키지는 다른 제품에 사용될 수 있다.
  • 지속적인 관계 – 프로젝트나 제품에 대한 지식이 특정인의 머리 속에 있는 경우가 많다. 추적가능성을 이용하여 이 지식은 서로 다른 공예품들 사이의 관계를 시각화함으로써 저장된다. 이 지식은 사람이 프로젝트를 떠나도 남는다.
  • 테스트 최적화 – 요구사항, 소스 코드, 테스트 사례 및 테스트 결과를 연결함으로써 테스트가 실패할 경우 소스 코드의 영향을 받는 부분을 쉽게 식별할 수 있다. 또한 중복 시험 사례를 식별하고 제거할 수 있다.

추적가능성과 그 관련성에 의해 지원되는 개발 활동의 보다 완전한 개요가 에 제시되어 있다.[12]

추적가능성 정보의 실제 사용

광범위한 연구는 효과성뿐만 아니라 추적가능성 정보를 수집하는 어려움도 문서화한다.

  • 추적가능성은 개발 활동을 가속화하고 향상시킨다 - 추적가능성 지원 유무에 따라 소스 코드 변경을 수행한 71명의 실험 대상자를 대상으로 한 연구는 추적가능성의 이점을 보여주었다. 개발자들은 추적가능성을 지원하여 작업을 24% 더 빠르고 50% 더 정확하게 완료했다.[13]
  • 보다 완전한 추적성은 소프트웨어 결함을 피하는 데 도움이 된다 - 24개의 중·대규모 오픈소스 프로젝트에서 얻은 개발 데이터의 분석에서, 포착된 추적성 정보의 완전성과 개발된 소스 코드의 결함률 사이에 통계적으로 유의한 관계가 발견되었다. 더 완벽한 추적성을 가진 구성품들은 결점(일명 버그)의 수가 더 적었다.[14]
  • 준수 추적성 달성은 어렵다 - 2013년 미국 식품의약국(FDA)에서 의료기기의 소프트웨어에 대한 사전 시장 시험을 분석한 결과 규정된 추적성 정보와 파일화된 추적성 정보 사이에 상당한 차이가 있는 것으로 확인되었다.[8] 표준 적합성 추적성을 위한 탐구는 종종 "대규모 동결"을 초래한다. 기업들은 재인증이 엄청난 노력과 연관되어 있기 때문에 추가적인 개발을 피하려고 하기 때문에 큰 동결이다.[15]

추적성 정보의 시각화

추적가능성의 한 가지 목표는 유물 간의 관계를 시각화하는 것이다. 추적 링크의 수와 복잡성이 증가함에 따라 추적성 시각화를 위한 기법이 필요하다. 시각화에는 아티팩트(예: 아티팩트 유형, 메타데이터, 속성) 및 링크(예: 링크 유형, 메타데이터, 링크 강도)에 대한 정보가 포함될 수 있다.[16]

추적가능성 정보에 대한 일반적인 시각화는 행렬, 그래프, 목록 및 하이퍼링크가 있다.

  • 추적성 행렬 – 추적성 행렬은 열에 표시된 한 유형(예: 요구 사항)의 아티팩트를 행에 그려진 다른 유형(예: 소스 코드)의 아티팩트에 매핑하는 표와 같은 표현이다. 셀은 채워지면 두 개의 아티팩트 사이의 흔적을 시각화하고, 비어 있으면 추적하지 않는다.[16] 추적가능성 매트릭스의 장점은 아티팩트 사이의 모든 링크가 한눈에 보인다는 것이다. 필터는 표시되는 정보의 양을 줄이는 데 도움이 된다. 추적가능성 매트릭스는 관리 업무에 적합하다.[16] 그러나, 산업에서 프로젝트는 종종 수천 개의 유물로 구성된다: 표는 매우 크고 혼란스러울 수 있다.[17]
  • 추적성 그래프 – 추적성 그래프에서 아티팩트는 노드로 표현된다. 아티팩트 사이에 추적 링크가 존재하는 경우 노드는 가장자리를 기준으로 연결된다. 그래프는 특히 개발 작업에 적합하다. 그것들은 설명적으로 링크에 대한 개요를 얻을 수 있게 해주며 높은 정보 이해율로 특징지어진다.[16] 그래프를 탐색하면 누락된 링크를 힌트로 쉽게 식별하여 필요한 아티팩트를 만들 수 있다.
  • 목록 – 목록은 하나의 항목에 추적가능성 링크를 나타낸다. 이 항목은 소스 및 대상 아티팩트 및 속성에 대한 정보를 포함할 수 있다. 여러 가지 다른 아티팩트에 대한 대량 작업을 실행할 때 특히 적합하다. 필터와 정렬 메커니즘은 표시된 정보를 처리할 수 있다. 그러나 위에서 설명한 시각화에 비해 프로젝트 관리, 개발 및 시험 업무 수행에 적합하지 않다.[16]
  • 하이퍼링크 – 하이퍼링크는 연결된 아티팩트를 연결하고 소스 아티팩트에서 연결된 아티팩트로 "점핑"을 허용한다. 이 시각화는 고유 환경에서 아티팩트를 탐색할 수 있기 때문에 아티팩트에 대한 자세한 정보가 필요한 경우에 적합하다.[16] 하이퍼링크만 사용하면 링크된 아티팩트가 압축적으로 시각화되지 않기 때문에 링크 상태에 대한 개요를 얻기 위해 많은 탐색 노력이 필요하다는 단점이 있다.

시각화는 그들의 특정한 한계를 극복하기 위해 결합될 수 있다.

기술실현황

수동 추적성

추적성은 전적으로 수동 또는 지원되는 툴(예: Microsoft Excel의 스프레드시트로)을 캡처함으로써 실현된다. 광범위하게 적용되지만, 이 프로세스는 번거롭고 오류가 발생하기 쉬우며, 다양한 관련 개발 도구와 일반적으로 추적해야 할 유물 수가 매우 많아 품질이 부족한 추적가능성 정보로 이어지는 경우가 많다.[18]

툴 지원 추적성

도구 지원 추적성은 개발 도구의 전체 체인에 걸쳐 분산된 개발 정보를 균질화 및 취합할 것을 요구한다. 이 상태에 도달하기 위해 다음과 같은 접근법이 존재한다.

AMLM 도구를 통한 소프트웨어 도구 환경의 균질화 – AML 도구 체인은 소프트웨어 개발 라이프사이클을 포괄하고 소프트웨어 개발 프로세스의 모든 아티팩트를 관리한다. 지라, 아즈레 데브옵스, 기트, 젠킨스, 수많은 시험 자동화 툴 등의 성공과 인기로 동종 최고의 접근방식을 선택한 기업이 많다. 동종 최고의 접근방식을 선택한 기업은 동종 최고의 도구를 위한 완벽한 추적가능성 모델과 통합을 제공하는 요구사항 관리(RM) 도구로 추적가능성 과제를 해결한다. 요구사항, 리스크 분석, 시스템 설계, 작업 관리, 코드 저장소, 통합, 테스트 등을 다루는 단일 AML 툴은 동종 최고의 기능과 보다 제한된 공통 플랫폼 간의 전형적인 트레이드오프다.

대리모 요구 사항을 통한 데이터의 균질화 – 요구 사항 관리(RM) 도구는 시스템 사양에 대한 모든 요구 사항을 저장, 구성 및 관리할 수 있으며 일반적으로 상위 사양에 있는 상위 요구 사항과 각 요구 사항을 연결하는 사양 트리에 배치한다. 기록된 추적가능성 정보에 기초한 일반적인 분석 기능은 예를 들어, 완전성 점검(즉, 모든 시스템 수준 요건이 변경 여부와 무관하게 장비 수준으로 내려가는가), 모든 수준에 걸친 요건 편차의 평가 및 자격 상태 표시 등이다. 요구사항을 초과하는 아티팩트 유형에 대한 추적성을 보장하기 위해 RM 도구는 종종 다른 아티팩트를 대리 요구 사항으로 가져오도록 허용하며, 이 경우 도구의 요구 사항 추적 방법으로 추적할 수 있다. 이 접근방식의 단점은 일관된 버전과 데이터 형식을 갖추어야 하는 서로 다른 아티팩트 유형에 대한 서로 다른 어댑터 또는 변환기가 필요하다는 것이다. AML 도구와 대조적으로 이러한 일관성은 스스로 수행해야 한다.

전용 추적가능성 도구를 통한 데이터의 균질화 - 전용 추적가능성 도구의 기본 개념은 다음 세 가지 필수 단계로 구성된다.

  • 데이터 모델 a.k.a. 추적성 정보 모델(TIM)의 정의. 이 모델은 어떤 아티팩트 유형(예: 이해관계자 요건, 소프트웨어 요건, 통합 시험, 시스템 모델 요소)과 그것들이 어떻게 연결되는지를 명시한다.
  • 개발 도구 체인의 일부인 모든 도구의 모든 관련 데이터 및 이러한 데이터가 TIM에 매핑되는 방법의 매핑 정의.
  • 메트릭과 분석 기능은 특정 도구에 상주하는 데이터가 아닌 TIM에 정의된다.

접근방식은 전술한 접근방식의 장점을 결합한다. 모든 도구와 아티팩트를 전체론적 접근방식으로 포괄하고, 데이터를 균질화하며, 시대에 뒤떨어진 대리인에 의해 야기되는 불일치의 위험을 방지한다. 단점은 이 접근방식이 다른(추적성) 툴에 의한 툴체인 확장을 의미한다는 점이다.

추적성 도구

많은 프로젝트에서 사람들은 추적가능성을 관리하기 위해 스프레드시트와 같은 사무용 도구를 사용한다. 이러한 도구는 수백 개의 요구 사항과 여러 명의 사용자가 프로젝트에서 작업하는 경우 오류가 발생하기 쉽다. 프로젝트의 효과적인 제어를 위해 전문 추적 도구를 사용할 수 있다.

참고 항목

참조

  1. ^ Systems and software engineering – Vocabulary. Iso/Iec/IEEE 24765:2010(E). 2010-12-01. pp. 1–418. doi:10.1109/IEEESTD.2010.5733835. ISBN 978-0-7381-6205-8.
  2. ^ IEEE Guide for Developing System Requirements Specifications. 1998 Edition IEEE STD 1233. 1998-12-01. pp. 1–36. doi:10.1109/IEEESTD.1998.88826. ISBN 978-0-7381-1723-2.
  3. ^ IEEE Guide for Information Technology - System Definition - Concept of Operations (ConOps) Document. IEEE STD 1362-1998. 1998-12-01. pp. 1–24. doi:10.1109/IEEESTD.1998.89424. ISBN 978-0-7381-1407-1.
  4. ^ a b c Gotel, O.C.Z.; Finkelstein, C.W. (April 1994). An analysis of the requirements traceability problem. Proceedings of IEEE International Conference on Requirements Engineering. pp. 94–101. CiteSeerX 10.1.1.201.7137. doi:10.1109/icre.1994.292398. ISBN 978-0-8186-5480-0. S2CID 5870868.
  5. ^ Gotel, Orlena; Cleland-Huang, Jane; Hayes, Jane Huffman; Zisman, Andrea; Egyed, Alexander; Grünbacher, Paul; Dekhtyar, Alex; Antoniol, Giuliano; Maletic, Jonathan (2012-01-01). Cleland-Huang, Jane; Gotel, Orlena; Zisman, Andrea (eds.). Software and Systems Traceability. Springer London. pp. 3–22. doi:10.1007/978-1-4471-2239-5_1. ISBN 9781447122388.
  6. ^ Hull, Elizabeth; Ken Jackson; Jeremy Dick (2005). Requirements Engineering (Second ed.). Springer. pp. 9–13, 131–151. ISBN 978-1-85233-879-4.
  7. ^ F.A.C. 및 Goguen J.A., "추적 요건을 위한 객체 지향 도구", IEEE 소프트웨어 1996, 13(2), 페이지 52-64
  8. ^ a b Mäder, P.; Jones, P. L.; Zhang, Y.; Cleland-Huang, J. (2013-05-01). "Strategic Traceability for Safety-Critical Projects". IEEE Software. 30 (3): 58–66. doi:10.1109/MS.2013.60. ISSN 0740-7459. S2CID 16905456.
  9. ^ Li, Yin; Juan Li; Ye Yang; Mingshu Li (2008). Requirement-Centric Traceability for Change Impact Analysis:A Case Study. Springer Berlin/Heidelberg. pp. 100–111. ISBN 978-3-540-79587-2.
  10. ^ Wiegers, Karl (2013). "Requirements Traceability: Links in the Requirements Chain, Part 1". jama. Retrieved 2016-12-14.
  11. ^ Wiegers, K.; Beatty, J. (2013). Software Requirements. Microsoft Press.
  12. ^ Bouillon, Elke; Mäder, Patrick; Philippow, Ilka (2013-04-08). Doerr, Joerg; Opdahl, Andreas L. (eds.). Requirements Engineering: Foundation for Software Quality. Lecture Notes in Computer Science. Springer Berlin Heidelberg. pp. 158–173. CiteSeerX 10.1.1.659.3972. doi:10.1007/978-3-642-37422-7_12. ISBN 9783642374210.
  13. ^ Mäder, Patrick; Egyed, Alexander (2015-04-01). "Do developers benefit from requirements traceability when evolving and maintaining a software system?". Empirical Software Engineering. 20 (2): 413–441. doi:10.1007/s10664-014-9314-z. ISSN 1382-3256. S2CID 2514618.
  14. ^ Rempel, Patrick; Mäder, Patrick (2016-01-01). "Preventing Defects: The Impact of Requirements Traceability Completeness on Software Quality". IEEE Transactions on Software Engineering. PP (99): 777–797. doi:10.1109/TSE.2016.2622264. ISSN 0098-5589. S2CID 1959772.
  15. ^ "open-DO Toward a cooperative and open framework for the development of certifiable software". www.open-do.org. Retrieved 2017-04-15.
  16. ^ a b c d e f Li, Y.; Maalej, W. (2012). Which Traceability Visualization Is Suitable in This Context? A Comparative Study. Springer. pp. 194–210.
  17. ^ Lerche, Felix (2019). "5 REASONS WHY A REQUIREMENTS TRACEABILITY MATRIX IS NOT ENOUGH".
  18. ^ Kannenberg, Andrew; Saiedian, Hossein (2009). "Why Software Requirements Traceability Remains a Challenge" (PDF). CrossTalk Magazine - the Journal of Defense Software Engineering.