Ⅰ. 요구사항 확인 - 요구사항.

1. 요구사항

- 고객에 의해 요구되거나 시스템이 가져야 하는 서비스 또는 제약사항.

기능적요구사항 ( Tip. 기 완 일 )

• 시스템 제공기능, 서비스에 대한 요구사항.
• 특성 : 기능성, 완전성, 일관성

비기능적 요구사항 ( Tip. 신 사 유 효 이 )

• 시스템 기능 이외의 사항.
• 시스템 구축 제약사항에 관한 요구사항.
• 특성 : 신뢰성, 사용성, 효율성, 유지보수성, 이식성

요구사항 개발 프로세스 ( Tip. 도 분 명 확 )

1. 요구사항 도출 : 요구사하 파악하는 단계.
2. 요구사항 분석 : 상충되는 요구사항 해결, 시스템 요구사항을 정제하여 소프트웨어 요구사항 도출.
3. 요구사항 명세 : 문서작성 / 시스템정의, 시스템요구사항, 소프트웨어 요구사항을 작성.
4. 요구사항 확인 : 문서가 표준에 적합하고, 이해가능하며, 일관성있고 완전한지 검증.

요구사항 검증 기법 ( Tip. 동 워 인 )

• 동료검토 : 2~3명이 진행하는 리뷰형태 / 명세 작성자가 설명, 이해관계자들이 들으면서 결함발견 하는 형태.
• 워크스루 : 오류 조기검출 목적 / 검토자료를 회의전 배포 후 사전검토, 짧은시간 회의 진행, 리뷰통해 오류 검출.
• 인스펙션 : 다른 전문가 또는 팀이 검사하여 오류를 찾아내는 공식적 검토 방법.

요구사항 관리절차 ( Tip. 협 기 변 확 )

1. 요구사항 협상.
   • 주요기법 : 우선순위 설정, 시물레이션
   • 가용한 자원과 수용가능한 위험수준에서 구현가능한 기능을 협상하기 위한 기법.
2. 요구사항 기준선.
   • 주요기법 : 공식회의, 형상관리
   • 공식적으로 검토되고 합의된 요구사항 명세서.
3. 요구사항 변경관리.
   • 주요기법 : CCB, 영향도 분석
   • 요구사항 기준선을 기반으로 모든 변경을 공식적으로 통제하기 위한 기법.
4. 요구사항 확인 및 검증.
   • 주요기법 : 확인 및 검증
   • 구축된 시스템이 이해관계자가 기대한 요구사항에 부합하는지 확인하기 위한 방법.

요구사항 분석 기법 ( Tip. 분 개 할 협 정 )

• 요구사항 분류.
  • 요구사항이 기능인지 비기능인지 확인.
  • 요구사항이 소프트웨어에 미치는 영향 범위 파악.
  • 요구사항이 생명주기동안 변경이 발생하는지를 확인.
• 개념모델링.
  • 개념모델은 문제 도메인의 엔티티들과 개별관계 및 종속성을 반영.
  • 유스케이스 다이어그램을 주로 활용 / 모델링 표기법은 UML사용.
• 요구사항 할당.
  • 요구사항 만족시키기 위한 아키텍쳐 구성요소를 식별하는 활동.
• 요구사항 협상.
  • 두명의 이해관계자가 서로 상충되는 내용 요구시, 적절한 지점에서 합의하기 위한 기법.
• 정형분석.
  • 형식적으로 정의된 의미를 지닌 언어로 요구사항을 정확하고 명확하게 표현.

요구사항 확인 기법 ( Tip. 요 프 모 인 )

• 요구사항 검토.
  • 여러 검토자들이 에러, 잘못된 가정, 불명확성, 표준과의 차이를 검토.
  • 고객중심 프로젝트에서는 검토그룹내 고객대표 1명 이상 포함 필요.
  • 시스템 정의서, 시스템 사양서, 소프트웨어 요구사항 명세서를 완성한 시점에서 검토.
• 프로토타이핑.
  • 요구사항 도출 수단 및 SW 요구사항에 대해 엔지니어가 해석한 것을 확인하기 위한 수단으로 사용.
• 모델검증.
  • 분석단계에서 개발된 모델의 품질 검증 필요.
  • 객체 모델의 경우 객체간 의사소통 경로를 검증하기 위해 정적 분석 수행에 유용.
• 인수테스트.
  • 최종 제품을 기준으로 요구사항을 만족시키는지 확인 가능해야함.
  • 각 요구사항 확인 계획 수립 후, 요구사항 확인 테스트.

요구사항 확인 프로세스 ( Tip. 목 정 비 타 )

• 요구사항 목록확인.
  • 요구사항 목록 중 기능에 대한 요구사항 반영 여부 확인.
• 요구사항 정의서 작성여부 확인.
  • 요구사항 정의서(유스케이스 명세서)가 작성 되었는지 확인.
  • 시스템의 동작 방식을 명확하고 구체적으로 기술하고 있는지 검토.
• 비기능적 요구사항 확인.
  • 비기능적 요구사항이 명확하게 도출되었는지 검토.
  • 성능, 가용성, 사용 용이성, 유지보수 용이성, 안전성, 보안성 등에 대한 요구사항 문서화 여부 확인.
• 타시스템 연계 및 인터페이스 요구사항 확인.
  • 타 또는 하위 시스템과 인터페이스 요구사항 정의되었는지 확인.
  • 인터페이스 구분, 주기, 방법, 제공자, 요청자 등이 명확하게 정의 되었는지 확인.

2. 요구사항의 시스템화 타당성 분석

타당성 분석 4단계 ( Tip. 성 상 아 기 )

• 성능 및 용량산정의 적정성.
  • 목표 시스템의 용량 산정 후 성능 관련 비기능 요구사항과 비교하여 적정성 여부 판단.
• 시스템간 상호운용성.
  • 타 시스템과 연동을 요구하는 경우, 상호 운용이 가능한지 여부를 판단.
• IT 시장성숙도 및 트렌드 부합성.
  • 구축시 요구되는 영역별 기술들의 동향 파악, 요구사항이 이에 부합하는지 판단.
• 기술적 위험 분석.
  • 적용한 기술의 복잡성, 검증여부, 의존성 등 위험발생 가능성, 영향도 파악.

분석 프로세스

1. 타당성 분석결과기록.
   • 요구사항 목록에 타당성 분석을 위한 속성 추가하고 타당성 분석 결과를 기록.
   • 타당성 분석을 위한 속성 : 성능/용량, 시스템간 상호운용성, 시장성숙도 및 트렌드 부합성, 기술복잡성, 기술검증여부, 기술의존성.
2. 타당성 분석 결과의 이해관계자 검증.
   • 타당성 분석 결과를 요구사항 관련 이해관계자에게 배포하여 사전검토 요청.
   • 관련 이해관계자가 모여 타당성 분석 결과 검증.
   • 결과에 이견이 있을 경우 프로젝트 관리자의 중재하에 합의 도출.
3. 타당성 분석결과 확인 및 배포 / 공유.
   • 이해관계자 검증을 거친 분석결과를 의사결정자가 확인.
   • 확정된 타당성 분석 결과를 이해관계자에게 배포하여 공유.

3. 비용산정모델

하향식 산정방법

• 경험이 많은 전문가에게 비용산정의뢰 또는 여러 전문가와 조정자를 통해 산정.
• 종류
  • 전문가판단 : 두명이상의 전문가에게 산정의뢰.
  • 델파이기법 : 한명의 조정자와 여러 전문가로 구성.

상향식 산정기법

• 요구사항과 기능에 따라 비용을 계산.
• 종류
  • 코드라인수(LOC)
  • Man Month
  • COCOMO모형 : 프로그램 규모에 따른 산정.
  • 푸트남(Putnam)모형 : 소프트웨어 개발 주기의 단계별로 요구할 인력의 분포를 가정하는 모형.
  • FP모형(Function Point) : 기능점수모형. 기능의 점수를 계산하여 비용 산정.

---

• 정보처리기사 필기 합격 후 실기대비 정리 및 책없이 간단히 보기위해 작성하였습니다.
• 2020년 수제비 정보처리기사 책 기반으로 정리 하였습니다.
• 저작권 관련 문제가 있다면 hojunbbaek@gmail.com 으로 메일 주시면 바로 삭제 조치 하도록 하겠습니다.

---