2. OOAD - Inception

Inception

1주동안 아래 질문들을 하는 short initial step이고 이를 통해 해당 프로젝트 진행 여부를 결정하게 된다.

• 우리가 할 수 있나?
• 살 수는 없는가? 꼭 직접 만들어야 하는가?
• vision은 무엇인가?

위 질문들을 답하기 위해서 요구사항을 식별하게 되는데

얇고 넓게 찾는 단계가 Inception이고, 깊게 디테일하게 찾을 때는 elaboration 단계이다.

 

Inception 단계의 Artifacts

• Use-Case Model : Funcional Requirements
• Supplementary Specification : non-Functional Requirements
• proof-of-concepts : 새로운 기술/도구를 적용 전에 한번 이용해보는 것
• Iteration Plan : Iteration을 어떻게 돌 것인지에 관한 계획

 

 

Requirements

시스템이 반드시 만족해야하는 condition들과 Capability들

Requirement analysis : client와 개발자 모두 분명하게 알아볼 수 있는 형식으로 진짜 필요한 것이 무엇인지 찾고 커뮤니케이션하고 조직화하는 것

 

Requirements in UP

UP에서 요구사항은 iteratively하고 skillfully하게 분석된다

• iteratively : waterfall은 처음에 완벽하게 요구사항을 식별하여 fix해야 하는 반면에 UP에서는 계속해서 식별할 수 있다.
• skillfully : requirement workshop에서 customer와 같이 작업 

 

FURPS+ model

requirement coverage를 위한 cheklist로 사용

• Functional : 기능
• 비기능
  • Usability
  • Reliability
  • Performance
  • Supportability
• + : Implementation, interface, legal 등

 

Quality Attributes/Requirements

Non-functional requirement의 한 종류로 (Usability + Reliability + Performance + Supportability 등)

Non-functional requirement 중 Quality Requirement가 아닌 경우

법을 따라야한다, 표준은 이것이다, 우리회사는 이 소스를 밖에 가지고 가면 안 된다, 언제까지 개발 해야한다, 사장님 보고는 이런 형식을 사용해야한다 등이 있다. 

 

Non-functional requirement도 functional requirement만큼 시스템 구조에 영향을 미친다.

 

 

 

Use Cases (functional Requirements)

Inception 단계에서 brief format(3줄 정도 작성)으로 가볍게 시작해서 Elaboration 단계에서 지속적으로 refine하며 종료한다.

보통 OOA에서는 캐쥬얼 format, OOD에서는 Fully Dressed Style로 작성한다.

 

 

Fully Dressed Style 예시)

 

 

Other(non-functional) Requirements

URPS+ quality attribute(F 제외), reports 어떤 포맷(워드, ppt 등)으로 써야하는지, 하드웨어와 소프트웨어 제약, 디자인 제약, licensing, legal concern, packaging, standards, domain rules 등 기능이 아닌 모든 것들은 Supplementary Specification에 작성한다.

 

Inception에서 시작해서 Elaboration에서 refine 된다.

 

 

 

 

비기능요구사항도 시스템 구조에 영향을 미친다.

비OOAD는 SASD를 의미하는데 Use case는 요구사항을 식별하는 방법이기 때문에 관련 없음.