요구사항관리

Requirements management

요구사항 관리는 요구사항의 문서화, 분석, 추적, 우선순위화 및 합의, 그리고 변화를 통제하고 관련 이해관계자와 소통하는 과정이다. 그것은 프로젝트 전체에 걸쳐 연속적인 과정이다. 요구사항은 프로젝트 결과(제품 또는 서비스)가 준수해야 하는 능력이다.

개요

요구사항 관리의 목적은 조직이 고객 및 내부 또는 외부 이해관계자의 요구와 기대를 문서화하고 검증하며 충족시키도록 보장하는 것이다.[1] 요구사항 관리는 조직의 목표와 제약사항을 분석하고 도출하는 것으로 시작한다. 요건 관리에는 요건에 대한 계획 수립 지원, 요건 및 그들과 협력하기 위한 조직 통합(요건에 대한 주의사항), 요건에 대해 전달되는 다른 정보와의 관계 및 요건에 대한 변경사항도 포함된다.

따라서 확립된 추적가능성은 준수, 완전성, 적용범위 및 일관성의 측면에서 회사와 이해관계자의 이익의 이행을 보고하기 위한 요구사항을 관리하는 데 사용된다. 또한 추적가능성은 요구사항 또는 기타 관련 요소(예: 기능 아키텍처와의 관계를 통한 기능적 영향)를 통한 변경의 영향을 이해하고 이러한 변경사항의 도입을 촉진하는 요건 관리의 일부로 변경 관리를 지원한다.[2]

요구사항 관리는 프로젝트 팀원과 이해관계자 간의 의사소통, 프로젝트 과정 전반에 걸쳐 요구사항 변경에 대한 조정을 포함한다.[3] 한 등급의 요구사항이 다른 등급보다 우선하는 것을 방지하려면 개발팀 구성원 간의 지속적인 의사소통이 중요하다. 예를 들어, 내부 애플리케이션을 위한 소프트웨어 개발에서 비즈니스는 사용자 요구사항을 무시하거나 사용 사례를 만들 때 사용자 요구사항이 처리되고 있다고 생각할 정도로 강력한 니즈를 가지고 있다.

추적성

주요 기사: 요구사항 추적성

요구사항 추적성은 요구사항의 수명을 문서화하는 것과 관련이 있다.[4] 각 요건의 기원을 추적할 수 있어야 하며, 따라서 추적가능성을 달성하기 위해 요건에 대한 모든 변경사항을 문서화해야 한다.[5] 구현된 기능을 배치하고 사용한 후 요구 사항의 사용도 추적할 수 있어야 한다.[5]

요구사항은 제품을 주문하는 비즈니스 담당자, 마케팅 관리자, 실제 사용자 등 다양한 출처에서 온다. 이 사람들은 모두 제품에 대한 요구 조건이 다르다. 요구사항 추적성을 사용하여 구현된 기능은 요구사항 도출 중 원하는 사용자 또는 그룹으로 추적할 수 있다. 예를 들어, 이것은 개발 프로세스 중에 요구조건의 우선순위를 [6]정하기 위해 사용될 수 있으며, 요구조건이 특정 사용자에게 얼마나 중요한지를 결정할 수 있다. 사용자 연구 결과 기능이 사용되지 않는 것으로 나타날 때 배치 후 사용할 수도 있어, 애초에 왜 그것이 필요했는지 알 수 있다.

요구사항 활동

개발 프로세스의 각 단계에는 핵심 요구사항 관리 활동과 방법이 있다. 예를 들어, 조사, 타당성, 설계, 시공 및 시험, 릴리스 단계와 함께 표준 5단계 개발 프로세스를 고려하십시오.

조사

조사에서는, 처음 3가지 등급의 요건이 사용자, 사업체, 개발팀으로부터 수집된다. 각 영역에서는 유사한 질문이 출제된다. 목표는 무엇인가, 제약조건은 무엇인가, 현재 시행 중인 툴이나 프로세스는 무엇인가 등이다. 이러한 요건을 잘 이해해야만 기능 요건을 개발할 수 있다.

일반적인 경우, 요구사항은 프로젝트 초기에 완전히 정의될 수 없다. 일부 요구사항은 단순히 추출되지 않았기 때문에 또는 작업 중인 내부 또는 외부 힘이 중간 사이클에서 프로젝트에 영향을 미치기 때문에 변경될 것이다.

조사 단계에서 인도할 수 있는 것은 팀의 모든 구성원이 승인한 요건 문서다. 나중에 이 문서는 개발의 두께에서 범위 크리프 또는 불필요한 변경을 방지하는 데 매우 중요할 것이다. 시스템이 발전함에 따라 각각의 새로운 기능은 새로운 가능성의 세계를 열어주기 때문에 요건 명세서는 팀을 원래의 비전에 고정시키고 범위 변화에 대한 통제된 논의를 허용한다.[citation needed]

많은 조직에서 여전히 요구사항 관리를 위해 문서만 사용하는 반면, 다른 조직에서는 소프트웨어 툴을 사용하여 요구사항 기준선을 관리한다. 이러한 도구는 요구사항이 데이터베이스에서 관리될 수 있도록 하며, 일반적으로 추적가능성을 자동화하는 기능을 가지고 있다(예: 부모와 자식 요구사항 간에 또는 시험사례와 요구사항 사이에 전자적 링크를 만들 수 있도록 허용함), 전자 기준선 생성, 버전 제어 및 변경 관리. 일반적으로 그러한 도구는 요구사항 데이터를 표준 문서 애플리케이션으로 내보내 규격 문서를 작성할 수 있는 내보내기 기능을 포함한다.[citation needed]

타당성

타당성 단계에서 요구사항의 원가는 결정된다. 사용자 요건의 경우, 현재 작업 비용은 새로운 시스템이 구축되면 미래 예상 비용과 비교된다. 이와 같은 질문: "현재 데이터 입력 오류로 인해 발생하는 비용은 무엇인가?" 또는 "현재 인터페이스의 운영자 오류로 인한 폐기 비용은 얼마인가?" 사실, 이러한 질문들이 조직 내 금융인들의 관심을 끌기 때문에 새로운 도구의 필요성이 종종 인식되고 있다.

비즈니스 비용에는 "이것에 대한 예산이 어느 부서에서 있는가?"가 포함될 것이다. "시장에서 신상품의 예상 수익률은 얼마인가?" "새롭고 사용하기 쉬운 시스템을 만들면 교육비와 지원비를 절감하는 데 있어 내부 수익률이 얼마나 될까?"

기술 비용은 소프트웨어 개발 비용 및 하드웨어 비용과 관련이 있다. "도구를 만들 적임자가 있는가?" "확대된 소프트웨어 역할을 지원하기 위해 새로운 장비가 필요한가?" 이 마지막 질문은 중요한 유형이다. 팀은 새로운 자동화된 도구가 사람들의 시간을 절약하기 위해 사용자로부터 시스템으로 일부 부담을 옮길 수 있는 충분한 처리 능력을 추가하는지 여부를 조사해야 한다.

이 질문은 또한 요구사항 관리에 대한 근본적인 요점을 지적한다. 인간과 도구는 시스템을 형성하는데, 도구가 컴퓨터나 컴퓨터의 새로운 응용 프로그램이라면 이 깨달음이 특히 중요하다. 인간의 정신은 데이터가 부족한 상태에서 추세를 병렬 처리하고 해석하는 데 탁월간단하다. CPU는 직렬 처리와 정확한 수학적 계산에 뛰어나다. 따라서 소프트웨어 프로젝트의 요구사항 관리 노력의 중요한 목표는 자동화 중인 작업이 적절한 프로세서에 할당되도록 하는 것이다. 예를 들어, "인간이 인터페이스의 그녀가 어디에 있는지 기억하게 하지 말라. 인터페이스가 항상 시스템 내 인간의 위치를 보고하도록 하십시오." 또는 "인간이 두 개의 화면에 같은 데이터를 입력하게 하지 말라. 시스템에 데이터를 저장하고 필요에 따라 두 번째 화면을 채우도록 하십시오."

타당성 단계에서 도출할 수 있는 것은 그 프로젝트의 예산과 일정이다.

디자인

비용이 정확하게 결정되고 얻을 수 있는 편익이 충분히 크다고 가정하면 프로젝트는 설계 단계로 진행할 수 있다. 설계에서 주요 요구사항 관리 활동은 설계 결과를 요구사항 문서와 비교하여 작업이 범위를 벗어나지 않는지 확인하는 것이다.

다시 말하지만, 융통성은 성공에 있어 가장 중요하다. 여기 실제로 잘 작동했던 중류의 범위 변화에 대한 고전적인 이야기가 있다. 80년대 초반의 포드 자동차 디자이너들은 휘발유 가격이 10년 말까지 갤런당 3.18달러에 달할 것으로 예상하고 있었다. 포드 타우루스의 디자인 중간중간 가격은 갤런당 1.50달러 정도에 집중되어 있었다. 설계팀은 기름값이 낮게 유지되면 더 크고, 더 편안하고, 더 강력한 자동차를 만들 수 있다고 판단해 차를 재설계했다. 타우러스 출시로 인해 이 새 차가 출시되었을 때 전국적인 판매 기록을 세웠는데, 주된 이유는 이 차가 너무 넓고 운전하기 편했기 때문이다.

그러나 대부분의 경우 원래 요건에서 그 정도까지 벗어나는 것은 효과가 없다. 따라서 요건 문서는 팀이 설계 변경에 대한 결정을 내리는 데 도움이 되는 중요한 도구가 된다.[7]

시공 및 시험

건설 및 시험 단계에서 요구사항 관리의 주요 활동은 작업 및 비용이 일정 및 예산 범위 내에서 유지되고 새로운 툴이 실제로 요구사항을 충족하는지 확인하는 것이다. 이 단계에서 사용되는 주요 도구는 시제품 제작과 반복 시험이다. 소프트웨어 애플리케이션의 경우, 사용자 인터페이스는 종이에 만들어지고 소프트웨어의 프레임워크가 구축되는 동안 잠재적 사용자들과 함께 시험될 수 있다. 이러한 시험의 결과는 사용자 인터페이스 설계 가이드에 기록되어 인터페이스를 개발할 준비가 되었을 때 설계 팀에게 전달된다. 이것은 그들의 시간을 절약하고 그들의 일을 훨씬 더 쉽게 만든다.

확인: 이 노력을 통해 요구사항이 올바르게 구현되었는지 검증한다. 검증 방법은 분석, 검사, 시험, 실증 등 4가지다. 예를 들어, 수치적 소프트웨어 실행 결과나 네트워크 시험의 통과는 요건이 충족되었다는 분석 증거를 제공한다. 공급업체 문서 또는 사양서에 대한 검사도 요구 사항을 검증한다. 실험실에서 소프트웨어를 실제로 시험하거나 입증하는 것 또한 요구 사항을 검증한다: 일반적으로 실험실의 일부(또는 시험 대상 시스템)가 아닌 시험 장비를 사용할 때 시험 형식의 검증이 발생한다. 단계와 예상 결과를 개략적으로 설명하는 포괄적인 시험 절차는 단계 수행의 결과로 보여지는 결과를 명확하게 식별한다. 단계 또는 단계 세트가 완료된 후, 마지막 단계의 예상 결과는 관찰된 내용을 호출한 다음 어떤 요구사항이나 요건을 검증했는지 식별한다(숫자로 식별). 요구사항 번호, 제목 및 용어는 시험 문서의 다른 위치에 함께 묶여 있다.

요구사항변경관리

어떤 소프트웨어 개발 프로젝트도 그 프로젝트에 대한 약간의 변경 없이는 완성되지 않을 것이다. 이러한 변화는 완제품을 사용할 것으로 예상되는 환경의 변화, 사업 변화, 규제 변화, 요구사항의 원래 정의의 오류, 기술의 한계, 보안 환경의 변화 등에서 기인할 수 있다. 요구사항변경관리의 활동에는 이해관계자로부터 변경요청 접수, 접수된 변경요청 기록, 이행의 타당성 및 프로세스 분석·결정, 변경요청 이행, 이행에 대한 품질보증, 변경요청 종결 등이 있다. 그런 다음 변경 요청 데이터를 취합, 분석하여 적절한 측정 기준을 도출하고 조직 지식 저장소에 통합한다.[8]

해제

요구사항 관리는 제품 출시로 끝나지 않는다. 그 시점부터 애플리케이션의 수용성에 대해 들어오는 데이터를 수집하여 다음 세대 또는 릴리스의 조사 단계로 공급한다. 이리하여 그 과정은 다시 시작된다.

툴링

요구사항 관리를 지원하는 도구를 확보하는 것은 사소한 문제가 아니며 더 광범위한 프로세스 개선 이니셔티브의 일환으로 수행될 필요가 있다. 한 번 프로젝트에 취득하여 설치한 툴이 모든 요건 관리 관련 요구를 해결할 수 있다는 것은 오래 전부터 인식되어 왔다. 그러나 요건 관리를 지원하는 도구의 구입이나 개발은 비용이 많이 드는 결정이 될 수 있다. 조직은 값비싼 지원 계약에 부담을 느낄 수 있으며, 불균형적인 노력이 도구 사용 방법을 학습하고 특정 요구를 해결하도록 구성하는 방향으로 잘못 연결될 수 있으며, 잘못된 의사결정을 초래할 수 있는 부적절한 사용이 발생할 수 있다. 조직은 개발 프로세스와 툴링의 광범위한 맥락 안에서 특정 요구를 지원하는 툴에 대한 결정을 내리기 위해 증분 프로세스를 따라야 한다.[9] 도구는 요구사항 추적가능성에 제시되어 있다.

참고 항목

참조

  1. ^ Stellman, Andrew; Greene, Jennifer (2005). Applied Software Project Management. O'Reilly Media. ISBN 978-0-596-00948-9. Archived from the original on 2015-02-09.
  2. ^ "Requirements management". UK Office of Government Commerce. Retrieved 2009-11-10.
  3. ^ A Guide to the Project Management Body of Knowledge (4th ed.). Project Management Institute. 2008. ISBN 978-1-933890-51-7.
  4. ^ 고텔, 오, 핀켈슈타인, A 제1회 요구사항 엔지니어링 국제회의의 요구사항 추적성 문제 분석, 1994, 페이지 94-101
  5. ^ a b 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. ^ Rempel, Patrick; Mäder, Patrick (2015-03-23). Fricker, Samuel A.; Schneider, Kurt (eds.). Requirements Engineering: Foundation for Software Quality. Lecture Notes in Computer Science. Springer International Publishing. pp. 81–97. doi:10.1007/978-3-319-16101-3_6. ISBN 9783319161006.
  7. ^ Ralph, P, 그리고 Wand, Y. 디자인 개념의 형식적 정의를 위한 제안. In, Lytinen, K, Loucopoulos, P, Mylopoulos, J, and Robinson, W, (eds), 설계 요구사항 엔지니어링: 10년 관점: Springer-Verlag, 2009, 페이지 103-136
  8. ^ Chemuturi, M. (2013). Requirements Engineering and Management for Software Development Projects. doi:10.1007/978-1-4614-5377-2. ISBN 978-1-4614-5376-5. S2CID 19818654.
  9. ^ Gotel, Orlena; Mäder, Patrick (2012-01-01). Cleland-Huang, Jane; Gotel, Orlena; Zisman, Andrea (eds.). Software and Systems Traceability. Springer London. pp. 43–68. doi:10.1007/978-1-4471-2239-5_3. ISBN 9781447122388.

추가 읽기

외부 링크