[소프트웨어공학] 요구사항 검증/변경/관리

요구사항 검증

• 고객이 정말 원하는 시스템인가?를 점검
  • 도출 및 분석과정과 겹침
  • 요구사항에서 문제점을 찾는 것과 관련
    
    
• 요구사항 검증은 매우 중요한 과정
  • 이후 단계에서 요구사항 문서상 오류가 발견될 경우 막대한 재작업 비용 필요
    ← 주로 개발 중이나 서비스 시작 후에 문제점이 발견되기 때문
    
    
  • 시스템 변경을 통해 요구사항 문제를 수정할 경우 높은 비용 발생
    ← 시스템 설계와 구현 변경, 테스트 다시 수행 → 설계나 코드 오류보다 훨씬 높은 비용
    
    

 

 

 

 

요구사항 검증 시 점검해야 하는 사항들

• 유효성 점검
  • 요구사항이 시스템 사용자의 실제 요구를 반영하는가?
    
    
• 일관성 점검
  • 문서상의 요구 사항이 서로 상충되지 않는지 확인
    → 모순되는 제약이나 같은 기능에 대한 다른 설명이 없는지 확인
    
    
• 완전성 점검
  • 의도한 모든 기능과 제약이 정의되었고, 요구사항이 문서에 모두 포함되어 있는지 확인
    
    
• 실현성 점검
  • 실제로 구현 가능한지 확인(기술, 예산 일정 측면)
    
    
• 검증 가능성
  • 시스템 요구사항은 문서로 작성해서 검증 가능해야 함
    • 인도한 시스템이 요구사항을 만족한다는 것을 시연/테스트를 통해 확인 가능해야 함
      
      
  • 고객과 계약자 사이의 분쟁 가능성을 줄이기 위해 필요

 

 

 

 

요구사항 검증 기법

• 요구사항 검토
  • 검토팀이 요구사항의 오류와 불일치사항을 체계적으로 분석하는 기법
    
    
• 프로토타이핑
  • 실행가능한 시스템 모델을 개발해서 최종 사용자와 고객들과 함께 사용하는 기법
    • 모델이 최종 사용자와 고객을 만족시킬 수 있는지 확인
      
      
  • 이해관계자는 실험을 통해 요구사항에 대한 피드백을 개발팀에게 전달
    
    

• 테스트 케이스 생성
  • 요구사항에 대한 테스트를 검증 프로세스의 일부로 만드는 기법
    • 요구 사항은 테스트할 수 있어야 함
    • 테스트가 설계하기 어렵거나 불가능하면 그 요구사항은 구현하기 어려움

 

 

 

 

 

요구사항 변경

요구사항의 불완전함

• 대규모 소프트웨어 시스템 요구사항은 항상 바뀜
  • 정의하기 어려운 문제를 다루기 위해 시스템을 개발하는 경우
  • 바뀐 문제에 대한 이해를 반영하기 위해 시스템 요구사항을 개선
    
    
• 비즈니스 환경 변화로 인해 시스템 요구사항에 대한 변경 발생

 

 

 

 

시스템 요구사항 변경 원인

• 비즈니스와 기술적 환경 변화
• 시스템 비용 지불자와 시스템 사용자가 다른 경우
  • 시스템 고객은 조직 및 예산으로 인한 제약 때문에 요구사항 조정
  • 이런 요구사항이 최종 사용자 요구사항과 상충되면 새로운 기능을 추가해야 함
    
    
• 대규모 시스템에 다양한 이해당사자가 있을 경우

 

 

 

 

요구사항 관리

• 요구사항 변경으로 인한 영향을 평가하기 위해 관리 필요
  • 개별 요구사항 추적 및 연관된 요구사항들 관계 정리
    
    
• 요구사항 관리 프로세스
  • 변경 제안서를 작성하고 이를 시스템 요구사항과 연관을 맺는 공식적인 프로세스
    
    
• 애자일 개발 프로세스
  • 개발 과정에서 변경되는 요구사항을 처리하도록 설계
  • 공식적인 변경 관리 프로세스를 거치지 않음
  • 변경에 대한 우선순위 설정 후, 다음 반복 주기에서 구현하도록 결정
    • 이 경우, 기존 구현 계획 기능 중 일부 포기해야 할 수도 있음

 

 

 

요구사항 관리 계획

• 요구사항 식별
  • 각 요구사항을 유일하게 판별할 수 있어야 함
    • 다른 요구사항과 상호참조, 추적가능성 평가 위해
      
      
• 변경 관리 프로세스
  • 변경에 대한 영향과 비용을 평가하는 활동들
    
    
• 추적가능성 정책
  • 기록해야 하는 관계를 정의하고, 기록들을 유지보수하는 방법
  • 관계 : 요구사항 사이 또는 요구사항과 시스템 설계 사이의 관계
    
    
• 도구지원
  • 요구사항에 대한 엄청난 양의 정보를 처리해야 하기 때문에 다양한 도구들을 사용할 수 있음
    
    
    
  • 도구지원이 필요한 이유?
    • 요구사항 보관
      • 요구사항을 프로세스에 참여하는 전원이 접근 가능한, 안전한 데이터 저장소에서 관리해야 함
        
        
    • 변경 관리
      • 적극적인 도구 지원이 가능하면 변경 관리 프로세스를 단순화 가능
        
        
    • 추적가능성 관리
      • 도구의 지원으로 관련 요구사항을 찾을 수 있음
      • 어떤 도구는 자연어 처리 기법으로 요구사항들 간의 가능한 관계를 찾도록 도움

 

 

 

 

요구사항 변경 관리

• 요구사항 문서가 승인된 후에 시스템 요구사항에 발생한 변경에 대해 적용해야 함
  
  
  
• 변경 관리는 필수적
  • 신규 요구사항을 구현해서 얻는 이익이 그 구현 비용보다 높은지 판단
    
    
• 정형적 변경 관리 프로세스 사용 시의 장점
  • 변경에 대한 모든 제안들을 일관하여 다룰 수 있음
  • 요구사항 문서에 대한 변경을 통제하면서 작성

 

 

 

 

 

변경 관리 프로세스의 세 가지 주요 단계

1. 문제 분석 및 변경 명세
   • 식별한 요구사항 문제 또는 특정 변경 제안으로 프로세스 시작
   • 문제 또는 변경 제안이 유효한지 확인하기 위해 분석
     
     
2. 변경 분석 및 비용 산출
   • 제안한 변경의 효과를 평가하고, 변경 생성 비용 추정
     • 분석 후, 요구사항을 변경할지 말지 결정
       
       
3. 변경 구현
   • 요구사항 문서(필수)와 시스템 설계 및 구현(선택)을 수정
     ← 과도한 재작성이나 재구조화를 거치지 않기 위해 요구사항 문서 작성 필수