소프트웨어 설계 1장 요구사항 확인 요약 3)요구사항, UML

요구사항의 개념 및 특징

- 요구사항 : 소프트웨어가 어떤 문제를 해결하기 위해 제공하는 서비스에 대한 설명과 정상적으로 운영되는데 필요한 제약조건 등

- SW 개발이나 유지 보수 과정에서 필요한 기준과 근거를 제공

- 개발하려는 SW의 전반적인 내용 확인 가능

 

요구사항의 유형

기술하는 내용에 따라

- 기능 요구사항(Functional requirements) : 시스템이 무엇을 하는지, 어떤 기능을 하는지에 대한 사항

- 비기능 요구사항(Non-functional requirements) : 주로 품질이나 제약사항에 대한 사항

기술 관점과 대상의 범위에 따라

- 사용자 요구사항(User requirements) : 사용자 관점에서 본 시스템이 제공해야 할 사항

- 시스템 요구사항(System requirements) : 개발자 관점에서 본 시스템 전체가 사용자와 다른 시스템에 제공해야 할 사항

 

요구사항 개발 프로세스

 

1. 도출 > 2. 분석 > 3. 명세 > 4. 확인

 

1.요구사항 도출(Requirement Elicitation, 요구사항 수집)

- 요구사항이 어디에 있고 어떻게 수집할 것인지 식별, 이해하는 과정

- 이해관계자가 식별됨

- 소프트웨어 개발 생명 주기동안 지속적으로 반복

- 요구사항 도출 주요기법 : 인터뷰, 설문, 브레인스토밍, 워크샵, 프로토타이핑 유승케이스 등

 

2. 요구사항 분석(Requirement Analysis)

- 요구사항 중 내용 중복, 상충되는 요구사항, 명확하지 않거나 모호한 부분 등을 걸러내기 위한 과정

- 사용자 요구사항의 타당성 조사, 비용과 일정에 대한 제약을 설정

 

3. 요구사항 명세(Requirement specification)

- 요구사항을 체계적으로 분석한 후 문서화 하는 것

- 기능 요구사항은 빠짐없이 완전하고 명확하게, 비기능은 팔요한것만 작성 사용자가 이해하기 쉬우며 개발자가 효과적으로 설계하도록 작성

- 설계 과정에서 잘못될 경우 요구사항 정의서에서 추적할 수 있어야 함

 

4 요구사항 확인(Requirement validation, 요구사항 검즘)

- 자원 할당 전에 요구사항 명세서가 완전하게 작성되었는지 검토

- 일반적으로 요구사항 관리 도구를 통해 문서들에 대한 형상관리 수행

 

*형상 : SW 개발 단계의 각 과정에서 만들어지는 프로그램, 프로그램을 설명하는 문서, 데이터 등

*형상관리 : SW 개발 과정에서 만들어지는 형상들의 변경 사항을 관리하는 일련의 활동

 

요구사항 분류

- 기능적 / 비기능적

- 하나 이상의 상위 요구사항에서 유도된것 / 이해관계자나 다른 원천으로 부터 직접발생

- 제품에 관한 것 / 개발 과정에 관한 것

- 우선순위에 따라

- SW에 미치는 영향의 범위에 따라

- 소프트웨어 생명 주기 동안에 변경될 가능성 여부에 따라

 

개념 모델링(Conceptual Modeling)

- 현실 세계의 상황을 단순화하여 개념적으로 표현(모델)하는 과정

- 모델링은 SW 요구사항 분석의 핵심

- 개체(Entity)들과 그들 간의 관계 및 종속성 반영

- 주로 UML을 사용하여 표기

 

요구사항 할당(Requirement Allocation)

- 요구사항을 만족시키기 위한 구성 요소를 식별하는 것

 

요구사항 협성(Requirement Negotiation)

- 요구사항이 서로 충돌될 경우 이를 해결하는 과정

- 요구사항이 서로 충돌된다면 우선순위를 부여하고 그외는 적잘한 기준점을 찾아 해결

 

정형분석(Formal Analysis)

- 구문과 의미를 갖는 정형화된 언어를 이용해 요구사항을 수학적 기호로 표현 한 후 이를 분석하는 과정

- 요구사항 분석의 마지막 단계에서 이루어짐

 

요구사항 확인 기법

- 문서화된 요구사항 관련 내용을 확인하고 검증하는 방법

 1. 요구사항 검토 2. 프로토 타이핑, 3. 모델 검증 , 4. 인수테스트 등

 

1. 요구사항 검토(Requirement Reviews)

- 문서화된 요구사항을 훑어보면서 확인하는 것

- 검토자 그룹에는 고객 대표자가 반드시 포함

- 시스템 정의서 시스템 사양서, 소프트웨어 요구사항 명세서 등

2. 프로토타이핑(Prototyping)

- 프로토타입을 만든 후 개발이 진행되는 동안 도출되는 요구사항을 반영하면서 지속적으로 프로토타입을 재작성 하는 과정

- 소프트웨어 엔지니어의 해석이 맞는지 확인하기 위한 수단으로 주로 사용

 

장점 : 빠르게 제작하고 반복되는 제작을 통해 발전될 결과물을 얻거나 변동 가능한 요구사항들이 감소, 완성 전에 문제점에 대한 식별과 피드백이 가능, 이해하기 쉬움

단점 : 프로토 ㅏ입에만 집중될 수 있음, 지속적이고 반복적인 프로토타입의 개선으로 인한 비용 부담

 

3. 모델 검증(Model Verification)

- 요구사항 분석 단계에서 개발된 모델이 요구사항을 충족시키는지 검증하는 것

- 객체 모델의 경우 의사소통 경로를 검증하기 위해 정적 분석을 수행하는 것이 유용

4. 인수테스트(Acceptance Tests)

- 사용자가 실제로 사용될 환경에 요구사항들이 모두 충족되는지(사용자 입장에서 확인하는 과정)

종류 : 사용자 인수 테스트, 운영상의 인수 테스트. 계약 인수테스트, 규정 인수 테스트, 알파 검사, 베타 검사

 

UML (Unified Modeling Language)

- 시스템 개발 과정에서 시스템 개발자와 고객 또는 개발자 상호간의 의사소통이 원활하게 이루어지도록 표준화한 대표적인 객체지향 모델링 언어

- 6개의 구조 다이어그램(시스템 구조를 표현) + 7개의 행위 다이어그램(시스템 동작을 표현) 작성가능

- 구성요소 : 사물, 관계, 다이어그램 등

 

사물(Things)

사물	- 모델을 구성하는 가장 중요한 기본요소 - 관계가 형성될 수 있는 대상
구조사물	- 시스템의 개념적, 물리적 요소를 표현 - 클래스, 유스케이스, 컴포넌트, 노드 등
행동사물	- 시간과 공간에 따른 요소들의 행위를 표현 - 상호작용, 상태 머신 등
그룹사물	- 요소들을 그룹으로 묶어서 표현 - 패키지
주해 사물	- 부가적인 설명이나 제약조건 등을 표현 - 노트

 

관계(Relationships)

- 사물과 사물 사이의 연관성을 표현하는 것

1. 연관 관계, 2. 집합 관계, 3. 포함 관계, 4. 일반화 관계, 5. 의존관계, 6 실체화 관계 등

 

1. 연관(Association)관계 

- 2개 이상의 사물이 서로 관련되어 있음

- 사물간 실선으로 연결, 화살표로 방향성 표현 (양방향 관계의 경우 화살표 생략)

- 다중도(연관에 참여하는 객체의 개수)를 선위에 표기

연관관계 다중도

2. 집합(Aggregation) 관계

- 하나의 사물이 다른 사물에 포함되어 있는 관계

- 포함 하는 쪽과 포함되는 쪽은 서로 독립적

- 부분(포함되는 쪽)에서 전체(포함하는 쪽)으로 빈 마름모 연결

집합 관계

3. 포함(Composition) 관계

- 집합 관계의 특수한 형태로, 전체(포함하는 사물)의 변화가 부분(포함되는 사물)에게 영향을 미치는 관계

- 전체와 부분은 서로 독립될 수 없고 생명주기를 함께함

- 부분에서 전체로 속이 채워진 마름모를 연결

4. 일반화(Generalization) 관계

- 하나의 사물이 다른 사물에 비해 더 일반적인지 구체적인지를 표현

- 일반적인 개념을 상위(부모), 구체적인 개념을 하위(자식)라고 일컬음

- 하위 사물에서 상위 사물로 빈 화살표 연결

일반화 관계

5. 의존(Dependency)관계

- 서로 연관은 있으나 필요에 의해 서로에게 영향을 주는 짧은 시간 동안만 연관을 유지하는 관계

- 영향을 주는 사물이 영향을 받는 사물쪽으로 점선 화살표

6. 실체화(Realization) 관계

- 사물이 할 수 있거나 해야 하는 기능(행위, 인터페이스)으로 서로를 그룹화할 수 있는 관계를 표현

- 사물에서 기능 쪽으로 속이 빈 점선 화살표

실체화 관계

다이어그램(Diagram)

- 사물과 관계를 도형으로 표현한 것

- 시스템을 가시화한 뷰(View)를 제공함으로써 의사소통에 도움

- 주로 정적 모델링은 구조적 다이어그램, 동적 모델링은 행위 다이어그램을 사용

 

구조적(Structural) 다이어그램 종류

클래스 다이어그램	시스템을 구성하는 클래스들 사이의 관계 및 속성을 표현
객체 다이어그램	시스템 실행 중 어느 순간의 객체와 관계를 포착해서 보여줌
컴포넌트 다이어그램	컴포넌트 간의 관계나 인터페이스를 표현
배치 다이어그램	시스템의 물리적 요소(결과물, 프로세스, 컴포넌트) 구조 표현
복합체 구조 다이어그램	복합 구조의 클래스나 컴포넌트 내부 구조를 표현
패키지 다이어그램	모델 요소(유스케이스, 클래스등)들을 그룹화한 패키지들과 그들의 관계를 표현

행위(Behavioral) 다이어그램 종류

유스케이스 다이어그램	사용자 관점에서 시스템행위를 표현
시퀀스 다이어그램	시스템이나 객체 사이의 상호 작용 표현
커뮤니케이션(통신) 다이어그램	상호작용 + 객체들간의 연관까지 표현
상태 다이어그램	객체의 상태 변화를 표현
활동 다이어그램	어떤 기능을 수행하는지 객체의 처리 로직이나 조건에 따른 처리의 흐름을 순서에 따라 표현
상호작용 개요 다이어그램	상호작용 다이어그램간의 제어 흐름을 표현
타이밍 다이어그램	개게 상태 변화와 시간 제약을 명시적으로 표현