소프트웨어 요구사항 개요 및 명세 방법

소프트웨어 요구사항 개요

소프트웨어의 위기해결을 위한 방법으로써 소프트웨어의 공학이 대두되었다.
(위기로 인해 프로젝트가 실패되는 경우가 더욱 빈번해지고 있기 때문이다.)

프로젝트 실패 원인

• 고객과의 비효율적인 의사소통으로 인한 사용자 입력 부족
• 불명확하게 설정된 목표와 범위로 인한 불완전한 요구사항
• 잘못된 프로젝트 계획과 추정으로 인해 변경

요구사항단계에서 오류수정 비용이 가장 싸다
(일반적으로 단계를 거듭할수록 10-13배씩 증가)

잘못된 요구사항 관리는 변경으로 인한 재작업을 가져온다

요구사항 관리와 노력의 투자

• 시스템 개발비용은 초기단계에서 80%가 결정된다
• 시스템 개발의 초기단계에 시스템 요구사항을 명확하게 정의하면 Cost overrun이 감소한다
• 요구사항 관리에 개발노력의 10%수준으로 투입하면 비용초과나 일정 지연이 줄어든다.
• 요구사항 관리에 13% 이상 투자 시 비용증가 추세가 안정화된다

부적정한 요구관리 적용 위험의 예시

• 사용자의 불충분한 참여
• 사용자 요구 도출의 더딘 진행
• 특정 계층의 사용자 간과
• 개발자의 과시적 외양 치중 및 불필요한 특성 추가
• 최소한의 상위 요구사항
• 애매모호한 요구사항
• 불완전하게 정의된 요구사항

정확한 시스템 Goal 식별

프로젝트 비전의 정의

프로젝트 비전 ?
: 프로젝트에서 만든 제품으로 어떠한 편리성, 효율성을 제공하려고 하는 것인가?

• 궁극적인 목적에 대한 전략 수립

  Need - "왜 해당 조직에서 프로젝트를 수행하는가?
   Goals - "요구를 만족시키기 위하여 무엇을 수행하여야 하는가?
   Objectives - "어떻게 Goals를 달성할 것인가?"

• 목표충돌을 인식

개발범위 정의

프로젝트 범위 ?
: 제품에 포함해야하는것과 포함하지 않아야 하는 것은?
: 프로젝트 제약사항으로 인한 범위 내외의 경계는?

• Product의 boundary 정의
• 특정 릴리즈에 대한 범위 정의 : Divide and Conquer
• 범위확장관리

"Gold-Plate"의 방지

고객중심의 요구사항 도출

1. 사용자 관점에서 문제를 해결한다

• 개발자 중심의 문제접근을 피한다

  개발자가 미리 문제해결에 대해 예상
   사용자 관점에서 문제를 해결하지 않음

• 수동적 요구사항 수집이 아닌 능동적 요구사항 도출활동을 한다

  능동적인 참여자 투입
   고객의 소리 경청

• 참여자가 많을수록 더 많은 기능을 요구한다

2. 고객으로부터 요구사항 정보를 도출한다

• 지속적인 탐색과 발견의 과정

  한 번의 Workshop이나 회의로 모든 요구사항을 도출할 수 없다
  여러단계의 릴리즈나 반복을 통하여 상위수준의 개념을 상세화한다
  변경, 명확화, 조절작업을 수행한다
  

• Listen Carefuly, Ask Question

  중립적입장에서 자연스럽고 효과적으로 이끄는 역할 요구
   심문이 아니라 질문을 한다
   고객을 분석가의 의도대로 이끄는 질문은 피하라
   단순히 고객의 대답을 기록하는것이 아니다
   이유를 탐색한다
   

3. 사용자와 개발자가 동일한 용어를 사용한다

• 용어집을 작성한다

  용어의 오용 및 의미혼동으로 인한 오해를 최소화함
   모든 참여자들간에 정의와 관련된 동의 내용을 기록한다

• 공통의 표현법으로 기술한다.

  자연어 표현의 모호성 및 테스트 가능성 고려
   자신의 표현법과 용어로 요구사항을 기술한다
   그래프, 다이어그램등을 추가하여 모호성을 방지한다
   

다양한 이해관계자 관리

• 다중 참여자 그룹을 식별한다

  	단일 이해관계자가 모든것을 말해줄 수는 없다
      이해관계자별 다양한 관점을 관리하여야한다.

요구사항 도출 기법

• 적합한 요구도출기법을 사용한다
  (요구사항의 크기/복잡도, 도메인, 포함된 인원을 기반으로 기법 선정)

1. 인터뷰

• Ask Question & Listen Answer

  모든관점을 고려하여 많은 정보 획득이 가능하다
   소수인원이 많은 정보를 알고있을경우 적용가능하다
   Closed Interview, Open Interview

• 인터뷰의 고려사항

  인터뷰 전 : 목적을 정의, 관련지식 및 공통용어 수집
   인터부 중 : 대상자의 말을 경청, 앞선질문 -> 다음질문 유추, 
              피드백과 이해를 위해 모델과 스케치 사용 
   종료 전 : 정보요약 및 결과 설명 후 다음 질문
   

2. 설문서

• Questionnaire

  많은 인원으로부터 요구사항 도출
   정량적 데이터의 제시가 필요할 경우
   1단계: 사전질문, 2단계: 설문으로 효율적인 설문 수행
   미리 정의된 질문을 사용한다

3. 브레인스토밍

• Group Session

  소수 인원의 그룹에 의한 의견 생성
  삐른시간에 많은 의견을 생성 가능
  익명성 - 자유롭게 생각을 도출 : 사용용이, 적은 Overhead
  다양한 견해를 제공

4. 사용자 관찰

• 분석가가 고객의 "일상" 작업 수행과정을 관찰
• 활용 가능 시점

현재시스템의 문제를 찾을 때
고객이 알고있지만 표현을 하지 못할 때
(처음 개념을 잡을때는 부적절하다)

5. 요구사항 워크샵

• 주제에 대한 토론

  참가자의 적극적 참여의식 필요
  이해관계자와 최종합의
  
  브레인스토밍 vs 워크샵
  브레인스토밍은 소수인원으로 다양한 의견 생성가능
  워크샵은 다수인원이 일정 주제 기반의 의견공유 및 합의 세션

• 워크샵 수행 고려사항

  진행규칙을 정한다
  모니터링하며 진행을 제한해 수행범위를 넘지 않는다
  토론팀의 규모를 작게 유지한다.
  기록시 향후 고려항목을 위한 공간을 준비한다

사용자 정보유형 분류

• 비즈니스 요구사항
• 유즈케이스 or 시나리오
• 비즈니스 규칙
• 기능 요구사항
• 품질속성
• 외부 I/F 요구사항
• Constraints

요구사항 도출 시 주의사항

• 프로젝트 범위의 완전성 및 적절성 여부를 파악하고 변경조치를 한다
• 요구사항은 "What"에 초점, "How"는 사용자에 초점
• 워크샵은 아키텍처, 개발자, 설계자 등을 포함하여 최소의 인력이 참여
• 균형성을 고려하여 골고루 의견을 수렴

누락 요구사항 발견

• 모든 사용자계층이 요구사항 제시
• 추상적 요구사항 -> 상세화
• 기능 요구사항을 추적하여 필요한 모든 기능이 도출되었는지 확인
• ERD, DFD, STD 등 다양한 모델을 활용하여 검증
• CRUD 매트릭스 활용

사용자의 의견 표출의 종료신호

• 사용자가 더 이상 UC를 제시하지 못하는 경우
• 이미 끝난 토의내용을 되풀이하는 경우
• 개벌범위 이외의 UC or 기능적 요구사항을 제시하는 경우
• 신규 요구사항이 이미 정의한것이고 낮은 우선순위를 가질경우

요구사항 분석 개요

• 요구사항 정제/보완 (불완전, 추상적 -> 완전성 일관성)

• 요구사항 분석 활동

  	 요구사항 모델링: 추상적 요구사항의 구조화 및 상세화
  	 요구사항 우선순위화: 위험관리 / 충돌해결을 위한 우선순위 결정
       요구사항 선정: 다음 릴리즈에 포함될 요구사항 선정

요구사항 우선순위

• Analytical Hierarchy Process (AHP)
• Value-Based Prioritization

좋은 '요구사항 명세' 속성

• Necessary
• Correct
• Feasible
• Prioritized
• Understand
• Verifiable

전채 '요구사항 문서' 속성

• Complete
• Consistent
• Modifiable
• Traceable

소프트웨어 명세 및 실습

요구사항 수집 대상

• 시스템 요구사항, 시스템 아키텍처, 시스템 요구사항 및 아키텍처 변경 사항
• 제안서, 계약서, 고객업무 프로파일, 서비스수준 합의서, 작업기술서, 업무규정집, 현행시스템 관련자료 (작성산출물)

요구사항 수집 방법

• Document-based : 시스템 요구사항, 시스템 아키텍처 문서 및 이에 따른 변경사항 기반
• Interview : 가장 직접적인 요구사항 습득기법. 간단, 실직적으로 모든 상황에서 적용 가능
• Workshop : 정해진 짧은 기간 안에 고객의 주요 요구사항을 얻을 수 있는 기법, Cost-effective, Time-efficient 한 기법
• 설문조사 : 고객의 비즈니스를 잘 알고 있는 경우 정량적 결과를 얻어 통계적 분석을 하고자 할 때 주로 사용. 기초 인터뷰, 분석작업 이후 고객 요구사항 재차 확인 용도가 유용하다
• Role-Playing : 고객의 비즈니스가 매우 복잡할 경우, 고객의 입장에서 실세계를 경험하게 하여 이해를 높이고자 할 때 사용되는 기법

요구사항 분석 방법

• 문장 분석

  	문서로 제공된 시스템 요구사항, 제안서, 기존 시스템 변경사항자료 등을 기반으로 요구사항을 분석한다. 
  	구조적 방법론에서 주로 사용

• DFD 분석

  	구조분석을 위한 기법으로 시스템이 다루는 데이터나 저장소, 프로세스 저장소 등을 기반으로 요구사항을 분석한다.

• 스윔레인 분석

  	비즈니스 프로세스나 제안된 소프트웨어 시스템 운영에 필요한 각 단계를 표현하는 방법을 제공한다.
      UML Activity 다이어그램과 유사하며, 기능요구사항을 묶는데 도움이 된다.

• 유즈케이스 분석

  	Actor가 어떤 중요한 결과는 성취하는데 있어 결과를 만들어내는, 시스템과 외부행위자간에 상호작용 순서를 설명한다. 
     사용자의 관점에서 시스템의 서비스 혹은 기능 및 그와 관련한 외부 요소를 보여주는 다이어그램. 
     고객과 개발자가 함께보며 요구사항에 대한 의견을 조율할 수 있다. 
     유즈케이스 분석의 결과로 기능요구사항을 도출한다.

• 의사결정 일람표와 의사결정 트리 분석

  복잡한 논리와 의사결정을 필요로 할 때 시스템이 해야하는일을 표현하는 두 가지 대안기법.
   일람표는 행동에 영향을 미치고 각 요소의 조합에 대한 시스템의 예상행위를 가리키는 모든 요소에 대한 다양한 값을 나열한다. 
   의사결정 트리는 프로그램의 분기문과 같은 형태로 의사결정을 표현한다
   

• 이벤트 반응표 분석

  실시간 시스템 요구사항 분석시 이벤트에 따라 시스템이 수행해야 할 반응을 중심으로 분석한다.
   이벤트주기, 이벤트를 처리하는데 필요한 데이터요소, 이벤트 반응 후의 시스템 상태
   

소프트웨어 개발 종류

• 새로운 소프트웨어 개발
• 기존 소프트웨어 개선