Inception
- Short initinal step (Feasibility Study)
- Not the requirement phase
- Go or Stop을 결정할 사람에게 보고할 자료를 만드는 정도의 단계
- Artifacts : Use-Case Model, Supplementary specification, Glossary Vision, Business Rules,... , erc.
Requirements
- Capabilities and conditions to which the system must conform
→ Requirements(요구사항)은 시스템이 준수해야 하는 기능 및 조건을 말하는 것
- In the UP, requirements are analyzed iteratively and skillfully.
→ 요구사항 분석은은 고객과 팀 구성원 모두에게 명확한 형태로 정말로 필요한 정보를 찾고, 의사소통하며, 조직화해야 하기 때문에 매우 중요한 단계입니다. 따라서 다음과 같은 기술을 통해 반복적으로 능숙, 숙련된 방법으로 분석되어야 합니다.
Types and Categories of Requirements : FURPS+ model
- 지금은 많이 쓰지는 않고, 그냥 checklist 정도로 참고!
(기능)
– Functional : features, capabilities, security
산출물 → Funtional Requirement : Use-Case Model로 Brief Format으로 작성
(이하 비기능 , aka Quality attributes/requirements)
– Usability : human factors, help, documentation
– Reliability : frequency of failure, recoverability, predictability
– Performance : response times, throughput, accuracy, availability, resource usage
– Supportability : adaptability, maintainability, internationalization, configurability
산출물 → Supplementary Specification라는 문서에 기능이 아닌 모든 것들을 작성
Quiz) 다음 중 Inception 단계에서 수행되는 활동 또는 결과물이 아닌 것은?
① Client, Architect 등 모든 과제 관련자들이 참가하는 Requirements Workshop을 개최한다.
② 대부분의 Use-Cases가 Brief 포맷으로 작성된다.
③ 대부분의 Architecturally Risky Requirements가 찾아진다.
④ 필요한 경우 Technical proof-of-concept을 위한 Prototype을 만든다.
Quiz) 다음의 요구사항(Requirements)에 대한 설명 중 올바르지 않은 것은 무엇인가요?
① 요구사항은 일반적으로 크게 기능 요구사항과 비기능 요구사항으로 구분할 수 있다.
② 비기능 요구사항은 시스템의 품질(Quality)에 큰 영향을 미치므로 Quality Attributes/Requirements 라고도 한다.
③ 시스템의 SW Architecture에 영향을 크게 미치는 요구사항은 기능 요구사항이다.
④ UP에서 일반적으로 기능 요구사항은 Use-Case Model로, 비기능 요구사항은 Supplementary Specification으로 작성된다.
Quiz) Use-Case에 대한 다음의 설명 중 올바르지 않은 것은?
① Use-Case는 요구사항을 체계적으로 분석하는 방법이다.
② Use-Case는 비(非) OOAD 개발 시에 사용하면 효과가 상당히 반감된다.
③ Use-Case는 모든 OOAD 개발방법론에서 사용되는 중요한 시작점(Starting-Point) 중의 하나이다.
④ Use-Case를 이용한 다양한 요구공학(Requirements Engineering) 방법론이 있으나, UP에서는 가장 간단한 수준으로만 Use-Case를 활용한다.
Quiz) UP기반 OOAD는 요구사항(requirements)을 iteratively 하고 skillful하게 분석한다고 주장합니다. 이 주장이 의미하는 바를 구체적으로 설명하세요.
→ Requirements(요구사항)은 시스템이 준수해야 하는 기능 및 조건을 말하는 것으로, 프로젝트 진행이 이어질 수록 번복하기 어려워지는 프로젝트의 공통 주제를 말합니다.
즉, 요구사항 분석은은 고객과 팀 구성원 모두에게 명확한 형태로 정말로 필요한 정보를 찾고, 의사소통하며, 조직화해야 하기 때문에 매우 중요한 단계입니다.
따라서 다음과 같은 기술을 통해 반복적으로 능숙, 숙련된 방법으로 분석되어야 합니다.
- 고객과의 use case 작성
- 개발자와 고객 모두를 참석하는 요구사항 워크샵
- 고객에게 피드백을 요청하기 위해 각 iteration 단계의 결과를 데모
본 글은 개인의 S/W 구조설계 역량 강화를 위한 학습 목적으로 정리된 내용입니다.
일부 타/개인 단체에 저작권이 있는 자료를 포함하고 있으므로, 절대 영리 목적으로 사용하실 수 없습니다.
'SW 공부 > OOP_OOAD_UML' 카테고리의 다른 글
[OOAD] 3-2. Elaboration - OOD (2) | 2022.08.29 |
---|---|
[OOAD] 3-1. Elaboration - OOA (2) | 2022.08.29 |
[OOAD] 1. Introduction of Object-Oriented Analysis and Design (2) | 2022.08.29 |
[UML] Component Diagram (2) | 2022.08.29 |
[UML] Activity Diagram (2) | 2022.08.29 |
댓글