4. Requirement Analysis

4.1 Requirement

📎 정의
: 소프트웨어가 제공해야 하는 시스템 (what, not how) + 시스템 제약사항

📎 요구사항 정의의 어려움
1) 요구사항의 복잡합
2) 원하는 것에 대해 정확히 알지 못하는 고객
3) 이해관계자(Stakeholders, 개발자와 고객)는 자기 자신의 언어를 사용하여 요구사항을 표현하며, 자신의 분야 지식은 모든 이해관계자가 알고있을 것이라고 착각
4) 변하는 요구사항
5) 여러 이해관계자가 관여할 경우 요구사항의 충돌

바람직한 요구사항은 당연히 빠지면(Missing) 안되지만 넘쳐서도(Superfluous) 안된다
-> 프로젝트의 리소스(노력, 시간, 비용) 등 불필요한 사용

바람직한 요구사항의 속성

1) ⭐️ Unambiguous (분명하다) : 모든 사람이 항상 똑같은 해석을 해야한다.
2) Correct : 고객이 분명히 원하는 것이어야 한다.
3) Complete : 모든 요구사항을 포함해야 한다.
4) Consistent : 요구사항 간 충돌이 없어야 한다.
5) ⭐️ Feasible : 구현이 가능해야 한다.
6) Traceable : 기능(설계,구현,테스팅)과 요구사항들을 연결할 수 있어야 한다.
 -> 요구사항이 어떻게 설계되고 개발되고 있는지 추적 가능해야 한다.

• Traceability
  

요구사항에서도 공학적인 절차가 필요하다

Require engineering (RE)

: 원하는 시스템에 대해 정확히 알지 못하는 고객에게서 추출된 요구사항은 바람직하지 않을 가능성이 있다. 이 요구사항들을 유스케이스 모델링 등의 방법을 통해 구체화 시키고 정제를 하여 궁금적으로 완전한 요구사항들을 추출 이를 SRS로 정리하는 과정이 Require engineering이다.

요구사항의 유형

1) User Requirement

• 고객을 위해 작성
• 자연어, 기술적인 내용 제외

2) System Requirement

• 개발자를 위해 작성
• 기능적(소프트웨어가 제공해야하는 시스템(what))과 비기능적 요구사항(제약사항)으로 나뉨
• 정밀하게 작성

• 기능적 요구사항은 input과 ouput의 관계에 대한 요구사항
  

4.2 Requirement Elicitation (요구 추출)

📎 요구사항 추출 대상
1) Customers
2) Domain experts
 -> 주문한 고객 조차도 원하는 SW를 정확히 모르는 경우가 있을 수 있다. 이 경우에는 도메인 전문가에게서 정보를 얻을 수 있다.
3) Stakeholders (이해관계자)
4) Users (주문한 사람 != 실사용자)
5) ⭐️ Reverse engineering
 -> 다른 회사의 유사 SW나 이전에 만들어놨던 제품으로 필요한 기능을 연구

📎 요구사항 추출에서의 문제점
1) Stakeholders

• 원하는 제품에 대해 잘 모르는 경우
• 원하는 제품에 대해 잘 설명하지 못하는 경우
• 원하는 제품을 알고는 있지만 전달될 때까지 인지하지 못하는 경우

2) Analysts

• 사용자가 가지고 있는 문제에 대해 그들보다 더 잘 안다고 오해하는 경우

3) Everybody

• 이해관계로 인해 추출의 어려움이 있는 경우

요구사항 추출의 기술

1) Customer presentation (workshop) : 사용자와 개발자가 만나 커뮤니케이션
2) Literature survey (문헌조사) & Business process and forms (업무 흐름과 양식)
3) Interview & Surveys
4) Brainstorming
5) Prototyping : 모형을 만들어보는 것

📎 Requirement Workshop

• 모든 이해관계자가 모여 주문한 고객이 요구사항 발표
• 정확한 문제, 중요한 특징 파악, 발생 위험들을 리스트화하고 우선순위 매김

📎 Background Reading

• 문헌조사, 기존 업무 프로세스, 기존 시스템 매뉴얼 조사
• 요구사항애 대해 잘 이해할 수 있음
• 문서가 실제 운영되고 있는 시스템과 정확히 일치하지 않을 수 있는 문제
• 문서 내 요구사항과 관련된 내용과 그렇지 않는 내용 구분 필요

📎 Brainstorming

• 회의의 한 형태
• 목적: 가능한 많은 아이디어를 만들어 내는 것
• 다른 사람의 의견에 대해 비판, 논쟁 자제 (일단 많은 아이디어를 만들어내는 것이 목표)

📎 Prototyping

• 모델을 만들어 보는 것
• 만들고자 하는 시스템 이해 및 피드백에 효과적
• 요구사항이 맞는지 확인
• 알지 못했던 요구사항 발견
• 많은 시간과 비용 발생

📎 Interviews & Surveys

• Interview : 특정 대상과 직접 만나는 방법으로 깊이있게 많은 정보를 얻을 수 있음
• Survey : 불특정 다수에게 설문조사 하는 방법으로 빠른 취합 가능, 설문조사 외의 내용은 취합 불가

4.3 Domain Analysis

• 요구사항의 배경지식을 알아야 정확한 해석이 가능
• 고객은 요구사항의 문맥, 배경 등 (ex. 학사운영)을 잘 알고있지만 개발자의 경우 모를 가능성도 있음

4.4 ⭐️ Use case

: 시스템과 사용자의 상호작용을 다이어그램으로 표현

요구사항 분석을 표현하는 모델
1) Structured analysis (구조적 분석)

• Data flow diagram (DFD)

2) Object-oriented analysis (객체지향 분석)

• UML : Use Case Modeling (UC)

• System scope : SW 시스템의 범위
• Actor : 시스템 사용자
• Use-Case : 시스템 요구사항

• 시스템 사용자, 프로그래머 등의 이해관계자들의 대화 매개체 역할
• SW 개발 전 주기에 있어서 가이드라인

유스케이스를 읽는 모든 이해관계자

-> SW 개발에 관련된 모든 사람들이 각자 역할에 따라 유스케이스 사용
1) Client team

• Customer : 주문한 시스템의 기능 확인
• User : 시스템 이해

2) Developer team

• Requirement Analysist : 요구사항 상세화
• Designer : 디자인 구상할 때
• Tester : 각각의 상호작용을 통해 테스트 케이스 구성할 때
• Project manager : 프로젝트 관리할 때
• Technical writer : 만들어질 시스템에 대한 가이드를 만들 때

Use case diagram 표기법

Actors

• 시스템 밖에서 상호작용 하는 Someone/Something
  - 사용자, other 시스템, 센서 (ex. 자동문)

Use case

• 사용자 관점에서의 시스템 기능

의사소통 관계

• Actor는 항상 Use Case와 상호작용
• -> (화살표) 혹은 - (직선) 으로 표현
• -> (화살표)는 그 기능을 시작하게 하는지를 강조할 때 사용
  

⭐️ 핵심포인트는 사용자의 관점에서 어떤 기능들을 제공하느냐에 관점에서 작성

유스케이스 작성

actors와 use cases를 찾고, 각각의 use case의 flow

• actors 찾기 및 기술
• use cases 찾기 및 기술
• actor와 use case 간 관계 찾기
• 다이어그램 그리기
• flow 그리기

Q. Actors는 어떻게 찾나요?

• 누가 시스템을 사용하나요?
• 누가 시스템으로부터 정보를 얻나요?
• 누가 정보를 제공하나요?
• 이 시스템이 어디에서 사용되나요?
• 누가 시스템을 유지보수 하나요?
• 시스템을 사용하는 다른 시스템이 무엇인가요?

Q. Use cases는 어떻게 찾나요?

• 찾은 actor가 시스템에 무엇을 원하나요?

확장된 Use case diagram 표기법

Include Relationship

• 유스케이스 간 포함관계
• 유스케이스들을 직선으로 연결 (원래의 유스케이스는 안되는 표기)
• 화살표가 향하는 유스케이스를 포함한다
  - ex) 인출, 예금, 이체를 할 때는 고객 확인을 한다.
  

Extend Relationship

• 조건부로 실행됨을 표현
• 화살표가 향하는 유스케이스: 확장 대상, 화살표를 보내는 유스케이스: 확장 기능
• 확장 대상을 수행할 때 특정 조건에 따라 확장 기능을 수행하는 경우에 적용
  - ex) 전화를 걸 때 발신인 표시를 하는 경우 (특정 서비스를 신청했을 때만)
  

Use Case Generalization

• 그룹을 만들어 이해도를 높이기 위한 관계 표현
  - ex) 주문을 한다 <= 전화 주문 + 인터넷 주문
• 화살표가 향하는 유스케이스가 부모 클래스와 같은 유형

Use Case Specification

• Preconditions
  : 시작하기 위해 갖춰져야 할 조건
• Postconditions
  : 유스케이스 종료 후의 상황

형식

• Use case name
• Desciption
  - Brief desciption
  - Priority (우선순위)
  - Importance (중요성)
  - Difficulty (구현에 있어서 쉬움/어려움)
• Actors
• Preconditions
• Basic flow
• Alternative flows
• Postconditions

4.5 ⭐️ SRS (Software Requirement Specification)

• 요구사항에 대해서 정리된 문서
• 사용자 요구사항과 시스템 요구사항 모두 포함
• 어떻게(how) 해야하는가 보다 무엇(what)을 해야하는가

Q. SRS는 누가 사용하나요?
-> stakeholders가 참조하게 되는 공통 목표, 가이드라인

목차

1. Introduction
2. User requirements
3. System requirements
   1) Functional requirements
   2) Non-functional requirements

4.6 Requirement Validation

• 고객의 요구사항 대로 잘 만들었는지 검증
  

Requirement review
: 위와 같이 질문 하면서 매뉴얼 검토
이러한 활동을 Walkthrough, Inspection, Formal review라고 부름 (정도의 차이는 있음)

Prototyping
: 프로토타입을 만들어 요구사항 검증

Test-case generation
: 직접 테스트케이스를 만들어 검증