요건 엔지니어링

Requirements engineering

Requirements Engineering(RE;[1] 요건 엔지니어링)은 엔지니어링 설계 프로세스에서 요건을[2] 정의, 문서화 및 유지하는 프로세스입니다.시스템 엔지니어링 및 소프트웨어 엔지니어링에서 공통적인 역할입니다.

용어 요건 공학의 첫번째 사용이 1964년에 회의 종이"유지 관리, 유지 관리성 및 시스템 요구 사항 공학"[3]에 일반에 대한 IEEE컴퓨터 학회 tutorial[4]의 1997년 3월 발간으로 1990년 후반과 r에 관한 컨퍼런스 시리즈가 이루어질 때까지 오지 않았다equire국제요건공학회의(International Requirements Engineering Conference)로 발전한 Ments 엔지니어링.

워터폴 [5]모델에서는 개발 프로세스의 첫 단계로 요구사항 엔지니어링이 제시됩니다.소프트웨어용 RUP(Rational Unified Process)를 포함한 이후의 개발 방법에서는 요건 엔지니어링이 시스템 수명 동안 계속된다고 가정합니다.

시스템 엔지니어링 프랙티스의 하위 기능인 요건 관리는 International Council on Systems Engineering(INCOSE) 매뉴얼에도 기재되어 있습니다.

활동.

요건 엔지니어링과 관련된 활동은 개발 중인 시스템의 유형과 [6]관련된 조직의 특정 관행에 따라 매우 다양합니다.여기에는 다음이 포함됩니다.

  1. 요건 개시 또는 요건 도출– 개발자와 이해관계자가 충족합니다.개발자와 이해관계자는 소프트웨어 제품에 대한 요구와 요구에 대해 질문을 받습니다.
  2. 요건 분석 및 협상– 요건을 특정하고(개발이 반복되는 경우 신규 요건을 포함), 이해관계자와의 상충을 해결합니다.필기 도구와 그래픽 도구(후자는 설계 단계에서 일반적으로 사용되지만 일부는 이 단계에서 유용하게 사용됨)를 모두 보조 도구로 성공적으로 사용합니다.서면 분석 툴의 예: 사용 사례 및 사용자 사례.그래픽 도구의 예: UML[7] 및 LML.
  3. 시스템 모델링 – 일부 엔지니어링 분야(또는 특정 상황)에서는 제품을 완전히 설계하고 모델링한 후 구축 또는 제조해야 합니다.따라서 사전에 설계 단계를 수행해야 합니다.예를 들어, 건물의 청사진은 계약을 승인하고 서명하기 전에 상세하게 작성되어야 합니다.Lifecycle Modeling Language를 사용하여 시스템 모델을 파생하는 필드도 많지만 UML을 사용하는 필드도 있습니다.주의:소프트웨어 엔지니어링과 같은 많은 분야에서 대부분의 모델링 활동은 요구사항 엔지니어링 활동이 아닌 설계 활동으로 분류됩니다.
  4. 요건 사양 – 요건은 요건 사양(RS)이라고 하는 정식 아티팩트에 기재되어 있습니다.이 아티팩트는 검증 후에만 공식화됩니다.RS에는 필요에 따라 기입 정보와 그래픽(모델) 정보를 모두 포함할 수 있습니다.예: 소프트웨어 요건 사양(SRS)
  5. 요건 검증 – 문서화된 요건과 모델이 일관되고 이해관계자의 요구를 충족하는지 확인합니다.최종 초안이 검증 과정을 통과한 경우에만 RS가 공식화됩니다.
  6. 요건관리 – 도입 후 요건과 관련된 모든 액티비티를 관리, 시스템 개발 시 감독, 사용 후까지 관리(변경, 확장 등)

이러한 활동들은 실제로 상당한 인터리빙이 있지만, 때로는 연대기 단계로 제시되기도 한다.

요건 엔지니어링은 소프트웨어 프로젝트의 [8]성공에 분명히 기여하는 것으로 나타났습니다.

문제

독일의 한 제한적인 연구는 요구사항 엔지니어링 구현에서 발생할 수 있는 문제를 제시하고 응답자들에게 실제 문제라는 데 동의하는지 물었다.결과는 일반화할 수 있는 것으로 제시되지 않았지만, 주요 인식 문제는 불완전한 요건, 이동 목표물 및 시간 복싱이며, 통신 결함, 추적성 부족, 용어 문제 및 불명확한 [9]책임이라는 점을 시사했다.

비판

요건 엔지니어링의 중요한 측면인 문제 구조화는 설계 성능을 [10]저하시킬 것으로 추측되고 있습니다.일부 연구에 따르면 요건 엔지니어링 프로세스에 결함이 있어 요건이 존재하지 않는 상황이 발생할 경우 설계 결정을 요건으로 잘못 기재한 환상과는 무관하게 소프트웨어 요건이 생성될 수 있습니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ Nuseibeh, B.; Easterbrook, S. (2000). Requirements engineering: a roadmap (PDF). ICSE'00. Proceedings of the conference on the future of Software engineering. pp. 35–46. CiteSeerX 10.1.1.131.3116. doi:10.1145/336512.336523. ISBN 1-58113-253-0.
  2. ^
  3. ^ Dresner, K. H. Borchers (1964). Maintenance, maintainability, and system requirements engineering. SAE World Congress & Exhibition 1964. SAE Technical Paper 640591. doi:10.4271/640591.
  4. ^ Thayer, Richard H.; Dorfman, Merlin, eds. (March 1997). Software Requirements Engineering (2nd ed.). IEEE Computer Society Press. ISBN 978-0-8186-7738-0.
  5. ^ Royce, W. W. (1970). Managing the Development of Large Software Systems: Concepts and Techniques (PDF). ICSE'87. Proceedings of the 9th international conference on Software Engineering. pp. 1–9.
  6. ^ Sommerville, Ian (2009). Software Engineering (9th ed.). Addison-Wesley. ISBN 978-0-13-703515-1.
  7. ^ "Uncovering Requirements With UML Class Diagrams Part 1". tynerblain.com. March 7, 2008. Retrieved March 14, 2018.
  8. ^ Hofmann, H.F.; Lehner, F. (2001). "Requirements engineering as a success factor in software projects". IEEE Software. 18 (4): 58–66. doi:10.1109/MS.2001.936219. ISSN 0740-7459.
  9. ^ Méndez Fernández, Daniel; Wagner, Stefan (2015). "Naming the pain in requirements engineering: A design for a global family of surveys and first results from Germany". Information and Software Technology. 57: 616–643. arXiv:1611.04976. doi:10.1016/j.infsof.2014.05.008. S2CID 1924926.
  10. ^ Ralph, Paul; Mohanani, Rahul (May 2015). "Is Requirements Engineering Inherently Counterproductive?". IEEE. doi:10.13140/2.1.3831.6321. {{cite journal}}:Cite 저널 요구 사항 journal=(도움말)
  11. ^ Ralph, P. (September 2013). "The illusion of requirements in software development". Requirements Engineering. 18 (3): 293–296. arXiv:1304.0116. Bibcode:2013AIPC.1516..293R. doi:10.1007/s00766-012-0161-4. S2CID 11499083.

외부 링크