Wanna be a thinker

■좋은 요건 정의서의 필수조건

• 전문 지식을 몰라도 내용을 이해할 수 있다.
• IT분야의 전문 지식이 없는 고객을 고려하여, 이해하기 쉽도록 작성한다.
• IT분야의 전문 용어나 전문 지식을 되도록이면 사용하지 않도록 한다.
• 이해하기 어렵게 작성되어 있으면, 결과물을 이미지할 수 없게 되고, 고객의 불신감이 싹트게 된다.
• 고객과 개발사의 역할 / 책임의 분담을 명확히 한다.
• 가능한 한, 정량적으로 작성한다.
• 배경, 기능은 가능한 정량적으로 작성해야, 시스템을 둘러싼 상황을 명확히 할 수 있다.
• 단, 이 단계에서 근거 없는 숫자를 작성하는 것은 위험하기 때문에 어디까지나 가능한 선에서 작성한다.
• 하지 않을 것을 명확히 한다.
• 요건 정의서에 기술된 내용이 하지 않을 것인지, 아직 정해지지 않은 것인지를 명확히 할 수 있어, 애매한 해석을 방지할 수 있다.
• 문체나 표기를 통일한다.
• 읽기 쉬운 문장도 품질의 하나이기 때문에, 문체 / 표기 / 용어 등을 통일한다.

■요건 정의서 작성 흐름

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. 요건 정의서로써 정리하여, 견적을 낸다.

■용어

• 요건 정의서
• 실현할 기능 등을 조정한 정보를 고객에게 제출하기 위해 개발측에서 작성하는 것이다.
• 업무 요건
• 기존 업무 흐름을 분석, 문제를 추출하여, 문제를 해결할 새로운 업무 흐름을 정의한 것이다.
• 시스템을 의식하지 않고, 업무에만 중점을 두어, 요건을 추려 낸다.
• 시스템 요건
• 업무 요건에서 정의한 새로운 업무 흐름을 만들기 위해, 어떻게 시스템화 할 지 방향성을 결정한 것이다.
• 기능 요건
• 시스템 요건에서 정한 시스템화의 방향성을 바탕으로, 시스템에 필요한 기능을 검토한 것이다.
• 데이터, 시스템의 종류 / 구조, 시스템이 처리할 수 있는 내용 등에 대해 작성한다.
• 비기능 요건
• 비기능 요건이란, 고객이 기능면 이외에서 요구하는 시스템 성능, 효율성, 보안, 보수 / 운용 서비스 등의 요건을 의미한다.

■개요

요건 정의서는 고객의 요구와 그 요건을 어떻게 이룰 것인가? 즉, 어떻게 시스템화 할 것인가?를 문장으로 정리한 것이다.

시스템 개발의 기반이 되며, 운용 개시 후까지 영향을 끼치기 때문에 시스템적인 모순이 없어야 하며, 고객과의 인식에 착오가 있어서는 안된다.

■목적

• 고객과의 인식을 맞추어, 개발 후 고객의 인식과 다른 결과물을 내지 않는 것이다.
• 시스템 개발에 있어, 무엇을 위해 무엇을 만드는지를 명확히 하는 것이다.

■요건 정의 수법

• 기존 업무 흐름과 시스템을 파악한다.
• 기존 시스템이나 업무 흐름에 해결할 문제가 있기 때문에 요구가 있는 것이다.
• 기존 업무 흐름과 시스템을 알아야, 어떤 부분이 문제인지, 어떻게 해결할 것인지를 알 수 있다.
• 요건 정의를 꼼꼼히 하기 위해, 보수 담당자나 시스템 사용자에게도 Hearing을 해야 한다.
• 요건 정의에 드는 비용을 최소화 하기 위해, 문제를 이해하여 해결책을 내야할 필요가 있다.
• 요구 정의서와 요건 정의서를 작성함에 있어, 고객과 협의 한다.
• 요구 정의서란, 고객이 해결하고자 하는 과제나, 도입하고자 하는 시스템에 대한 요구를 정리한 서류이다.
• 요건 정의서가 요구 정의서 대로 작성되었는지 고객과 함께 확인한다.
• 고객과의 협의는 공정 수의 삭감, 일을 두 번 하지 않기 위해 중요하다.
• 정중한 요건 정의서를 만들어 공유한다.
• 요건정의서는 고객과 개발자 간 인식의 착오를 일으키지 않도록, 최대한 상세하게 작성한다.
• 최종적인 결과물을 이미지할 수 있도록 작성하여 관계자 간에 합의가 되어야 한다.
• 담당자를 명확히 한다.
• 고객이 할 일과 SE가 할 일을 명확히 나누어야, SE가 고객의 일까지 떠맡지 않는다.
• 역할분담이 명확해야 불필요한 업무로 인한 공정 수의 압박을 피할 수 있다.

■요건 정의서의 작성 방법

• 요건 정의서 기술 항목(필수)

• 요건 정의서 기술 항목(옵션)

별명

블랙박스 테스트, 펑션 테스트

정의

소프트웨어나 시스템의 테스트 수법 중 하나로서, 테스트 대상의 내부구조를 고려하지 않고 외부에서 본 기능이나 동작이 올바른지를 검증하는 수법의 테스트이다.

특징

- 입출력에만 착목하여 다양한 입력에 대해 상정한 대로 출력되는지 확인한다.

- 테스트 케이스의 작성에 내부의 처리흐름이나 프로그램 구조는 고려하지 않는다.

수법

단, 막무가내로 정한 입력값으로는 처리의 올바름을 확인할 수 없기 때문에 다음과 같은 수법을 사용한다.

- 사양상 같은 처리를 수행할 터인 값의 범위나 그룹을 구하여 각 범위의 대표치를 선택하여 테스트하는 「동치분할」

- 범위의 경계부근이 올바른 처리를 하는지 확인하는 「한계치분석(=경계치분석)」

출처 : e-words.jp/w/%E3%83%96%E3%83%A9%E3%83%83%E3%82%AF%E3%83%9C%E3%83%83%E3%82%AF%E3%82%B9%E3%83%86%E3%82%B9%E3%83%88.html

목적

개발자가 생각치 못한 에러를 찾아내는 것

개요

시험할 부분, 조작법의 상정이나 개발자의 의도에 대한 고려 없이

시험 실시자가 즉흥적으로 조작하는 시험 방법이다.

명칭의 유래

원숭이에게 시켜 보면 어떨까? 라는 생각

상세

일반적으로 테스트는 대상의 설계, 구조, 용도, 조작법을 고려한 순서나 변수를 미리 정한다.

하지만, 몽키 테스트는 확신으로 인한 시험 관점의 누수를 배제하기 때문에

개발자가 생각하지 못한 에러를 발견하기도 한다.

주의점

에러가 발생했을 때 상황을 재현하기 위해 조작한 순서의 기록, 관찰을 신중히 해야 한다.

몽키 테스트 방식

- 랜덤한 조작을 연속적으로 시험하는 방식

- 시험대상 사용 경험이 없는 유저에게 설명 없이 사용하게 하는 방식

- 개발측의 사람이 통상적이지 않은 조작을 굳이 수행하는 방식 ... ex) 버튼 연타

출처 : e-words.jp/w/%E3%83%A2%E3%83%B3%E3%82%AD%E3%83%BC%E3%83%86%E3%82%B9%E3%83%88.html