요구사항
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
1. 개요
요구사항은 다양한 이해관계자의 관점에서 시스템 개발에 필요한 사항을 정의하는 것이다. 요구사항은 시스템 아키텍처, 비즈니스, 사용자, 기능, 비기능, 구현, 규제 요구사항 등 여러 유형으로 분류되며, 시스템 공학 및 소프트웨어 공학에서 중요한 역할을 한다. 좋은 요구사항은 단일성, 완전성, 일관성, 추적성, 명확성 등의 특징을 가지며, 요구사항 분석 및 관리를 통해 품질을 향상시킨다. 요구사항 변경 관리, 다양한 분류 체계, 프로세스 부패 등의 문제와 과제가 존재하며, 한국의 중소기업, 4차 산업혁명, 정부 정책 등 특수한 상황을 고려해야 한다.
요구사항(Requirement)이라는 용어는 1960년대부터 소프트웨어 공학 분야에서 사용되어 왔다.[2]
좋은 요구사항은 여러 저자에 의해 다르게 정의되지만, 일반적으로 인정되는 특징들이 있다.[8][9] 이러한 특징들은 요구사항의 품질을 평가하고, 최종 제품이 사용자의 요구를 충족시키는지 확인하는 데 중요한 역할을 한다.
2. 요구사항의 정의 및 유형
IIBA(BABOK)의 ''Business Analysis Body of Knowledge® 가이드'' 버전 2에 따르면,[3] 요구사항은 다음과 같다.
# 문제를 해결하거나 목표를 달성하기 위해 이해 관계자가 필요로 하는 조건 또는 능력.
# 계약, 표준, 사양 또는 기타 공식적으로 부과된 문서를 충족하기 위해 솔루션 또는 솔루션 구성 요소가 충족하거나 갖춰야 하는 조건 또는 능력.
# (1) 또는 (2)와 같은 조건 또는 능력의 문서화된 표현.
이 정의는 IEEE 610.12-1990: IEEE 표준 소프트웨어 공학 용어집을 기반으로 한다.[4]
요구사항은 일반적으로 개발 진행의 여러 단계에서 생성되는 유형으로 분류되며, 그 분류 체계는 사용되는 모델에 따라 달라진다. 국제 비즈니스 분석 연구소의 비즈니스 분석 지식 체계(Business Analysis Body of Knowledge)에서는 다음과 같이 요구사항을 분류한다.[5]
시스템 공학에서 요구사항 명세는 시스템이 무엇을 해야 하는지를 기술한 것이다. 완성된 시스템이 실행 가능해야 함을 지정하며, 기능을 어느 정도 잘 실행하는지를 나타내는 "비기능 요구 사항 명세", "성능 요구 사항 명세", "서비스 품질 요구 사항 명세" 등으로 불리는 경우도 있다.
요구사항의 집합은 필요한 시스템의 특징과 기능을 정의한다. 좋은 요구사항 명세는 "어떻게" 시스템을 구현해야 하는지를 기술하지 않고, 설계자에게 판단을 맡긴다.
소프트웨어 공학에서도 요구사항 명세에 기술해야 할 내용은 거의 같지만, 소프트웨어에만 초점이 맞춰져 있다.
2. 1. 비즈니스 요구사항
조직의 목표, 목적 또는 필요에 대한 상위 수준의 진술이다. 일반적으로 조직이 실현하고자 하는 기회 또는 해결하려는 문제를 설명하며, 사업 타당성 분석 단계에서 중요한 역할을 한다.[5]
2. 2. 사용자 (이해관계자) 요구사항
특정 이해관계자 또는 이해관계자 그룹의 필요에 대한 중간 수준의 진술이다. 일반적으로 누군가가 의도된 해결책과 어떻게 상호 작용하고 싶은지를 설명하며, 상위 수준의 비즈니스 요구사항과 보다 자세한 솔루션 요구사항 사이의 중간 지점 역할을 한다.[5]
2. 3. 기능 요구사항
기능 요구사항은 시스템이 수행해야 할 기능, 동작, 정보 처리에 대한 상세한 설명이다. 사용자가 시스템을 통해 수행하고자 하는 작업을 구체적으로 명시한다. 일반적으로 솔루션에 필요한 기능, 동작 및 정보에 대한 자세한 내용을 담고 있으며, 텍스트 서식 지정, 숫자 계산, 신호 변조 등이 그 예시이다.[5] "기능"이라고도 부른다.[5]
소프트웨어 공학에서 기능 요구사항은 시스템의 기능이나 시스템이 해야 할 일을 기술한다. "누가 무엇을 하는가"의 형태로 작성될 수 있는데, 예를 들면 "계약자는 X년 Y월 Z일까지 제품을 제공한다"와 같다.
2. 4. 비기능 요구사항
시스템의 성능, 보안, 사용성, 유지보수성 등 품질 속성에 대한 요구사항이다. 시스템이 기능을 어떻게 수행해야 하는지에 대한 제약 조건이나 품질 기준을 정의한다.[7] 소프트웨어 공학에서 요구사항은 일반적으로 다음 세 가지로 분류된다.
# 기능 요구사항 - 시스템의 기능이나 시스템이 해야 할 일을 기술한다.
# 비기능 요구사항 - 시스템이 갖춰야 할 속성(예: 성능, 가용성, 접근성 등)을 기술한다.
# 제약 조건 - 개발에 대한 일정한 조건. (예: 시스템이 동작해야 하는 운영체제를 지정하거나 시스템 구현에 사용해야 하는 프로그래밍 언어를 지정.)
시스템 공학에서 요구 사항 명세는 시스템이 무엇을 해야 하는지를 기술한 것이다. 이러한 종류의 요구 사항 명세는 완성된 시스템이 실행 가능해야 함을 지정한다. 다른 요구 사항 명세 형식으로 시스템 자체에 관한 기술을 하는 경우도 있으며, 기능을 어느 정도 잘 실행하는지를 나타낸다. 후자의 요구 사항 명세는 "비기능 요구 사항 명세", "성능 요구 사항 명세", "서비스 품질 요구 사항 명세" 등으로 불린다. (예: 가용성, 검증 가능성, 유지 보수성, 사용 편의성 등에 관한 기술)[7]
요구 사항의 집합에 의해 필요한 시스템의 특징과 기능이 정의된다. 좋은 요구 사항 명세는 일반적으로 "어떻게" 시스템을 구현해야 하는지를 기술하지 않고, 그러한 설계상의 판단은 설계자에게 맡긴다.
2. 5. 시스템 아키텍처 요구사항
아키텍처 요구사항은 시스템 구조와 시스템 행동, 즉 시스템의 시스템 아키텍처가 통합되어 무엇을 해야 하는지를 설명한다. 소프트웨어 공학에서, 이것은 소프트웨어 시스템의 아키텍처에 측정 가능한 영향을 미치는 요구사항으로 정의되는 아키텍처적으로 중요한 요구사항이라고 불린다.[6]
2. 6. 구현 (전환) 요구사항
구현 (전환) 요구사항은 일반적으로 기업의 현재 상태에서 원하는 미래 상태로 전환하는 데 필요한 기능 또는 동작에 대한 자세한 진술이지만, 그 이후에는 더 이상 필요하지 않다. 예를 들어 채용, 역할 변경, 교육, 한 시스템에서 다른 시스템으로의 데이터 마이그레이션 등이 있다.[5]
2. 7. 규제 요구사항
법률(연방, 주, 지방 자치 단체 또는 지역), 계약(약관) 또는 정책(회사, 부서 또는 프로젝트 수준)에 의해 정의된 요구사항이다.[2]
2. 8. 제품 및 프로세스 요구사항
제품 요구사항은 시스템 또는 제품의 속성을 규정한다. 프로세스 요구사항은 개발 조직에서 수행해야 하는 활동을 규정한다. 예를 들어, 프로세스 요구사항은 따라야 하는 방법론과 조직이 준수해야 하는 제약 조건을 지정할 수 있다.[2]
제품 및 프로세스 요구사항은 밀접하게 연결되어 있다. 제품 요구사항은 프로세스 요구사항을 지원하는 데 필요한 자동화를 지정하고, 프로세스 요구사항은 제품 요구사항을 지원하는 데 필요한 활동을 지정한다. 예를 들어, 최대 개발 비용 요구사항(프로세스 요구사항)은 최대 판매 가격 요구사항(제품 요구사항)을 달성하는 데 도움이 되도록 부과될 수 있다. 제품의 유지 관리 가능성에 대한 요구사항(제품 요구사항)은 종종 특정 개발 스타일(예: 객체 지향 프로그래밍), 스타일 가이드 또는 검토/검사 프로세스(프로세스 요구사항)를 따르도록 요구사항을 부과하여 해결된다.[2]
3. 좋은 요구사항의 특징
특징 설명 단일성 (응집성) 요구사항은 단 하나의 사항만을 다룬다. 완전성 요구사항은 빠진 정보 없이 한 곳에 완전히 기술되어 있다. 일관성 요구사항은 다른 요구사항과 모순되지 않으며, 모든 권위 있는 외부 문서와 완전히 일치한다. 비-결합형 (원자성) 요구사항은 접속사를 포함하지 않는 원자적 단위이다. 추적성 요구사항은 이해 관계자가 제시하고 권위 있게 문서화한 비즈니스 요구의 전부 또는 일부를 충족한다. 최신성 요구사항은 시간이 지나도 구식이 되지 않아야 한다. 모호성 제거 요구사항은 기술 용어, 약어 (요구사항 문서의 다른 곳에서 정의되지 않는 한) 또는 기타 난해한 어구를 사용하지 않고 간결하게 기술되어야 한다. 중요도 명시 요구사항은 중요도 수준을 명시해야 한다. 검증 및 유효성 검사 요구사항의 구현은 검사, 시연, 테스트 (계측) 또는 분석 (유효한 모델링 및 시뮬레이션 포함)과 같은 기본적인 방법을 통해 확인할 수 있다.
이론적으로 좋은 요구사항 명세는 필요성, 간결성, 달성 가능성 등의 특징을 갖는다.
요구사항의 품질을 높이기 위해 고려해야 할 다른 속성들도 많이 있다. 예를 들어, 요구사항이 데이터 무결성 규칙을 따른다면 정확성과 유효성도 중요한 속성이 된다.
3. 1. 단일성 (응집성)
요구사항은 단 하나의 사항만을 다룬다.[8][9]
3. 2. 완전성
요구사항은 빠진 정보 없이 한 곳에 완전히 기술되어야 한다.[8][9]
| 특징 | 설명 |
|---|---|
| 완전성 | 요구사항은 빠진 정보 없이 한 곳에 완전히 기술되어 있다. |
이론적으로 좋은 요구사항 명세는 완전해야 한다. 즉, 하나의 문서에 모든 내용이 담겨 있으며, 독자가 의미를 파악하기 위해 다른 문서를 참조할 필요가 없다.
3. 3. 일관성
요구사항은 다른 요구사항과 모순되지 않으며, 모든 권위 있는 외부 문서와 완전히 일치해야 한다.[8][9]이론적으로 좋은 요구사항 명세는 다음과 같은 특징을 갖는다.
- 일관성 - 각 요구사항 간에 모순이 없고, 다른 관련 요구사항 명세와도 모순되지 않는다. 또한, 용어 사용도 일관적이다.
3. 4. 원자성
요구사항은 더 이상 분리될 수 없는 최소 단위로 작성되어야 한다. 즉, 접속사를 포함하지 않는 원자적이어야 한다.[8][9] 예를 들어, "우편번호 필드는 미국 ''및'' 캐나다 우편번호를 검증해야 한다"는 요구사항은 다음 두 가지 개별 요구사항으로 분리해야 한다.- "우편번호 필드는 미국 우편번호를 검증해야 한다."
- "우편번호 필드는 캐나다 우편번호를 검증해야 한다."
3. 5. 추적성
요구사항은 이해 관계자가 제시하고 권위 있게 문서화한 비즈니스 요구의 전부 또는 일부를 충족해야 한다.[8][9]추적성은 요구사항 집합이 요구사항을 충족하는지(더도 덜도 아닌) 확인하는 것이다.
3. 6. 최신성
요구사항은 시간이 지나도 구식이 되지 않아야 한다.[8][9]3. 7. 명확성 (모호성 제거)
요구사항은 기술 용어, 약어(요구사항 문서의 다른 곳에서 정의되지 않는 한) 또는 기타 난해한 어구를 사용하지 않고 간결하게 기술되어야 한다. 주관적인 의견이 아닌 객관적인 사실을 표현하며, 단 하나의 해석만 가능해야 한다. 모호한 주어, 형용사, 전치사, 동사 및 주관적인 구문은 피해야 하며, 부정문과 복합문도 피해야 한다.[8][9]이론적으로 좋은 요구사항 명세는 여러 가지로 해석될 수 있는 표현을 사용하지 않아 명확해야 한다.[8][9]
검증 가능성은 일종의 명확성에 기반하며 필수적이지만, 다른 중요한 문제가 소홀해질 위험도 있다. 요구 명세가 전체적으로 틀렸더라도 여전히 검증 가능한 경우도 있다. 검증 가능하다는 것이 그 요구 명세가 옳다는 것을 보증하지는 않는다. 또한 필요한 사항이 빠져 있었을 경우, 검증 가능성은 그것에 대해 아무것도 보증할 수 없다. 분석, 검사, 리뷰를 통해 그러한 문제의 일부를 발견할 수 있더라도, 요구 명세의 타당성 문제는 크며, 요구 공학의 연구 주제 중 하나이다.[8][9]
3. 8. 중요도 명시
많은 요구사항은 이해 관계자가 정의한 특성을 나타내며, 이러한 특성이 없으면 주요 결함 또는 치명적인 결함이 발생한다. 다른 요구사항은 시간과 예산이 허락하는 경우 구현될 수 있는 기능을 나타낸다. 요구사항은 중요도 수준을 명시해야 한다.[8][9]3. 9. 검증 및 유효성 검사 가능성
요구사항은 실제로 구현되었는지, 그리고 이해관계자의 요구를 충족하는지 검증할 수 있는 방법이 제시되어야 한다. 구현은 검사, 시연, 테스트(계측) 또는 분석(유효한 모델링 및 시뮬레이션 포함)과 같은 기본적인 방법을 통해 확인할 수 있다.[8]모든 요구사항은 검증 가능해야 한다. 가장 일반적인 방법은 테스트를 이용하는 것이다. 그렇지 않은 경우 다른 검증 방법(예: 분석, 시연, 검사 또는 설계 검토)을 사용해야 한다.[8]
특정 요구사항은 그 구조상 검증할 수 없다. 시스템이 특정 속성을 ''절대'' 또는 ''항상'' 나타내야 한다고 명시하는 요구사항이 그러하다. 이러한 요구사항을 제대로 테스트하려면 무한한 테스트 사이클이 필요하다. 따라서 이러한 요구사항은 검증 가능하도록 다시 작성해야 한다.
소프트웨어 수준에서 검증할 수 없는 비기능적 요구사항은 여전히 고객의 의도를 문서화하는 형태로 유지해야 한다. 그러나 이러한 요구사항은 이를 충족하는 실질적인 방법으로 결정된 프로세스 요구사항으로 추적될 수 있다. 예를 들어, 백도어가 없어야 한다는 비기능적 요구사항은 페어 프로그래밍을 사용하는 프로세스 요구사항으로 대체하여 충족할 수 있다. 다른 비기능적 요구사항은 다른 시스템 구성 요소로 추적되며 해당 수준에서 검증된다. 예를 들어, 시스템 신뢰성은 종종 시스템 수준에서 분석을 통해 검증된다.
4. 요구사항 분석 및 관리
요구사항 분석은 요구사항의 모호성, 불완전성, 불일치 등의 문제를 해결하고, 요구사항을 명확하고 구체적으로 만드는 과정이다. 소프트웨어 공학 및 시스템 공학에서 요구사항 분석은 필수적인 단계로, 프로젝트의 성공적인 완수를 위한 중요한 기반이 된다.
요구사항은 모호성, 불완전성 및 비일관성의 문제가 발생하기 쉽다.[11][12] 이러한 문제를 해결하기 위해 엄격한 검토와 같은 기술이 사용된다. 요구사항 단계에서 문제를 해결하면 제품 개발 후반 단계에서 발견될 때보다 수정 비용이 일반적으로 수십 배 적게 든다.
요구사항 분석 시 고려해야 할 엔지니어링 트레이드 오프는 다음과 같다.
- 너무 모호하거나 너무 상세하여 생산하는 데 시간이 오래 걸려 완료되면 때로는 쓸모없게 되는 요구사항
- 사용 가능한 구현 옵션을 제한하는 요구사항
- 생산 비용이 많이 드는 요구사항
애자일 접근 방식은 요구사항을 높은 수준으로 기준선화하고 적시 또는 "마지막 책임 순간" 기준으로 세부 사항을 상세화하여 이러한 문제를 극복한다.
4. 1. 요구사항 분석
수집된 요구사항은 중복, 누락, 충돌 여부를 확인하고, 요구사항 간의 관계를 파악하기 위해 분석되어야 한다.[10] 요구사항 분석은 모호성, 불완전성, 비일관성 문제를 해결하기 위한 활동이다.[11][12] 이러한 문제는 소프트웨어 개발 초기 단계에서 해결하는 것이 비용 효율적이다.엄격한 검토는 요구사항의 문제를 해결하는 데 도움이 된다. 요구사항 단계에서 문제를 해결하면 제품 개발 후반 단계에서 발견될 때보다 수정 비용이 일반적으로 수십 배 적게 든다.
요구사항 분석 시 고려해야 할 엔지니어링 트레이드 오프는 다음과 같다.
- 너무 모호한 요구사항과 너무 상세하여 생산하는 데 시간이 오래 걸려 완료되면 때로는 쓸모없게 되는 요구사항
- 사용 가능한 구현 옵션을 제한하는 요구사항
- 생산 비용이 많이 드는 요구사항
애자일 접근 방식은 요구사항을 높은 수준으로 기준선화하고 적시 또는 "마지막 책임 순간" 기준으로 세부 사항을 상세화하여 이러한 문제를 극복한다.
4. 2. 요구사항 명세
시스템 공학에서 요구사항 명세는 시스템이 무엇을 해야 하는지를 기술한 것이다. 이러한 종류의 요구사항 명세는 완성된 시스템이 실행 가능해야 함을 지정한다. 다른 요구사항 명세 형식으로 시스템 자체에 관한 기술을 하는 경우도 있으며, 기능을 어느 정도 잘 실행하는지를 나타낸다. 후자의 요구사항 명세는 "비기능 요구사항 명세", "성능 요구사항 명세", "서비스 품질 요구사항 명세" 등으로 불린다. 예를 들어, 가용성, 검증 가능성, 유지 보수성, 사용 편의성 등에 관한 기술이 그것에 포함된다.요구사항의 집합에 의해 필요한 시스템의 특징과 기능이 정의된다. 좋은 요구사항 명세는 일반적으로 "어떻게" 시스템을 구현해야 하는지를 기술하지 않고, 그러한 설계상의 판단은 설계자에게 맡긴다.
소프트웨어 공학에서도 요구사항 명세에 기술해야 할 내용은 거의 같지만, 소프트웨어에만 초점이 맞춰져 있다는 점이 다르다. 요구사항 명세는 모호하고 부정확하며 일관성이 없는 경향이 있다. 이러한 문제에 대처하기 위해 엄격한 인스펙션과 같은 기술이 제시되어 왔다. 모호함, 불완전함, 불일치를 요구사항 명세에서 제거함으로써, 개발 과정의 후반부에서 유사한 문제가 발견될 때보다 훨씬 적은 비용이 든다. 요구 분석은 이러한 문제에 대응하기 위한 노력이다.
요구사항 명세의 상세 정도에는 다음과 같은 공학적 트레이드 오프가 있다.
- 더 상세한 요구사항 명세는 작성에 더 많은 시간이 소요된다.
- 더 상세한 요구사항 명세는 선택 가능한 구현 옵션을 제한하는 경향이 있다.
- 더 상세한 요구사항 명세는 작성에 더 많은 비용이 소요된다.
요구사항은 시스템이 사용되는 영역에 적합한 비즈니스 규칙에 따라 시스템의 생성/수정을 지시하는 형태로 작성된다. 시스템은 해당 사업의 비즈니스 영역에 올바르게 대응해야 한다. 요구사항의 일반적인 형식은 "누가 무엇을 하는가"와 같다. 예를 들어 "계약자는 X년 Y월 Z일까지 제품을 제공한다"와 같은 형태이다.
4. 3. 요구사항 검증 및 유효성 확인
모든 요구사항은 검증 가능해야 하며, 가장 일반적인 방법은 테스트이다. 그렇지 않은 경우 분석, 시연, 검사 또는 설계 검토와 같은 다른 검증 방법을 사용해야 한다.[10]특정 요구사항은 그 구조상 검증할 수 없다. 예를 들어 시스템이 특정 속성을 '절대' 또는 '항상' 나타내야 한다는 요구사항은 무한한 테스트가 필요하므로 검증 가능하도록 다시 작성해야 한다. 소프트웨어 수준에서 검증할 수 없는 비기능적 요구사항은 고객의 의도를 문서화하는 형태로 유지해야 하지만, 이를 충족하는 실질적인 방법으로 결정된 프로세스 요구사항으로 추적될 수 있다. 예를 들어, 백도어가 없어야 한다는 비기능적 요구사항은 페어 프로그래밍을 사용하는 프로세스 요구사항으로 대체할 수 있다. 다른 비기능적 요구사항은 다른 시스템 구성 요소로 추적되며 해당 수준에서 검증된다. 예를 들어, 시스템 신뢰성은 시스템 수준에서 분석을 통해 검증된다. 복잡한 안전 요구사항을 갖는 항공 전자 소프트웨어는 DO-178B 개발 프로세스를 따라야 한다.[11][12]
요구사항 엔지니어링은 프로젝트의 타당성 조사 또는 '개념 분석 단계'와 요구사항 수집 (이해 관계자의 요구사항 수집, 이해, 검토 및 명확화) 및 분석(일관성 및 완전성 확인), 명세 (요구사항 문서화) 및 유효성 검사 (명시된 요구사항이 올바른지 확인)를 포함한다.
요구사항은 모호성, 불완전성 및 비일관성의 문제가 발생하기 쉽다. 엄격한 검토와 같은 기술은 이러한 문제를 해결하는 데 도움이 된다. 요구사항 단계에서 해결할 수 있는 모호성, 불완전성 및 비일관성은 제품 개발의 후반 단계에서 동일한 문제가 발견될 때보다 수정 비용이 일반적으로 수십 배 적게 든다.
너무 모호한 요구사항과 너무 상세하여 생산하는 데 시간이 오래 걸려 완료되면 때로는 쓸모없게 되는 요구사항, 사용 가능한 구현 옵션을 제한하는 요구사항, 생산 비용이 많이 드는 요구사항 사이에서 엔지니어링 트레이드 오프를 고려해야 한다.
애자일 접근 방식은 이러한 문제를 극복하기 위한 방법으로 발전했으며, 요구사항을 높은 수준으로 기준선화하고 적시 또는 "마지막 책임 순간" 기준으로 세부 사항을 상세화한다.
4. 4. 요구사항 변경 관리
요구사항은 일반적으로 시간이 지남에 따라 변경된다. 정의되고 승인된 요구사항은 변경 관리 하에 있어야 한다. 많은 프로젝트에서 시스템이 완료되기 전에 요구사항이 변경된다. 이는 부분적으로 컴퓨터 소프트웨어의 복잡성과 사용자가 실제로 보기 전에는 무엇을 원하는지 알지 못한다는 사실 때문이며, 이러한 요구사항의 특성으로 인해 요구사항 관리 연구 및 실천이 이루어졌다.범위 변경은 시간이 지남에 따라 요구 사항이 변경되면서 발생할 수 있다. 요구사항 관리에서 요구 사항의 변경은 허용되지만, 적절하게 추적되지 않거나, 선행 단계(비즈니스 목표, 사용자 요구 사항)가 추가적인 감독에 의해 제한되지 않거나, 비용 및 잠재적인 프로그램 실패로 처리되지 않으면, 요구 사항 변경이 쉽고 발생할 가능성이 높다. 개발자가 작업을 수행하는 속도보다 요구 사항 변경이 더 빠르게 발생하면, 결과적으로 '뒤로' 돌아가는 노력이 발생하기 쉽다.
5. 요구사항 관리의 쟁점 및 과제
요구사항 관리는 여러 이해관계자가 참여하고, 기술적으로 복잡하며, 환경 변화에 민감하여 다양한 어려움에 직면한다.
- 상충되는 표준: IEEE와 IIBA 등 주요 단체들이 제시하는 요구사항 관리 표준이 서로 달라 혼란을 야기할 수 있다.[1]
- 소프트웨어 요구사항의 필요성 및 영향 논쟁: 일부 연구는 요구사항 명시가 창의성과 설계 성능을 저해할 수 있다고 주장한다.[14] 반면 애자일 소프트웨어 개발 방법론은 변화하는 요구사항을 수용하며, 익스트림 프로그래밍과 같이 사용자 스토리를 활용하여 요구사항을 비공식적으로 기술하고, 인수 테스트를 통해 검증한다.
- 요구사항 변경 (Requirements creep): 범위 변경은 시간이 지남에 따라 요구사항이 변경되면서 발생할 수 있다. 요구사항 변경은 불가피하지만, 제대로 관리되지 않으면 프로젝트에 부정적인 영향을 미칠 수 있다.[1]
- 다양한 요구사항 분류 체계: IEEE, IIBA, 미국 국방부(U.S. DoD) 등 다양한 프레임워크에 따라 요구사항 분류 체계가 달라 혼란을 야기할 수 있다.[1]
- 프로세스 부패: 인간의 결함, 편의, 정치적 요인 등으로 인해 요구사항 관리 프로세스가 제대로 지켜지지 않을 수 있다.[1]
- 엄격함 부족: 잦은 예외나 변경으로 프로세스가 무시될 수 있다.
- 새로운 참여자의 변경 시도: 새로운 담당자가 이전의 작업을 변경하려 할 수 있다.
- 권한 남용: 사용자가 자신의 권한을 남용하여 부적절한 요구사항을 추가할 수 있다.
- 늦은 참여: 개발 전에 요구사항 추출 노력이 부족할 수 있다.
이러한 요구사항 관리의 어려움을 보여주는 역사적 사례로 펜타곤 워스에 묘사된 M-2 브래들리, 파이터 마피아의 F-16, 1998년경 '네트 레디' 관련 사례가 있다.[1]
5. 1. 상충되는 표준
IEEE와 IIBA는 요구사항 관리 표준을 제시하는 주요 단체이다. 그러나 이 두 단체는 요구사항에 대해 서로 다르면서도 유사한 정의를 가지고 있어, 표준 간 상충되는 견해가 존재한다.[1]5. 2. 소프트웨어 요구사항의 필요성 및 영향에 대한 논쟁
많은 프로젝트가 요구사항에 대한 합의 없이 성공했다.[13] 일부 연구는 요구사항 명시가 창의성과 설계 성능을 감소시킬 수 있음을 보여준다.[14] 요구사항은 디자이너가 제공된 정보에 지나치게 몰두하게 만들어 창의성과 설계를 방해한다.[15][16][17] 더 나아가, 일부 연구는 소프트웨어 요구사항이 실제 요구사항이 명확하지 않은 상황에서 설계 결정을 요구사항으로 잘못 표현하여 만들어진 환상이라고 주장한다.[18]한편, 대부분의 애자일 소프트웨어 개발 방법론은 소프트웨어 요구사항을 초기에 엄격하게 설명할 필요성에 의문을 제기하며, 변화하는 목표로 간주한다. 예를 들어, 익스트림 프로그래밍은 사용자 스토리(시스템이 수행해야 하는 한 측면을 설명하는 색인 카드에 맞는 짧은 요약)를 사용하여 요구사항을 비공식적으로 설명하고, 개발자가 고객에게 직접 설명을 요청하는 것을 의무로 간주한다. 애자일 방법론은 일련의 자동화된 인수 테스트에서 요구사항을 캡처하려고 시도한다. 익스트림 프로그래밍과 같은 최근의 소프트웨어 공학 방법론에서는 요구 사항 명세를 엄격하게 기술할 필요성에 의문을 제기하며, "사용자 스토리"로 요구 사항 명세를 비형식적으로 기술하고, 해당 사용자 스토리로부터 인수 테스트의 테스트 케이스를 작성한다. 사용자 스토리란 시스템이 해야 할 일을 어떤 관점에서 간단하게 그린 것이다.
5. 3. 요구사항 변경 (Requirements creep)
요구사항은 일반적으로 시간이 지남에 따라 변경된다. 정의되고 승인된 요구사항은 변경 관리 하에 있어야 한다. 많은 프로젝트에서 시스템이 완료되기 전에 요구사항이 변경된다. 이는 부분적으로 컴퓨터 소프트웨어의 복잡성과 사용자가 실제로 보기 전에는 무엇을 원하는지 알지 못한다는 사실 때문이다. 이러한 요구사항의 특성 때문에 요구사항 관리 연구 및 실천이 이루어졌다.범위 변경은 시간이 지남에 따라 요구 사항이 변경되면서 발생할 수 있다. 요구사항 관리에서 요구 사항의 변경은 허용되지만, 적절하게 추적되지 않거나, 선행 단계(비즈니스 목표, 사용자 요구 사항)가 추가적인 감독에 의해 제한되지 않거나, 비용 및 잠재적인 프로그램 실패로 처리되지 않으면, 요구 사항 변경이 쉽고 발생할 가능성이 높다. 개발자가 작업을 수행하는 속도보다 요구 사항 변경이 더 빠르게 발생하면, 결과적으로 '뒤로' 돌아가는 노력이 발생하기 쉽다.
5. 4. 다양한 요구사항 분류 체계
요구사항에는 여러 가지 분류 체계가 있으며, 이는 사용되는 프레임워크에 따라 달라진다. (예를 들어, IEEE의 명시된 표준, IIBA 또는 미국 국방부(U.S. DoD) 접근 방식 등) 서로 다른 환경이나 일반적인 대화에서 사용되는 언어와 프로세스는 혼란을 야기하고, 원하는 프로세스에서 벗어나게 할 수 있다.[1]5. 5. 프로세스 부패
사람이 실행하는 프로세스는 거버넌스 측면에서 인간의 결함에 영향을 받는다. 편의, 욕구 또는 정치적 요인에 의해 프로세스에 대한 예외가 발생하거나 노골적인 전복이 이루어져, 프로세스가 교과서적인 방식에서 벗어날 수 있다.[1]- 엄격함이 없는 프로세스는 존중받지 못함: 예외나 변경이 흔한 경우, 프로세스를 실행하는 조직이 독립성이나 권한이 거의 없고 기록에 대한 신뢰성과 투명성이 부족하면 전반적인 프로세스가 무시될 수 있다.[1]
- 새로운 참여자가 다시 시작하기를 원함: 새로운 사람이 자신의 권력이나 가치를 증명하기 위해 전임자의 작업을 변경하려는 경향이 있을 수 있다. 예를 들어 새로운 CEO가 이전 CEO의 계획을 변경하거나, 새롭게 만들어진 부서가 현재 프로젝트 개발에 반대하여 프로젝트를 되돌리고 기준을 다시 설정하려는 노력을 시작하는 경우가 있다.[1]
- 선을 넘어서기: 더 많은 통제를 원하는 사용자가 디자인 세부 사항이나 선호하는 공급업체 특성을 사용자 요구 사항으로 삽입하거나, 자신의 부서에서 말하는 모든 것을 가능한 최고 우선 순위로 삽입하는 경우가 있다.[1]
- 늦게 나타나기: 개발 전에 요구 사항 추출에 거의 또는 전혀 노력을 기울이지 않는 경우가 있다. 이는 개인의 참여에 관계없이 동일한 이점을 얻을 수 있다고 생각하거나, 테스트 단계와 다음 반복에서 요구 사항을 삽입할 수 있다면 의미가 없다고 생각하거나, 작업 후 비판을 기다림으로써 항상 옳게 되려는 선호 때문일 수 있다.[1]
미국 국방부 프로세스 내에서 요구 사항 문제에 대한 몇 가지 역사적인 예는 다음과 같다.[1]
- 펜타곤 워스에서 묘사된 M-2 브래들리의 무의미한 요구 사항 변경 문제
- 파이터 마피아의 경량 전투기 개념에서 발전한 F-16의 사례. F-15 프로그램이 경쟁을 방해하려 하거나 개별 부서가 경량 및 저비용이라는 개념을 훼손하는 지역적 욕구를 반영한 것으로 추정된다.
- 1998년경 '네트 레디'에 대한 열정은 요구 사항 프로세스를 정의하는 부서 외부의 네트 레디 부서가 핵심 성과 매개변수(KPP)로 지정하도록 했으며, 이는 해당 부서의 이전에 정의된 프로세스, KPP의 정의, 또는 일부 노력이 적절하지 않거나 '네트 레디'를 구성하는 요소를 정의할 수 없을 수 있다는 점과 일치하지 않았다.
6. 한국의 특수 상황 및 정책적 고려 사항
한국의 IT 산업은 빠르게 변화하고 있으며, 특히 중소기업 및 스타트업의 역할이 중요해지고 있다.
참조
[1]
서적
Form and Style of Standards, ASTM Blue Book
http://www.astm.org/[...]
ASTM International
2013-01-05
[2]
간행물
A view of 20th and 21st century software engineering
http://dl.acm.org/ci[...]
Association for Computing Machinery, ACM New York, NY, USA
2013-01-02
[3]
웹사이트
1.3 Key Concepts - IIBA
http://www.iiba.org/[...]
2016-09-25
[4]
웹사이트
IEEE SA - 610.12-1990 - IEEE Standard Glossary of Software Engineering Terminology
http://standards.iee[...]
[5]
서적
A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide) Version 2.0
http://IIBA.org
[6]
학술지
Characterizing Architecturally Significant Requirements
[7]
서적
A Proposal for a Formal Definition of the Design Concept
Springer-Verlag
[8]
서적
Software Requirements: Objects, Functions, and States, Second Edition
https://archive.org/[...]
Prentice Hall
[9]
서적
IEEE Recommended Practice for Software Requirements Specifications
Institute of Electrical and Electronics Engineers, Inc
[10]
서적
Applied Software Project Management
http://www.stellman-[...]
O'Reilly Media
[11]
서적
Software Requirements, Second Edition
Microsoft Press
[12]
서적
Effective Requirements Practices
https://archive.org/[...]
Addison-Wesley
[13]
서적
System Thinking, System Practice
Wiley
1999-01-01
[14]
간행물
Is Requirements Engineering Inherently Counterproductive?
https://www.research[...]
IEEE
2015-05-01
[15]
학술지
Design fixation
1991-01-01
[16]
학술지
Design and other types of fixation
1996-01-01
[17]
간행물
Requirements Fixation
https://www.research[...]
IEEE
2014-05-01
[18]
학술지
The Illusion of Requirements in Software Development
본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.
문의하기 : help@durumis.com