📌요구사항 분석이란
- 요구사항들을 완전한가?, 상충하지 않나? 등을 분석
- 요구사항들을 분석하고 정제하여 정해진 모델, 양식으로 만드는 것
📖모델링 방법
- DFD
- UML : use case modeling
📌Use case
- 각 상호작용에서 유저의 관점에서 바라보는 요구사항을 기술하는 것
- UC : 시스템에서 제공하는 기능
- 시스템 : 모든 UC들을 모은 것
- 유저와 개발자, 테스터 등의 사이에 커뮤니케이션에 사용됨, 개발동안의 가이드 라인
📖의의
- 우리가 만들고자 하는 것이 무엇인가 정의
- 유저가 쉽게 이해 가능
- 고객과 개발자 사이의 커뮤니케이션이 원활
📖Use case의 Reader
- client team : Customer, Users
- developer team : Designer, Tester, PM 등
📖Use Case Diagram
- Actors : 시스템 밖에서 시스템과 상호작용하는 무언가, 유저, 다른 시스템, 센서 등
- Use Case : Actors가 사용하는 기능, 시스템에게 원하는 어떤 것
- line : 어떤 Actor가 어떤 Use case에 관여한다, 화살표는 누가 관여를 시작하는지
- 기본적으로 Use Case들 사이에 line을 그리지 않음
📖Use Case model 만드는 과정
- identify actors : 누가 사용하나?, 시스템을 사용하는 또 다른 시스템은?
- describe actors : 해당 액터가 무엇을 원하는가?
- identify use cases
- describe use cases
- identify actor and use cases relationships
📖Structuring Use Case Model
Include-Relationship
- Use case간의 포함 관계
- 돈을 인출하고 보내고 과정에 고객 확인은 포함되므로
Extend-Relationship
- 조건부로 포함될때
- caller과 callee에서 callee는 caller의 정보를 봐야할 수도(무엇을 신청하거나) 필요 없을 수도(그냥 단순한 QnA)있음
Use Case Generalization
- 유사한 두 case의 부모 case를 지정(상속 느낌)
- 전화 주문, 어플 주문에서 공통되는 부분과 조금씩 다른부분이 있음
📖Use Cases Specification
- 위에서 그림을 간단하게 그리고 구체적인 플로우를 문서에 기술
- Preconditions : 해당 use Case를 시작하기 위한 조건
- Postconditions : 해당 use Case가 끝나면 어떤 조건이 된다
📌요구사항 명세(SRS)
- 중요한 공식적인 문서, 모두가 같은 문서를 봐야함 함부로 수정 불가
- 사용자 요구사항과 고객의 요구사항이 모두 포함
- 개발자 수준의 상세 내용 필요
- 무엇을 할것인지 위주로 기술
📖기본 목차
- 개요
- 사용자 요구사항
- 시스템 요구사항
- 기능적 요구사항
- 비기능적 요구사항
📌요구사항 검증
- 검증, 검토할 요소
📖검증 방법
- 문서로 분석
- 프로토타입 제작
- 테스트 케이스 만들어보기
📌요구사항 관련 요약
- 고객으로부터 요구사항 추출(애매하고 불확실함)
- 요구사항 공학 과정을 통해 명확하게 문서 작성 및 Diagram 그리기
- 최종 SRS 작성
