소프트웨어 공학 이론 정리 -8장- <요구사항 설계와 접근법>

Requirement Analysis

-      성격

• 소프트웨어의 기능과 행동을 분명하게 표시해야 한다.
• 다른 소프트웨어 요소와의 인터페이스를 명확하게 보여줘야 한다.
• 소프트웨어가 반드시 가지게 될 제한사항을 제시해야 한다.

-      소프트웨어 엔지니어가 요구사항 분석을 위해 해야 할 일

• 일찍이 작성된 추상적인 basic 요구사항을 펼쳐보아야 한다.
• 유저의 다양한 관점에서 필요한 요구사항을 확인하고, 이를 모델화해야 한다.

Requirement Models (요구사항 모델) 표현법 (구체화하는 방법)

-      Scenario-based models :
시스템 내 다양한 Actor의 관점에서 필요한 요구사항을 그려낸다.

-      Class-oriented models :
object-oriented 된 클래스로 표현하는 방법이다. 이 때, class가 해야 하는 일과, 협력관계를 설명하며 요구사항을 만족시켜야 한다.

-      Behavioral models(BM : 행동모델) :
내/외부적 이벤트에 따라 소프트웨어가 작동하는 방법을 묘사한다.

-      Data models :
요구사항(problem)에 맞춰진(domain) 데이터 모델을 묘사한다.

-      Flow-oriented models :
단계적인 공정과정(functional elements)을 통해 data의 흐름을 설명한다.

 

 

A Bridge

• 시스템 설명 : 시스템의 목적, 사용자와 같은 것을 추상적으로 제시
• 분석모델 = 브릿지 => 디자인 모델에 시스템 설명을 구체적으로 전달해줘야 함
• 디자인 모델 : 설계단계에 사용되는 모델

Rules of Thumb (최고의 룰)

-      분석 모델은 내용 압축도 (level of abstraction)는 다른 낮은 레벨의 모델에 비해 상당히 높다. (Design, Implementation에 비해서)
대신 비즈니스나 요구사항에 있어 눈에 보이는 영역에 집중한다.

-      분석 모델은 소프트웨어의 기능, 정보, 행동에 대해 직관적으로 보여줄 수 있어야 한다.

-      분석 모델은 모든 stakeholders의 요구사항에 부합하는 가치를 제공할 수 있어야 한다.
그렇기 때문에, 최대한 심플하게 모델이 제공할 수 있게 해야 한다.

 

 

Requirements Modeling Principles(요구사항 설계의 원칙)

-      Principle 1. 요구사항 (problem)을 해결하는데 사용되는 데이터의 용례가 이해되고 표현되어야 한다.

-      Principle 2. 소프트웨어가 갖춰야할 function(기능)이 선언되어야 한다.

-      Principle 3. 소프트웨어의 행동(behavior)이 잘 표현되어야 한다.

-      Principle 4. 모델은 정보, 기능, 행동이 나뉘어서 표현되어야 하는데, 이 때 단계별로 (혹은 hierarchical) 표현한다.

-      Principle 5. 분석에서 하는 일은 필수 정보를 구현에서도 사용될 수 있게 일관성 있게 표현 되어야 한다.

Scenario-Based Modeling : Actors and Profiles

A UML actor models an entity that interacts with a system object

-      Actor는 stakeholder에 포함되는 사람이나 시스템과 정보를 교류하는 시스템 밖 하드웨어가 될 수 있다.

A UML profile provides a way of extending an existing model to other domains or platforms

-      UML profile은 Standalone 시스템을 웹 기반 시스템과 모바일 플랫폼과 같은 곳으로 확장시키는 역할을 한다.

-      Profiles은 다양한 유저의 관점을 상대하는 시스템을 구성할 수 있게 돕는다.

Use Cases = 행동에 대한 계약

-      Use case는 외부에서 시스템을 사용하는 Actor에 의해서 작성된다.

-      Use case를 만들 때 고려해야 하는 것

• 어떤 것을 써야 하는가? Actor가 요구하는 기능을 프로세싱하는 과정
• 얼마나 많이 써야 하는가?(about size) 하나의 요구사항에 대해 여러 use case가 존재할 수 있으며, 적정양을 만들어야 한다. (너무 많으면 디자인적인 문제가 생김)
• Use case 안에 얼마나 자세히 쓸 것인가? 자세할수록 좋다.
• 얼마나 use case를 organize할 것인가?