요건 정의서 작성

■요건 정의서 작성 흐름

1. 요건 정의 계획 작성
2. 업무 요건의 정리
1. 현행 업무의 정리
2. Hearing 실시, 과제 분석, 해결책 검토
3. 새로운 업무를 검토
4. 시스템화 범위의 검토
3. 시스템 요건의 정리
1. 플랫폼의 검토
2. 기능 요건과 비기능 요건의 정리
4. 정리 / 견적
1. 요건 정의서 작성
2. 기본 설계 이후의 계획 작성
3. 견적 산출

1. 요건 정의 계획 작성

• 성과물
• 요건 정의 설계서
• 시스템화 방침을 명확히 하여, 요건 정의의 스케줄과 체제도를 작성한다.
• 5W2H를 명확히 한다.

2. 업무 요건의 정리

시스템 요건에 앞서 업무 요건을 정리해야 한다.

고객도 현재 상황에 대한 분석이 충분치 않은 상태에서 Hearing하더라도,

제대로 요건을 끌어내지 못하거나, 나중에 가서 새로운 기능의 추가가 요구될 수 있기 때문이다.

• 현행 업무의 정리
  • 현행 업무 흐름
  • 업무 처리 정의서
• 성과물
• 업무의 있어야 할 모습(To-be)과 현재 상황(As-is)간의 갭이 업무 과제가 된다.
• 과제를 빠짐 없이 추려내기 위해, 현재의 업무(As-is)의 정리가 중요하다.
• 현재 업무를 정리하는 수법은 다양하지만, 업무 흐름도를 작성하는 것이 일반적이다.
• 흐름도 상에 다 쓸 수 없는 상세한 내용은, 업무처리정의서에 기재한다.

• Hearing 실시, 과제 분석, 해결책 검토
  • Hearing결과 일란
  • 문제 / 영향 / 원인 / 대책 일란
  • 업무 상의 문제, 과제를 추려 낸다.
  • Hearing한 내용은, 일란표로 정리하여 나중에 확인할 수 있도록 한다.
• 성과물
• 업무 부문의 Hearing을 하며, 과제를 분석하여 대책을 검토하는 과정이다.
• 이 때의 대책은, 시스템화에 의한 대책 뿐만이 아닌, 업무 프로세스나 체제의 변경 등을 포함한다.
• Hearing 실시

• 과제 분석
• Hearing한 결과를 바탕으로, 문제 / 영향 / 원인을 구조적으로 정리한다.
• 문제로부터 정리하면 좋다.
• 영향에 대해서는, 그래서 뭐?를 반복하여 매상 / 코스트 / 고객만족도 / 준수법규(complaiance)와 같은 경영 레벨의 관점으로 연결한다.원인에 대해서는, 왜?를 반복하여 업무 프로세스 / 시스템 / 제도, 룰 / 조직, 담당자 / 설비, 기기와 같은 관점에서 정리하면 대책을 검토하기 쉽다.각 문제에 대해 우선순위를 정해두면, 해결책의 검토 대상을 한정하거나, 시스템화의 대책 범위를 결정할 때 도움이 된다.

• 해결책 검토
• 핵심적인 원인에 대한 대책을 검토한다.
• 업무 프로세스 / 시스템 / 제도, 룰 / 조직, 담당자 / 설비, 기기와 같은 관점에서 정리하면 대책을 검토하기 쉽다.
• 시스템의 관점에서 검토한 대책이, 시스템 요건으로 이어진다.

• 새로운 업무를 검토
  • 신 업무 흐름도
• 성과물
• 현행 업무의 자료에 검토한 해결책을 반영시킨다.
• 현행의 데이터 흐름이나 유즈케이스를 정리한 경우, 개선 후의 자료도 정리 한다.
• 시스템화 범위의 검토
  • 시스템화의 대상 범위
• 성과물
• 문제 분석과 해결책의 검토 후, 시스템화 범위가 바뀌었을 가능성이 있기 때문에 검토한다.
• 구체적으로는 요건 정의를 개시했을 때 설정한 5W 2H의 Where(대상 범위)나 How(실현 수단)를 체크한다.
• 고객이 요구한 기능이 실현 가능한지 판단하여 탑재할 기능을 고객과 함께 결정한다.
• 요구 내용 중 시스템화 할 범위를 명확히 해야, 도중에 사양 버그로 인해 두 번 일하지 않는다.
• 당초와 비교해 시스템화 범위가 확대된 경우, 범위를 좁히거나 프로젝트 예산을 늘릴 필요가 있다.(요건 정의 스케줄이 연장되기도 한다.)

3. 시스템 요건의 정리

시스템화 범위나 플랫폼의 변경이 없는지 재검토 후, 시스템의 기능 요건과 비기능 요건을 구체화하는 작업이다.

• 플랫폼 검토
  • 하드웨어 구성
  • 소프트웨어 구성
  • 네트워크 구성
• 성과물
• 플랫폼이란, 시스템 기능을 제공하기 위한 네트워크, 하드웨어, 운영체제, 미들웨어를 의미한다.
• 앞에서의 시스템화 범위의 검토의 결과를 토대로, 필요한 플랫폼을 정리한다.
• 플랫폼의 변경은, 프로젝트에 큰 영향을 끼치기 때문에, 제대로 검토할 필요가 있다.
• 기능 요건과 비기능 요건의 정리
  • 시스템 기능 : 시스템 기능 계층도
  • 화면 : 화면 일란 / 화면 전이도 / 화면 레이아웃
  • 장표 : 장표 일란 / 장표 레이아웃
  • 데이터 : ER도 / 엔티티 일란 / 엔티티 정의서
  • 외부 인터페이스 : 외부 시스템 관련도 / 외부 인터페이스 일란 / 외부 인터페이스 정의서
  • 사용성 및 접근성
  • 시스템 방식
  • 규모
  • 성능
  • 신뢰성
  • 확장성
  • 상위호환성
  • 계속성
  • 정보 보안
  • 정보 시스템 가동 환경
  • 테스트
  • 이행
  • 인수인계
  • 교육
  • 운용
  • 보수
• 기능 요건 : 업무를 대행 또는 지원하는 기능
• 비기능 요건 : 성능 / 신뢰성 / 조작성 등, 기능 이외의 요건
• 기능 요건의 성과물
• 비기능 요건의 성과물

4. 요건 정의 정리 / 견적

• 요건 정의서 정리
  • 요건 정의서
• 성과물
• 여지껏 작성한 자료를 정리하는 작업이다.
• 시스템 설계 직전의 공정이기 때문에, 시스템의 전체상에서 세분화한 기능까지, 가능한 상세하게 기입해야 한다.
• 서면 내용은 고객의 요구를 만족한, 상호간 협의 및 합의가 된 내용이어야 한다.
• 기본 설계 이후의 계획 작성
  • WBS
• 성과물
• 요건 정의서 작성 후, 기본 설계 이후의 작업을 추려내어 스케줄을 세운다.
• 여기서 작성한 자료는 견적이나 후속 공정에서의 스케줄, 비용 관리에도 사용한다.

• 견적 산출
  • 견적서
  • 유추 견적
  • 과거의 비슷한 프로젝트로부터 견적을 유추하는 방법이다.
  • 예산 획득 시 등, 상류 공정의 초기 견적에서 사용되는 경우가 많으나, 정밀도가 낮기 때문에 요건 정의 이후에는 거의 사용되지 않는 수법이다.
  • 모수(母数：パラメトリック) 견적
  • 기능 수, 화면 수 등의 계수를 곱하여 견적을 산출한다.
  • 계수의 설정에 따라 견적의 정밀도가 바뀌지만, 이용 실적이 많은 기업에서는 계수의 신뢰성이 높고, 고객 기업의 이해도 얻기 쉽기 때문에 가장 많이 사용되는 수법이다.
  • BottomUp 견적
  • 프로젝트의 작업을 추려 내어, 공정 수를 산출하는 방법이다.
  • 작업 베이스로 견적을 내기 때문에, 가장 정밀도가 높고, 프로젝트 개시 후의 스케줄 / 비용 관리에도 유용할 수 있다.
• 성과물
• 요건 정의서 작성 후, 시스템 개발의 견적을 산출하여, 예산을 오버하지 않았는지 체크한다.
• 다음과 같은 대표적인 견적을 내는 수법이 있다.

 

※요약

1. 어떻게 진행할 지 계획을 세운다.
2. 기존 업무를 어떻게 바꾸고 싶은지 정리한다.
3. 이를 위해, 어떤 시스템이 필요한지 정리한다.
4. 요건 정의서로써 정리하여, 견적을 낸다.