요구사항 분석 및 설계

Part 1. Requirement Engineering

요구사항 엔지니어링이란 다양한 Task와 방법을 통해 고객의 요구사항을 이해하는 것으로, 설계와 구축을 이어주는 기반이 된다.

1. Requirement Engineering

Requirement Engineering의 과정은 다음과 같다.

1. Eliciation(추출)

2. Elaboration(정제)

3. Negotiation(조정)

4. Specification(정의)

5. Validation(검증)

6. Requirement management(요구사항 관리)

1-1. Elicitation(추출)

모든 stakeholders로부터 요구사항을 도출하는 것

*Elicitation의 문제

(1)범위(Domain)의 문제

-불명확하고 불필요한 기술적 세부사항

(2)이해의 문제

-컴퓨팅 환경의 제약 조건과 성능에 대한 이해의 부족

-문제 영역 전반에 대한 이해 부족

(3)변경의 문제

-요구사항은 지속적으로 변경된다.

1-2. Elaboration(정제)

- Elicitation 단계에서 획득한 정보를 확장하고 정제한다.

- 정제된 요구사항 모델 개발에 초점을 맞춘 Task이다.

- 데이터, 기능, 그리고 동적인 요구사항을 식별하는 분석 모델 생성

-사용법 시나리오의 창조와 정제에 의해 Task 진행

1-3. Negotiation(조정)

- 다양한 stakeholders 사이의 논쟁을 조정

- 요구사항의 우선순위 결정, 요구사항에 대한 비용과 리스크 분석, 내부적 갈등 추적, 요구사항의 삭제/결합 또는 수정의 반복적인 접근법 사용

1-4. Specificatin(정의)

- 명세서 작성

1-5. Validation(검증)

- 요구사항 엔지니어링의 결과가 올바른 품질을 가지고 있는지 평가한다.

1-6. Requirement management(요구사항 관리)

프로젝트가 진행되는 동안 언제든지 요구사항이 변경되고 추적될 수 있도록 도와준다.

2. 요구사항 정의 방법

(1) User Story: Agile Process에서 사용

(2) Use-case Diagram과 Class Diagram: UP 또는 기존 process에서 사용

(3) Formal Language: Formal Method에서 사용

(4) Text, Graph(diagrams), 수학적 기호, 테이블 등을 사용하여 요구사항을 정리하면서 모델화 작업을 수행

2-1.요구사항 분석 방법들

(1)기능적 요구사항

기능적 요구사항 분석을 위해서 flow-oriented model, use-case diagram, class diagram 등을 사용한다.

구조적 개발 방법론에서는 flow-oriented model, 객체 지향 개발 방법론에서는 use-case diagram, class diagram 및 UML을 사용한다.

(1)-1. flow-oriented modeling

-구조적 개발 방법론에서 주로 사용한다.

-연속, 선택, 반복의 논리적인 구조를 사용한다.

(1)-2. use-case diagram

- 시나리오 모델링

(1)-3. class diagram

- 문제 영역에서 클래스를 추출하여 분석한다.

- 개념 클래스와 분석 클래스로 구성된다.

※use-case diagram은 요구사항 정의 단계에서, class diagram은 요구사항 분석 단계에서 사용된다.

(1)-4. Behavior Modeling

- 동적인 요구사항을 나타낸다.

- sequence/activity diagram을 나타낸다.

(2)Data 요구사항

-ER Diagram(Entity-Relationship Diagram)

(2)-1. Data Modeling

- 자료 구조 및 DB 분석 및 설계에 사용된다.

- 주로 Entity-Relationship Diagram이 사용된다.

(3)사용자 인터페이스 요구사항

-GUI tool(graphic tool)

2-2.기능적 요구사항과 비기능적 요구사항

(1)기능적 요구사항

-시스템이 제공해야 할 서비스

-시스템이 입력에 반응하는 내용

-시스템의 오류 처리

→일반 언어, 그래픽 언어, 정형 언어 등으로 작성할 수 있다.

(2)비기능적 요구사항

-시스템이 실행되는 환경에서 지켜야할 제약 등

-실행 속도, 실패율, 메모리 성능, 개발 언어 등

→기능적 요구사항은 오류가 있으면 수정이 쉬울 수 있으나, 비기능적 요구사항은 만족하지 못하면 수정이 더 어려울 수 있다.

Part 2. Software Design

-분석된 요구사항 명세서를 참조하여 개발자가 실제적으로 개발할 수 있는 문서를 작성하는 과정

-설계 목표를 설정하고 아키텍처 안을 만든 후 최적의 설계를 한다.

-시스템 구조에 대한 설계, 모듈 설계, 자료에 대한 설계, 사용자 인터페이스 설계, 통신 방법에 대한 설계 등을 포함한다.

-설계 작업의 결과는 명세서로 작성되며, 이 명세서는 프로그래밍을 위한 뒤면 역할을 한다.

(1)설계의 두 단계

(1)-1.아키텍처 설계

소프트웨어를 구성하는 모듈 간의 관계 및 구조를 설계하는 것이다.

(1)-1.아키텍처 설계

각 모듈을 알고리즘 수준까지 설계하는 것이다.

(2)사용자 인터페이스(User Interface, UI) 설계

-Easy to use

-Easy to understand

-Easy to learn

(3)모듈

-시스템을 모듈 단위로 나누면, 각각의 모듈별로 관리 및 수정이 가능하므로 효율적이다.

-모듈로 나누는 기준은 결합도(coupling)과 응집도(cohesion)이다.

-모듈의 크기가 작으면, 모듈 내 에러의 발생은 줄어들지만 모듈 통합에 많은 에러가 발생한다. 반대로 모듈의 크기가 크면, 모듈 내 에러의 발생은 증가하지만 모듈 통합에 비교적 적은 에러가 발생한다. 따라서 모듈을 적절한 크기로 나누는 것이 좋다.

(3)-1.결합도(coupling)

결합도는 모듈 간의 정보를 주고받고 종속성의 정도를 말한다. 결합도는 낮을수록 좋다.

Data Coupling>Stamp Coupling>Control Coupling>Common Coupling>Content Coupling

-Data Coupling: 각 모듈간 파라미터를 이용해 데이터를 주고 받는 것

-Stamp Coupling: 각 모듈이 동일한 구조의 자료구조를 참조하는 것

-Control Coupling: 모듈이 다른 모듈로부터 제어 흐름을 입력받는 것

-Common Coupling: 여러 모듈이 하나의 데이터 영역을 참조하는 것

-Content Coupling: 모듈이 다른 모듈의 내부 기능과 데이터를 참조하는 것

(3)-2.응집도(cohesion)

응집도는 모듈 내 여러 요소의 연관성을 나타내며, 응집도는 높을수록 좋다.

Functional Cohesion>Sequential Cohesion>Communicational Cohesion>Procedure Cohesion>Temporal Cohesion>Logical Cohesion>Coincidental Cohesion

-Functional Cohesion(기능적 응집도): 모듈 내의 모든 요소가 동일한 기능을 수행하는 것

-Sequential Cohesion(순차적 응집도): 한 요소의 출력이 다른 요소의 입력이 되는 것

-Communicational Cohesion(통신적 응집도): 여러 요소들이 동일한 입/출력을 받아 다른 기능을 수행하는 것

-Procedure Cohesion(절차적 응집도): 모듈내의 여러 요소들이 순차적으로 수행되지만 흐름 제어 요소가 전달되는 것

-Temporal Cohesion(일시적 응집도): 모듈 내의 여러 요소들이 순서에 상관없이 특정 시점에 수행되는 것

-Logical Cohesion(논리적 응집도): 모듈 내의 여러 요소들이 비슷한 기능을 수행하지만 서로의 관계는 밀접하지 않은 경우

-Coincidental Cohesion(우연적 응집도): 모듈 내의 여러 요소들이 아무런 관계도 없는 경우

(4)Object-Oriented Analysis & Design

객체를 중심으로 분석과 설계하는 것

Part 3. 재사용

재사용은 다른 기능을 가진 프로덕트 개발을 쉽게 하기 위해 다른 프로덕트의 컴포넌트를 사용하는 것이다.

(1)재사용의 형태

(1)-1.기회적(우연적) 재사용

일단 프로덕트를 구축하고, 그 후 재사용 가능한 컴포넌트를 저장하는 것

(1)-2.체계적(고의적) 재사용

일단 재사용 가능한 컴포넌트를 구축하고, 그 후 컴포넌트들을 재사용해 프로덕트를 구축하는 것

(2)재사용의 고려사항

(2)-1. 재사용의 비용

-재사용 가능한 컴포넌트를 개발하는데 필요한 비용

-재사용하는데 드는 비용

-재사용을 프로세스를 정의하고 구현하는데 드는 비용

(2)-2. 법적 문제

(2)-3. 상용 소프트웨어에 대한 소스코드의 부족

(3)재사용

(3)-1. 설계와 구현에서의 재사용

라이브러리 및 툴킷

-라이브러리 및 툴킷은 재사용 가능한 루틴의 집합이다.

-사용자에게 제어 로직을 지원한다.

프레임워크

-프레임워크는 설계의 제어 로직을 통합한 것이다.

(3)-2. 설계에서의 재사용

디자인패턴

-패턴은 일반적인 설계문제의 해결책이다.