기능적 요구사항과 비기능적 요구사항

요구공학이란?

• 요구공학은 시스템 개발 프로젝트에서 고객이나 사용자가 필요로 하는 기능과 시스템의 제약 조건을 파악하고, 이를 명확하게 문서화하여 개발 과정에서 요구사항을 효과적으로 관리하고 유지하는 과정입니다. 주요 목표는 시스템이 사용자의 필요와 기대를 만족시키도록 보장하는 것입니다​​.

Requirements abstraction

• 대규모 소프트웨어 프로젝트의 계약을 위해 필요한 요구사항을 충분히 추상적으로 정의하는 과정을 설명합니다. 이 방식은 다양한 계약자가 경쟁을 통해 다른 해결 방안을 제안할 수 있게 합니다. 계약 수여 후, 계약자는 더 구체적인 시스템 정의를 작성하여 고객이 소프트웨어의 기능을 이해하고 검증할 수 있도록 돕습니다.

요구사항 종류

1. 사용자 요구사항 (User requirements):
   • 사용자 또는 고객이 이해할 수 있는 자연어 및 다이어그램을 사용하여 시스템이 제공해야 할 서비스와 운영 제약 조건을 설명합니다. 이 요구사항은 종종 덜 기술적이며, 시스템의 주요 기능과 사용자 인터페이스에 초점을 맞춥니다.
   • 고객을 대상으로 쓰여진 요구사항
2. 시스템 요구사항 (System requirements):
   • 보다 구조화된 문서로, 시스템의 기능, 서비스 및 운영 제약을 상세히 설명합니다. 이러한 요구사항은 구현되어야 할 시스템의 기술적 세부사항을 정의하며, 클라이언트와 계약자 간의 계약의 일부가 될 수 있습니다​​.
   • 개발자를 대상으로 쓰여진 요구사항

기능적 요구사항 (Functional requirements)

• 기능적 요구사항(functional requirements)은 시스템이 수행해야 할 구체적인 기능이나 서비스를 명시합니다. 이러한 요구사항들은 시스템이 특정 입력을 받았을 때 어떻게 반응해야 하며, 특정 상황에서 시스템이 어떻게 행동해야 하는지를 설명합니다. 기능적 요구사항은 시스템의 필수적인 작업들을 구체적으로 나타내며, 이는 사용자와 시스템 간의 상호작용을 포함할 수도 있습니다​​.
• Requirements imprecision
  • 요구사항이 모호하거나 불분명할 경우, 개발자와 사용자 간에 서로 다른 해석이 발생할 수 있으며, 이는 시스템 개발 과정에서 혼란과 오류의 원인이 될 수 있습니다​​.
• Requirements completeness and consistency
  • 요구사항이 완전하다면, 그 문서는 시스템이 제공해야 할 모든 기능과 특성을 포함하고 있어야 합니다. 완전한 요구사항은 프로젝트의 범위를 명확하게 정의하고, 누락된 요구사항으로 인해 발생할 수 있는 개발 지연이나 비용 초과를 방지할 수 있습니다.
• 요구사항 문서 내의 정보가 서로 모순되지 않아야 합니다.

비기능적 요구사항 (Non-fuctional requirements)

시스템의 성능, 신뢰성, 유지보수 가능성, 보안 등과 같은 특성이나 시스템이 충족해야 하는 일반적인 제약 조건을 정의합니다. 이러한 요구사항들은 시스템의 전반적인 품질을 보장하며, 종종 시스템의 개별 기능이 아닌 전체 시스템에 적용됩니다​​.

1. 제품 요구사항 (Product requirements):
   • 제품이 특정 방식으로 동작해야 한다고 지정하는 요구사항입니다. 예를 들어, 실행 속도, 신뢰성, 유지보수성 등이 이에 해당됩니다. 이 요구사항들은 제품이 사용자와 다른 시스템 요소와 상호작용하는 방식을 정의합니다.
2. 조직 요구사항 (Organisational requirements):
   • 조직의 정책과 절차에 기인한 요구사항으로, 예를 들어 사용해야 하는 개발 프로세스, 표준, 또는 도구 등이 포함됩니다. 이러한 요구사항은 조직 내부의 운영 방식이나 기업 문화에 맞게 시스템을 구성해야 함을 명시합니다.
3. 외부 요구사항 (External requirements):
   • 시스템 및 개발 프로세스 외부에서 발생하는 요구사항으로, 상호운용성, 법적 요구사항, 산업 표준 등이 여기에 해당됩니다. 이러한 요구사항은 법적 또는 규제 기관의 요구사항을 준수하거나, 특정 산업 표준에 맞추어 시스템을 개발해야 함을 의미합니다​​.

Goals and requirements

1. 목표 (Goals)
   • 목표는 사용자의 일반적인 의도나 시스템에 대한 기대를 나타냅니다. 예를 들어, “시스템은 의료 직원이 쉽게 사용할 수 있어야 한다”는 목표는 구체적인 측정 기준 없이 사용자의 일반적인 희망사항을 표현합니다. 이러한 목표는 매우 추상적이어서 직접적인 테스트나 측정이 어렵습니다.
   • 목표는 시스템 사용자의 의도를 전달하기 때문에 개발자에게 유용합니다.
2. 검증 가능한 비기능적 요구사항 (Verifiable non-functional requirements)
   • 목표와 달리, 검증 가능한 비기능적 요구사항은 구체적인 측정 가능한 기준을 사용하여 명확하게 정의됩니다.
   • 예를 들어, “의료 직원은 4시간의 훈련 후 모든 시스템 기능을 사용할 수 있어야 하며, 경험이 풍부한 사용자는 시스템 사용 시 시간당 최대 2건의 오류를 범해야 한다”는 요구사항은 명확하게 측정하고 테스트할 수 있는 기준을 제시합니다.

측정 가능한 요소들

1. 속도 관련 지표 (Speed)
   • 거래 처리 속도: 초당 처리할 수 있는 거래의 수.
   • 사용자/이벤트 응답 시간: 사용자 입력 또는 이벤트에 대한 반응 시간.
   • 화면 갱신 시간: 화면이 새로 고침되는 데 걸리는 시간.
2. 크기 관련 지표 (Size)
   • 메가바이트 (Mbytes): 시스템이 사용하는 총 메모리 양.
   • ROM 칩의 수: 시스템에 사용된 ROM 칩의 총 수.
3. 사용 용이성 관련 지표 (Ease of Use)
   • 훈련 시간: 사용자가 시스템을 효과적으로 사용하기 위해 필요한 훈련 시간.
   • 도움말 프레임 수: 사용자가 참조할 수 있는 도움말 프레임의 수.
4. 신뢰성 관련 지표 (Reliability)
   • 고장까지의 평균 시간 (Mean time to failure): 시스템이 고장 나기 전까지 평균적으로 운영되는 시간.
   • 사용 불가능성 확률: 시스템이 사용할 수 없게 되는 확률.
   • 고장 발생률: 특정 시간 동안 발생하는 시스템 고장의 수.
5. 가용성 관련 지표 (Availability)
   • 가용성: 시스템이 사용 가능한 상태로 있을 수 있는 시간의 비율.
6. 견고성 관련 지표 (Robustness)
   • 고장 후 재시작 시간: 시스템이 고장 후 다시 시작하는 데 걸리는 시간.
   • 고장을 일으키는 이벤트의 비율: 시스템 고장을 유발하는 이벤트의 비율.
   • 고장 시 데이터 손상 확률: 시스템이 고장 났을 때 데이터가 손상될 확률.
7. 이동성 관련 지표 (Portability)
   • 대상 의존성 문장의 비율: 시스템 코드 중 특정 하드웨어나 운영 시스템에 의존하는 코드의 비율.
   • 대상 시스템의 수: 시스템이 설치되거나 실행될 수 있는 다른 플랫폼의 수.

요구사항 공학 프로세스

• 요구사항 추출 (Requirements Elicitation):
  • 이 단계에서는 이해관계자들로부터 요구사항을 수집합니다. 이 과정은 인터뷰, 설문조사, 사용 사례 분석, 관찰 등 다양한 방법을 통해 수행될 수 있습니다.
• 요구사항 분석 (Requirements Analysis):
  • 수집된 요구사항을 분석하여 모호함, 충돌, 누락된 정보를 해결합니다. 이 단계는 요구사항의 실행 가능성을 평가하고, 요구사항 간의 상호 의존성을 파악하는 것을 포함합니다.
• 요구사항 명세화 (Requirements Specification):
  • 이 단계에서는 요구사항을 명확하고 체계적인 문서로 정리합니다. 명세는 모델링 언어나 자연 언어를 사용하여 작성될 수 있으며, 모든 관련 이해관계자가 이해할 수 있도록 해야 합니다.
• 요구사항 검증 (Requirements Validation):
  • 명세화된 요구사항이 정확하고 완전하며, 사용자와 조직의 목표를 만족하는지 검증합니다. 이 과정은 프로토타이핑, 요구사항 검토 회의, 시뮬레이션 등을 포함할 수 있습니다.
• 요구사항 관리 (Requirements Management):
  • 프로젝트 진행 중 요구사항의 변경을 추적하고 관리합니다. 요구사항의 변경이 발생하면, 이 변경이 기존의 시스템 설계나 프로젝트 일정에 어떤 영향을 미칠지 평가하고 관련 이해관계자에게 이를 통보합니다.

요구사항 추출 (Requirements Elicitation)

요구사항 추출이란?

• 시스템에 대한 사용자 및 이해관계자의 필요와 기대를 파악하고 명확하게 하는 과정을 말합니다.

요구사항 추출의 목적

• 개발될 시스템이 충족해야 할 기능적 및 비기능적 요구사항을 명확하게 이해하고 문서화하는 것입니다. 이는 프로젝트의 범위를 설정하고, 추후 시스템 설계 및 구현의 기반을 마련하는 데 필수적입니다.

요구사항 추출 과정에서의 문제점

1. 이해관계자의 불확실성: 이해관계자들이 정확히 무엇을 원하는지 모르거나, 자신의 요구사항을 명확하게 표현하지 못하는 경우가 많습니다. 이로 인해 요구사항 추출이 어려워질 수 있습니다.
2. 이해관계자 간의 충돌: 다양한 이해관계자들이 서로 다른 요구사항을 가지고 있을 수 있으며, 이러한 요구사항이 서로 상충할 수 있습니다. 이는 프로젝트의 목표 설정에 혼란을 초래할 수 있습니다.
3. 조직 및 정치적 요인: 기업 내부의 정치적 이슈나 조직 문화가 요구사항 추출 과정에 영향을 미칠 수 있습니다. 이는 요구사항이 실제 필요에 의해서가 아닌, 특정 인물의 의견이나 영향력에 의해 좌우될 수 있음을 의미합니다.
4. 요구사항의 변경: 프로젝트 진행 중에 새로운 이해관계자가 참여하거나 비즈니스 환경의 변화로 인해 초기에 정의된 요구사항이 변경될 수 있습니다. 이는 프로젝트의 범위와 일정에 큰 영향을 미칠 수 있습니다.
5. 요구사항의 표현: 이해관계자들이 자신의 요구사항을 자신의 언어로 표현하기 때문에, 요구사항 엔지니어가 이를 이해하고 정확하게 문서화하는 데 어려움을 겪을 수 있습니다.

요구사항 추출 과정

1. 요구사항 발견: 이해관계자와의 상호작용을 통해 요구사항을 파악합니다. 이 단계에서는 이해관계자들의 필요, 시스템이 제공해야 할 서비스, 운영상의 제약사항 등을 정의합니다.
2. 요구사항 분류 및 조직화: 관련 요구사항을 그룹화하고 체계적으로 조직합니다. 이를 통해 요구사항을 더욱 명확하게 이해하고 관리할 수 있습니다.
3. 우선 순위 결정 및 협상: 중요한 요구사항을 우선순위에 따라 배열하고, 상충하는 요구사항에 대해 협상을 진행합니다.
4. 요구사항 명세화: 최종적으로 요구사항을 문서화하여 개발팀이 사용할 수 있도록 준비합니다. 이 문서는 후속 개발 단계의 지침서로 사용됩니다.

요구사항 발견

• 필요한 시스템 및 기존 시스템에 대한 정보를 수집하고 이를 분석하여 사용자 및 시스템 요구사항을 도출하는 과정입니다. 이 과정은 시스템 이해관계자들과의 상호작용을 통해 진행되며, 관리자부터 외부 규제기관에 이르기까지 다양한 이해당사자가 참여합니다.

인터뷰

• 인터뷰는 요구사항 추출 과정에서 주로 사용되는 기술 중 하나입니다. 이 과정에서는 이해관계자들과의 형식적 또는 비형식적 대화를 통해 시스템에 대한 이해와 요구사항을 도출합니다.
• 인터뷰의 유형
  • 폐쇄형 인터뷰(Closed interviews): 미리 정해진 질문 목록을 바탕으로 진행되며, 구체적이고 제한된 정보를 수집하는 데 유용합니다.
  • 개방형 인터뷰(Open interviews): 다양한 주제에 대해 자유롭게 이야기를 나누며, 보다 폭넓은 정보를 수집할 수 있습니다.
• 효과적인 인터뷰 방법
  • 인터뷰어는 편견을 가지지 않고 개방적인 자세로 접근해야 하며, 이해관계자가 요구사항을 자유롭게 표현할 수 있도록 격려해야 합니다.
  • 스프링보드 질문, 요구사항 제안, 또는 프로토타입 시스템을 함께 작업함으로써 인터뷰 대상자가 토론을 시작하도록 유도해야 합니다.
  • 그들이 원하는 것이 무엇인지 단순히 묻는 대신, 요구사항을 제안함으로써 사용자가 시스템에 대해 이야기하도록 유도해야 합니다.
• 문제점
  • 언어의 장벽: 응용 분야의 전문가들이 자신의 업무를 설명할 때 사용하는 전문 용어는 요구사항 엔지니어가 이해하기 어려울 수 있습니다. 이는 의사소통의 장애를 초래하며 요구사항을 정확히 파악하는 데 어려움을 줄 수 있습니다.
  • 도메인 지식의 전제: 일부 도메인 지식은 너무나 일상적이어서 사람들이 그것을 명확히 설명하는 것을 어려워하거나, 설명할 필요가 없다고 생각할 수 있습니다. 이는 중요한 정보가 누락되어 요구사항 추출이 완전하지 않을 수 있음을 의미합니다.
  • 인터뷰의 한계: 인터뷰는 도메인 요구사항을 이해하는 데 적합하지 않을 수 있습니다. 인터뷰를 통해 얻은 정보만으로는 시스템이 해결해야 할 복잡한 문제나 특정 요구사항을 완전히 이해하기 어려울 수 있습니다.

인종학적 연구 (Ethnography)

• 인종학적 연구는 사회 과학자가 실제 작업 환경에서 상당한 시간을 보내면서 사람들이 어떻게 일하는지 관찰하고 분석하는 방법입니다. 이 방법은 사람들이 자신의 일에 대해 설명하거나 명시적으로 표현할 필요 없이, 사회적 및 조직적 요인의 중요성을 포착할 수 있습니다.
• Ethnography의 활용
  • 실제 작업 흐름 이해: 인종학적 연구는 사람들이 실제로 어떻게 협력하고 상호 작용하는지에 대한 깊은 이해를 제공합니다. 이는 프로세스 정의가 제안하는 것보다 훨씬 풍부하고 복잡한 작업 환경을 드러낼 수 있습니다.
  • 협업 및 상호 인식: 인종학적 연구는 다른 사람들의 활동에 대한 인식을 통해 우리가 일을 수행하는 방식에 변화를 주는 요구사항을 도출할 수 있습니다.
• Ethnography의 장점
  • 문화적 및 사회적 맥락 포착: 일반적인 요구사항 추출 기술로는 놓칠 수 있는 조직 내 문화나 사회적 상호작용을 포착할 수 있습니다.
  • 심층적 이해 제공: 표면적으로 드러나지 않는 작업 흐름이나 조직 내 묵시적 규칙을 이해할 수 있어, 시스템 설계가 더 인간 중심적이고 현실적인 요구사항을 반영할 수 있게 합니다.
• Ethnography의 한계
  • 신기능 도출 제한: 인종학적 연구는 기존의 관행을 분석하는 데 집중하기 때문에, 새로운 기능이나 시스템 개선을 제안하기에는 한계가 있습니다.
  • 시간 및 자원 소모: 인종학적 연구는 시간이 많이 걸리며 많은 자원을 필요로 하는 작업입니다.

요구사항 명세화 (Requirements specification)

• 도출된 요구사항을 정확하고 체계적으로 문서화하는 과정입니다. 이 문서화 과정은 프로젝트 팀, 이해관계자, 최종 사용자가 모두 이해할 수 있는 형태로 이루어져야 합니다.

요구사항과 설계

• 이론적으로 요구사항은 시스템이 무엇을 해야 하는지를 정의하고, 설계는 시스템이 어떻게 그 목표를 달성할지를 설명합니다. 그러나 실제로는 요구사항과 설계가 서로 영향을 주고받으며, 종종 분리하기 어렵습니다.

주요 구성 요소

• 사용자 요구사항: 최종 사용자가 이해할 수 있는 언어로 작성된 요구사항. 시스템이 사용자에게 제공해야 할 서비스와 기능을 설명합니다.
• 시스템 요구사항: 보다 기술적인 세부사항을 포함하며, 시스템이 어떻게 작동해야 하는지에 대한 구체적인 정보를 포함합니다. 이는 때때로 기능적 요구사항과 비기능적 요구사항으로 세분화됩니다.

작성 방법

• 자연어: 이해하기 쉽고 자연스러운 언어로 작성되며, 때로는 다이어그램이나 표를 통해 보충됩니다.
• 구조화된 자연어: 표준 양식이나 템플릿을 사용하여 각 요구사항이 구조화된 형태로 기술됩니다.
• 그래픽 표기법: 기능 요구사항을 정의하기 위해 사용되는 다이어그램 및 텍스트 주석을 포함한 시각적 모델입니다.
• 수학적 사양: 상태 머신이나 집합과 같은 수학적 개념을 사용하여 요구사항을 명확히 표현합니다.

자연어 명세서

• 특징
  • 표현성과 이해도: 자연어는 표현력이 뛰어나고 모든 이해관계자가 쉽게 이해할 수 있는 이점이 있습니다. 이는 기술적 배경이 없는 사용자와 고객이 요구사항을 쉽게 이해하고 검토할 수 있게 합니다.
  • 보편성: 자연어는 모든 사람이 사용하는 일반적인 언어이므로, 요구사항 문서가 더 널리 이해되고 접근 가능하게 됩니다.
• 가이드라인
  • 표준 형식 사용: 모든 요구사항을 동일한 형식으로 작성하여 일관성을 유지합니다. 이는 문서 전체의 가독성과 이해도를 높이는 데 도움이 됩니다.
  • 명확한 언어 사용: 요구사항을 명확하고 간결하게 표현합니다. ‘shall'(반드시), ‘should'(해야 함) 등의 용어를 일관되게 사용하여 요구사항의 의무적인 측면과 권장 사항을 구분합니다.
  • 핵심 부분 강조: 중요한 요구사항이나 키워드는 강조 표시를 통해 눈에 띄게 합니다. 이를 통해 요구사항의 핵심 부분을 쉽게 파악할 수 있도록 합니다.
  • 컴퓨터 용어 사용 자제: 가능한 한 일반적인 언어를 사용하여 모든 사용자가 요구사항을 이해할 수 있도록 합니다. 전문적인 용어나 약어의 사용은 피하거나, 필요한 경우 그 의미를 명확히 설명합니다.
  • 요구사항의 근거 제공: 각 요구사항이 왜 필요한지에 대한 설명을 포함시켜 요구사항의 중요성과 목적을 이해관계자에게 명확히 전달합니다.
• 문제점
  • 명확성 부족: 자연어는 그 본질적으로 모호할 수 있어, 요구사항이 불분명하게 해석될 가능성이 있습니다. 이는 개발 과정에서 의도하지 않은 결과를 초래할 수 있습니다.
  • 정밀성의 어려움: 자연어로 표현할 때 필요한 정밀성을 달성하기 어렵습니다. 특히 기술적인 세부사항을 명확하게 전달하기 위해서는 추가적인 설명이나 정의가 필요할 수 있습니다.
  • 요구사항 혼동: 기능적 요구사항과 비기능적 요구사항이 혼합되어 표현될 수 있습니다. 이는 중요한 요구사항들이 충분히 강조되지 않거나 무시될 수 있음을 의미합니다.
  • 요구사항의 집합화: 여러 다른 요구사항이 하나의 문장 내에서 표현되기도 합니다. 예를 들어, “사용자는 제품을 검색하고, 장바구니에 추가하며, 결제를 진행할 수 있어야 한다.”와 같은 문장은 여러 개의 독립적인 요구사항을 함께 묶어 표현하는 경우가 됩니다.

구조화된 명세서

• 특징
  • 요구사항이 표준 양식이나 템플릿을 따르도록 구조화됩니다.
• Form-based Specifications
  • 기능 또는 엔티티의 정의: 각 요구사항이 관련된 기능이나 엔티티에 대해 명확하게 정의합니다.
  • 입력의 설명: 기능에 필요한 입력과 그 출처를 설명합니다.
  • 출력의 설명: 기능의 결과로서 출력되는 데이터와 그 목적지를 명시합니다.
  • 계산에 필요한 정보: 기능 수행을 위해 필요한 데이터와 계산에 사용되는 기타 엔티티들에 대한 정보를 제공합니다.
  • 실행할 동작의 설명: 기능이 어떻게 수행되어야 하는지에 대한 구체적인 동작을 기술합니다.
  • 전후 조건: 기능 수행 전과 후의 조건을 명확히 합니다.
  • 부작용: 기능 수행의 결과로 발생할 수 있는 모든 부작용을 기술합니다.

그래픽 표기법

• 표 형식 명세서
  • 표 형식을 사용하여 요구사항을 구조화하고 명확하게 기술합니다. 이 방법은 다양한 시나리오에 따라 요구사항이 어떻게 변화하는지를 명확하게 보여주는 데 특히 유용합니다.
• Use case
  • 시스템이 사용자와 상호작용하는 구체적인 시나리오를 나타내며, 각각의 유스 케이스는 시스템이 수행해야 하는 특정 작업 또는 목표를 설명합니다.

소프트웨어 요구 사항 문서

• 목적: 이 문서는 시스템 개발자에게 요구되는 사항을 공식적으로 명시합니다.
• 내용 포함: 사용자 요구 사항의 정의와 시스템 요구 사항의 명세가 포함되어야 합니다.
• 디자인 문서와의 차이: 이 문서는 디자인 문서가 아니며, 가능한 한 시스템이 ‘어떻게’ 작동해야 하는지보다는 ‘무엇을’ 해야 하는지에 초점을 맞춰야 합니다.
• 요구 사항 문서의 사용자
  • 요구 사항 문서는 개발자, 고객, 사용자 등 다양한 이해관계자들이 사용합니다.
• 요구 사항 문서의 변동성
  • 시스템 유형 및 개발 접근 방식에 따라 다름: 요구 사항 문서에 포함된 정보는 개발되는 시스템의 유형과 사용된 개발 접근 방식에 따라 달라질 수 있습니다.
  • 점진적 개발 시스템: 점진적으로 개발되는 시스템의 경우, 요구 사항 문서에는 상세 내용이 덜 포함될 수 있습니다.
  • 표준: IEEE 표준과 같은 요구 사항 문서 표준이 존재하며, 이는 주로 대규모 시스템 엔지니어링 프로젝트의 요구 사항에 적용됩니다.
• 요구 사항 문서의 구조
  • 서문: 문서의 독자와 버전 이력을 정의하고, 새로운 버전 생성의 근거 및 각 버전에서 이루어진 변경 사항의 요약을 설명합니다.
  • 소개: 시스템이 필요한 이유를 설명하고, 시스템의 기능을 간략히 설명하며, 다른 시스템과의 작동 방식을 설명합니다.
  • 용어 정리: 문서에 사용된 기술 용어를 정의합니다.
  • 사용자 요구 사항 정의: 사용자에게 제공되는 서비스를 설명하고, 비기능적 시스템 요구 사항도 이 섹션에서 설명합니다.
  • 시스템 아키텍처: 시스템 모듈 간의 기능 분배를 보여주는 고수준의 시스템 아키텍처 개요를 제시합니다.
  • 시스템 요구 사항 명세: 기능적 및 비기능적 요구 사항을 더 자세히 설명합니다.
  • 시스템 모델: 시스템 구성 요소 간 및 시스템과 환경 간의 관계를 보여주는 그래픽 시스템 모델을 포함할 수 있습니다.
  • 시스템 진화: 시스템이 기반한 기본 가정과 하드웨어 진화, 사용자 요구의 변화 등으로 인한 예상 변경 사항을 설명합니다.
  • 부록: 개발 중인 애플리케이션과 관련된 구체적인 정보를 제공합니다.

요구 사항 검증 (Requirements validation)

• 목적: 요구 사항 검증은 제정된 요구 사항이 고객이 실제로 원하는 시스템을 정의하고 있는지를 보여주는 과정입니다.
• 중요성: 요구 사항에서 발생하는 오류의 비용이 매우 높기 때문에, 검증 과정은 매우 중요합니다. 요구 사항 오류를 배포 후 수정하는 비용은 구현 오류를 수정하는 비용보다 최대 100배까지 높을 수 있습니다

주요 검사 포인트

1. 유효성 (Validity)
   • 시스템이 고객의 필요를 지원하는 기능을 제공하는지 확인합니다.
2. 일관성 (Consistency)
   • 요구 사항 간에 충돌이 없는지 검사합니다.
3. 완전성 (Completeness)
   • 고객이 필요로 하는 모든 기능이 포함되었는지 확인합니다.
4. 현실성 (Realism)
   • 주어진 예산과 기술을 감안할 때 요구 사항이 구현 가능한지 검토합니다.
5. 검증 가능성 (Verifiability)
   • 요구 사항을 확인할 수 있는지 여부를 검토합니다.

요구 사항 검증 기법

1. 요구 사항 리뷰 (Requirements Reviews)
   • 요구 사항 정의가 수립되는 동안 정기적으로 리뷰를 실시해야 합니다.
   • 고객 및 계약자 직원 모두가 리뷰에 참여해야 합니다.
   • 리뷰는 공식적(완성된 문서 사용)이거나 비공식적일 수 있습니다. 개발자, 고객, 사용자 간의 좋은 소통은 초기 단계에서 문제를 해결할 수 있게 합니다.
2. 프로토타이핑 (Prototyping)
   • 시스템의 실행 가능한 모델을 사용하여 요구 사항을 검증합니다.
3. 테스트 케이스 생성 (Test-case Generation)
   • 요구 사항의 검증 가능성을 검사하기 위해 요구 사항에 대한 테스트를 개발합니다.

요구 사항 검토 체크 (Review Checks)

• 검증 가능성 (Verifiability): 요구 사항이 현실적으로 검증 가능한지 여부를 확인합니다.
• 이해도 (Comprehensibility): 요구 사항이 적절하게 이해되었는지 확인합니다.
• 추적 가능성 (Traceability): 요구 사항의 기원이 명확하게 명시되었는지 확인합니다.
• 적응성 (Adaptability): 요구 사항을 변경하는 것이 다른 요구 사항에 큰 영향을 미치지 않도록 할 수 있는지 확인합니다.

요구 사항 변경 (Requirements Change)

• 배경: 시스템이 설치된 후에도 비즈니스 및 기술 환경은 계속 변화합니다. 새로운 하드웨어 도입, 다른 시스템과의 인터페이스 필요성, 비즈니스 우선순위의 변경, 새로운 법률 및 규정의 도입 등이 이에 포함됩니다.
• 이유
  • 사용자와 구매자의 차이
    • 시스템을 지불하는 사람들과 시스템을 사용하는 사람들은 종종 다릅니다. 이러한 차이는 조직적, 예산적 제약으로 인해 구매자가 요구하는 요구 사항과 최종 사용자의 요구 사항이 충돌할 수 있습니다.
  • 다양한 사용자 커뮤니티
    • 대규모 시스템은 일반적으로 다양한 사용자 커뮤니티를 가지고 있으며, 많은 사용자가 서로 다른 요구 사항과 우선순위를 가질 수 있습니다. 이러한 요구 사항은 종종 상충할 수 있으며, 시스템 요구 사항은 이러한 다양한 요구 사항 간의 타협 결과입니다.
  • 요구 사항의 발전
    • 경험을 통해 종종 다른 사용자에게 제공되는 지원의 균형이 변경되어야 함을 발견할 수 있습니다.

요구 사항 관리 계획 (Requirements Management Planning)

• 목적: 요구 사항 관리의 상세 수준을 설정합니다. 이 계획은 요구 사항 변경이 프로젝트에 미치는 영향을 관리하고 통제하는 데 필수적입니다.
• 주요 결정 요소:
  • 요구 사항 식별
    • 각 요구 사항은 고유하게 식별되어야 하며, 이를 통해 다른 요구 사항과 교차 참조가 가능해야 합니다.
  • 변경 관리 프로세스
    • 변경의 영향과 비용을 평가하는 활동을 포함합니다. 변경 관리 프로세스는 조직에 맞춰 맞춤형으로 설정됩니다.
  • 추적 정책
    • 요구 사항과 시스템 설계 간의 관계를 정의하는 정책입니다. 이 정책은 변경이 발생했을 때 요구 사항의 영향을 평가하는 데 중요합니다.
  • 도구 지원
    • 요구 사항 관리를 지원하기 위해 사용되는 도구를 결정합니다. 이러한 도구는 전문 요구 사항 관리 시스템부터 스프레드시트, 간단한 데이터베이스 시스템에 이르기까지 다양할 수 있습니다.

요구 사항 변경 관리 (Requirements Change Management)

• 목적: 시스템 요구 사항에 대한 변경 요청을 평가하고, 필요에 따라 이를 수용, 수정, 또는 거절하는 프로세스입니다.
• 변경 관리 과정
  • 문제 분석 및 변경 사양 (Problem Analysis and Change Specification)
    • 변경 요청을 분석하여 해당 변경이 타당한지 검토합니다. 이 단계에서는 변경 요청자에게 분석 결과가 피드백되어 보다 구체적인 요구 사항 변경 제안으로 응답하거나 요청을 철회할 수 있습니다.
  • 변경 분석 및 비용 평가 (Change Analysis and Costing)
    • 제안된 변경의 영향을 추적 정보 및 시스템 요구 사항에 대한 일반적인 지식을 사용하여 평가합니다. 이 분석을 완료한 후, 변경을 진행할지 여부에 대한 결정을 내립니다.
  • 변경 구현 (Change Implementation)
    • 요구 사항 문서와 필요한 경우 시스템 설계 및 구현을 수정합니다. 이상적으로는 문서가 조직화되어 변경을 쉽게 구현할 수 있어야 합니다.