4장. 요구사항 개발 및 관리

 

[요구사항의 정의]

: 문제의 해결 또는 목적 달성을 위하여 고객에 의해 요구되거나, 표준이나 명세 등을 만족하기 위하여 시스템이 가져야    하는 서비스 또는 제약 사항.

- 고객이 요구하지 않았던거라도 당연히 제공되어야 한다고 가정되는 것들도 포함

 

 

[요구사항의 중요성]

: 요구사항을 정확하고 분명하게 작성하지 않으면, 이 이후 과정에 수많은 수정 작업이 들어가 어려움이 발생한다.

: 제품의 전체적 파악위해 의사소통 시간을 절약해주는것.

: 상세한 요구사항 있어야 비용산정이 가능하고, 이를 기반으로 계획을 수립할수 있다.

* 프로젝트 진행중에 가장 중요한 과정!

 

 

[요구사항의 분류]

- 기능적 요구사항(Functional Requirements)

  : 제품 구현위해 소프트웨어가 가져야할 기능적 속성.        ex)파일저장기능, 편집기능, 보기기능등

- 비기능적 요구사항(Non-Functional Requirements)

  : 제품 품질 기준등 만족위해 소프트웨어가 가져야할 특성  ex) 성능, 사용의 용이성 신뢰도, 보안성, 안전성등

 

 

[요구사항 개발]

: 고객으로 부터 구현될 제품의 사양을 정확히 도출해 요구사항을 명세하고, 이를 분석한 결과를 개발자들이 이해할수 있는 형식으로 기술하는 작업

 

# 요구사항 개발 프로세스

1. 요구사항 추출

: 고객이 원하는 요구사항을 수집

: 수집된 요구사항을 통해 개발될 시스템에 대한 요구, 기능, 제약사항을 식별, 이해하는 단계

* 고객의 최초 요구사항은 추상적이기 때문에 수주자는 정확한 요구사항을 파악해야됨.

<추출 기법의 종류>

  1) 인터뷰 : 요구자, 사용자와 직접적 대화를 통해 요구사항 추출. 

    - 미리 정형화된 질문 양식을 만들어서 배포

    - n차에 걸쳐 실시하는게 일반적

  2) 시나리오 : 시스템과 사용자간에 상호 작용을 시나리오로 작성해 요구사항 추출.

    - 시나리오에 포함될 필수 정보 

      : 시나리오 시작 직전 시스템 상태

      : 정상적 사건 흐름

      : 예외 흐름

      : 동시수행하는 다른 행위정보

      : 시나리오 완료후 시스템 상태

 

2. 요구사항 분석

: 추출된 요구사항을 분석 기법을 이용해 식별 가능한 문제들을 도출하고 요구사항을 이해하는 과정

: 추출된 요구사항을 명세서 작성전에 완전하고 일관성잇는 요구사항으로 정리하는 활동

<분석 기준>

 1) 시스템을 계층적이고 구조적으로 표현해야된다.

 2) 인터페이스(외부) - 시스템(내부) 간 인터페이스 정확히 분석해야한다.

 3) 분석단계 이후의 설계, 구현단계에 필요한 정보를 제공해야한다.

<분석 기법의 종류>

 1) 구조적 분석 : 전통적. 프로세스, 모듈간 작업흐름을 작성하는 방법

 2) 객체지향 분석 : 요구사항을 시나리오 분석을 통해 유스케이스 모델로 구축

 

3. 요구사항 명세

: 분석된 요구사항을 명확학 안전하게 기록.

- 최종결과물 : 요구사항 명세서(SRS)

- 요구사항 명세서(SRS)

  : 프로젝트 산출물 중 가장 중요한 문서

  : 모두에게 공동의 목표를 제시

  : 시스템이 HOW(어떻게 수행)가 아닌 WHAT(무엇을 수행)에 대한 기술

 <요구사항 명세서 작성 방법>

  1) 시스템이 수행할 모든 기능, 시스템에 영향주는 제약 조건을 명확히 기술

  2) 고객, 개발자 사이에서 모두가 이해하기 쉽고 간결히 작성. (둘다보는 유일한 문서)

  3) 검증이 가능 => 원하는 시스템의 품질, 상대적 중요도, 품질의 측정, 검증 방법 및 기준등을 명시.

  4) I/O만 작성. 그 과정(process)는 기술하지 않는다.

  5) 계층적으로 구성 : 시스템기능 이해, 변경에 대한 영향 분석 목적

  6) 요구사항을 고유의 식별자를 가지고 번호화, 우선순위화. 

 

4. 요구사항 검증

: 만든 SRS를 검토

: 요구사항이 사용자나 고객의 목적을 완전히 기술했는지

: 요구사항 명세가 문서 표준을 다루고, 설계 단계의 기초로 적합한지.

1) 요구사항 타당성 검증

  : 요구사항이 설계 기준에 따라 HW, SW에 적절히 할당되고 안전, 보안, 위험성 관련된 요구사항이 정확한지를 증명하는 것.

  <검증 내용>

   - 무결성, 완전성                  : 요구사항이 에러없이 반영여부

   - 일관성                            : 요구사항 모순 여부

   - 명확성                            : 요구사항의 모호함 여부

   - 기능성                            : HOW보다 WHAT에 관점 여부

   - 검증 가능성                     : SRS기재사항들이 사용자 요구 만족 여부

   - 추적가능성 및 변경용이성   : 설계문서 추적 여부

2) 요구사항 명세 구조 검증 : 정의된 요구사항으로 구현되는 시스템이 사용자의 요구와 목표를 만족여부 검증

3) 요구사항 공통 용어 검증 : 용어들의 공동된 인식 검증

 

 

[유스케이스 기반의 요구사항 분석]

: 요구사항 분석 방법중 객체지향 방법인 유스케이스 기반의 분석.

#요구사항 분석 방법

 

[UML의 개요]

: 통합된 표준 객체지향 모델링 언어 => UML표기법만 알면 의사소통의 불일치 지적 가능!

: 기존에는 다양한 객체지향 모델링 방법이 있었고, 서로 다른것을 쓰면서 많은 불편함과 어려움이 발생.

  그래서 이 기업들이 모델링 기법을 통일했고, OMG라는 비영리단체가 유지보수 하게끔 하였고 이게 바로 UML이다.

- 역할 : 시스템에 대한 다양한 뷰(view)를 제공.

 

 

[유스케이스 다이어그램]

: 사용자 관점에서 시스템의 서비스와 기능 및 그와 관련한 외부 요소를 보여주는 다이어그램.

#유스케이스 다이어그램의 예

# 구성 요소와 표기법

 - 시스템(System) : 만들고자 하는 시스템의 범위.  #사각형

 - 액터(Actor) : 시스템 외부에서 시스템과 상호작용하는 사람 or 다른 시스템  #사람모양

 - 유스케이스(Usecase) : 시스템이 액터에게 제공해야하는 기능의 집합. "~한다"체로 표현.  #타원

 - 관계(Relationship) : 액터와 유스케이스 사이의 의미있는 관계  #선

   1) 연관관계 : 서로간 상호작용이 있음을 표현  #실선

   2) 포함관계(include) : 하나의 유스케이스가 다른 유스케이스의 실행을 전제로 할때 형성되는 관계  #점선,include

   3) 확장관계(extend) : 확장대상 유스케이스 수행시 특정 조건에 해당 유스케이스를 수행하면 적용.  #점선,extend

 4) 일반화 관계 : 이해도를 높이기 위한 관계. 세부적 표현   #화살표선

 

 

[유스케이스 다이어그램 작성 순서]

1. 액터 식별

  <액터 찾기위한 질문>

    - 누가 정보 제공, 사용 삭제?

    - 누가 or 어디서 이 시스템 사용할지

    - 누가 요구사항에 관심가지고, 결과에 관심 있는지

    - 누가 유지보수 및 관리 하는지

    - 개발될 시스템과 상호작용하는 HW, SW는 무엇인지

 

2. 유스케이스 식별

  <유스케이스 찾기위한 질문>

   - 액터가 원하는 시스템 제공 기능이 뭔지

   - 액터가 시스템에 어떤 정보를 생성, 수정, 조회, 삭제 하고 싶어하는지

   - 액터는 시스템의 갑작스러운 외부변화에 어떤 정보를 필요로하는지

   - 시스템이 어떤 기능을 제공하면 액터의 작업이 효율, 편리해지는지

   - 모든 요구사항 만족하는 유스케이스가 모두 식별되는지

 

3. 관계 정의

  : 연관관계, 포함관계, 확장관계, 일반화 관계 식별

 

 

[유스케이스 기술서]

: 유스케이스 다이어그램 보완위한 산출물. 표준 없이 단체마다 다른 양식.

: 다이어그램은 시스템의 기능을 표현. 기술서는 해당 유스케이스가 어떻게 수행되는지를 표현하는 수단.

# 유스케이스 기술서 항목

  - 유스케이스명

  - 액터명

  - 유스케이스 개요 및 설명

  - 사전 및 사후 조건

  - 작업 흐름 : 1)정상흐름  2)대안흐름 : if  3)예외흐름

  - 시나리오

 

---

 

[Summary]

1. 요구사항을 정확하게 명세 하는 이유 : 참여자들로 항금 개발될 소프트웨어 제품을 전체적으로 파악해 의사소통 시간 절약. 상세한 요구사항 있어야 산정가능, 계획수립이 가능.(고객,사용자와 개발자가 공통으로 보는 거의 유일한 문서)   2. 기능적 요구사항과 비기능적 요구사항의 차이점   - 기능적 요구사항 : 제품 구현위한 기능적 특성   - 비기능적 요구사항 : 제품 품질등의 기준 만족 위한 특성 - 성능, 보안, 신뢰도등   3. 요구사항 개발 단계  : 요구사항 수립 -> 요구사항 분석 -> 요구사항 명세 -> 요구사항 검증   4. SRS란 무엇인가  : 요구사항 개발의 최종 목표. 요구사항 명세 단계에서 작성하는 자료이며, 고객,사용자등과 개발자가 공통으로 보는 중요한 문서이며, 모두에게 공통의 목표를 제시하며, 무엇을 수행할지(What)에 대해 명세하는 문서이다.   5. 유스케이스 다이어그램을 작성하는 이유  : 사용자 관점에서 바라보는 기능을 그려 이해도움 ==> 고객과 개발자가 이 다이억그램을 보며 요구사항에 대한 의견을 조율할수 있게끔 한다.   6. 유스케이스 다이어그램을 표현하는 절차  : 액터식별 -> 유스케이스 식별 -> 관계 정의