[OOP/UML] UP - Inception 단계

# 개요

보통 1주간 진행되는 짧은 단계로 아래의 질문들에 대해 생각해본다. 

• What is the vision and business case for this project?
• Feasible?
• Buy and/or build?
• Rough unreliable range of cost: Is it $10K-100K or in the millions?
• Should we proceed or stop?

대부분 Brief format (3줄 정도) 수준으로 작성한다. 

 

# Artifacts

그렇게 많은 UML을 그리지 않는다. 필요한 만큼만 그린다. 

# Requirements

시스템을 만족하기 위한 Capabilities와 Conditions를 뜻한다. 

 

Requirement를 찾는 것을 Requirement analysis라고 하는데,

UP에서는 iteratively하고 skillfully하게 진행한다. 

• waterfall에서는 초기에 다 찾아야 하므로 iteratively 하지 않다. 
• 고객과 함께 requirements workshop을 하고 계속해서 데모를 보여주며 확인한다. (agile방식)

## 종류

요구사항은 아래 다섯 가지 카테고리와 기타로 나뉘는데 약자를 따서 FURPS+라고 한다. 

Supportability 대신 요즘은 Security를 많이 쓴다. 

• Functional : features, capabilities, security
• Usability : human factors, help, documentation
• Reliability : frequency of failure, recoverability, predictability
• Performance : response times, throughput, accuracy, availability, resource usage
• Supportability : adaptability, maintainability, internationalization, configurability

위는 오래된 방식이고, 보통은 쉽게 Functional / Non-Functional Requirements로 구분한다. 

 

Functional Requirements는 Use case로 작성하고,

Non-Functional Requirements는 Supplementary Specification으로 작성한다. 

 

Non-Functional Requirements는 Quality attributes/requirements라고도 부른다. 

시스템에 따라서는 이게 더 중요하고 아키텍쳐에 영향을 많이 준다. (특히 Security쪽)

 

이 모든게 elaboration 단계에 가면 Software Requirements Specification (SRS)에 작성된다. 

 

## Non-functional requirements

Use Case에 적히는 요구사항 외에 Glossary, Vision, Business Rules 등이 있는데

이런 것들은 모두 Supplymentary Specification에 적힌다. 

 

예시는 아래와 같다. 

# QUIZ

정답: 1번. Elaboration phase에서 한다. 

3번 - Elaboration에서는 구현해보면서 해결하는 것이고 Inception에서 찾긴 해야 한다. 

4번 - Inception 단계에서는 feasibility 확인을 위해 prototype을 만든다. 

 

정답: 3번. 기능 요구사항도 아키텍쳐에 큰 영향을 미치지만 비기능 요구사항도 아키텍쳐에 큰 영향을 미친다. 

 

다만 비기능 요구사항은 기능 요구사항만큼 큰 문제를 일으키진 않는다. 

가령 속도가 느리다고 출시가 안되는건 아니다. 

정답: 2번. Use Case는 요구사항을 뽑아내기 위한 것이므로 OOAD뿐만 아니라 C나 C++에서도 효과적이다. 

 

Use Case를 작성할 때는 구체적인 시스템이 확정된 단계가 아니므로 더더욱 맞지 않다.