[Object Oriented S/E] Chapter 3 - System Engineering(2)

# 범위

58page ~ 65page

# 내용

## 3.3 SYSTEM REQUIREMENTS DEFINITION

• System requirements은 비지니스 니즈를 파악하며, 초기 단계에 설정되고 개념을 확장해나간다.
• 비즈니스 니즈를 파악하는 것은 정보수집활동을 하는 것이다.
• 정보 수집 방법에는 고객발표, 현재 사업 운영에대한 연구, 유저 설문, 사용자 인터뷰, 문헌조사가 있다.
• 시스템 요구사항은 어떠한 예산, 납품 기일, 정치적 제약, 비용 효율성과 같은 여러 이유로 요구사항이 충족되지 못할 수 있다.
•  

## 3.4 SYSTEM ARCHITECTURAL DESIGN

• 시스템 아키텍처를 디자인 하는 것은 모든 공학의 능통한 전문가를 고용해서 하는 것이 좋지만, 이런 사람들은 고용하기 어렵다(너부 비싸다)
• 그렇기 때문에 각각의 시스템을 계층적으로 분리시키고, 해당 서브시스템의 엔지니어가 역할을 맡는다.
• 이러한 것들은 복잡도와 비용도를 감소시켜주기도 한다.
• 요구사항을 분리된 서브시스템에 할당함으로써, 공유되는 요구사항들이 줄어들고 책임이 명확해진다.
• 시스템 아키텍처를 시각화 해야 한다.
• 시스템 분해과정에서는 top-dwon, 분할정복의 방식이 주로 사용된다.
• 분해된 시스템들은 더이상 하위로 나눌수 없을만큼 잘 나뉘어야 하고, 기술적으로 잘 나뉘어서 여러분야에 능한 엔지니어를 사용하지 않도록 해야한다. 또한 합치기 쉬워야 한다.
• 분해된 시스템에 요구사항을 배정해야 한다.
•