1과목-소프트웨어 설계-요구사항 확인3

*요구사항 정의*

 

1.요구사항의 개념 및 특징

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

-소프트웨어 개발이나 유지 보수 과정에서 필요한 기준과 근거를 제공

-이해관계자들 간의 의사소통을 원활하게 하는 데 도움을 준다

 

2.요구사항의 유형

-일반적으로 기술하는 내용에 따라 기능 요구사항, 비기능 요구사항으로 구분하며 기술 관점과 대상의 범위에 따라 시스템 요구사항과 사용자 요구사항으로 나눈다.

-기능 요구사항 : ex)사용자는 회원id와 비밀번호를 입력하여 로그인할 수 있다. 와 같이 말 그대로 기능에 관한 요구사항

-비기능 요구사항 : ex)시스템은 1년365일 하루 24시간 운용이 가능해야한다 와 같이 대부분 품질이나 제약사항과 관련

 

3.요구사항 개발 프로세스

 

*도출 

-개발에 관련된 사람들이 서로 의견을 교환하여 요구사항이 어디에 있는지 어떻게 수집할 것인지를 식별하고 이해

-주요 기법 : 인터뷰,설문,브레인스토밍,워크샵,프로토타이핑,유스케이스

-브레인 스토밍 : 3인 이상이 자유롭게 의견을 교환하면서 독창적인 아이디어를 산출해 내는 방법

-프로토타이핑 : 견본품을 통해 효과적으로 요구 분석을 수행하면서 명세서를 산출하는 작업

-유스케이스 : 사용자의 요구사항을 기능 단위로 표현하는 것

 

*분석

-요구사항 분석은 개발 대상에 대한 사용자의 요구사항 중 명확하지 않거나 모호하여 이해되지 않는 부분을 발견하고 이를 걸러내기 위한 과정

 

*명세

-요구사항을 체계적으로 분석한 후 승인될 수 있도록 문서화하는 것을 위미한다.

 

*확인

-개발 자원을 요구사항에 할당하기 전에 요구사랑 명세서가 정확하고 완전하게 작성되었는지를 검토하는 활동

 

 

*요구사항 분석 기법*

 

1.요구사항 분류

-요구사랑을 명확히 확인할 수 있도록 다음과 같은 기준으로 분류한다.

-기능 비기능 요구사항으로 분류한다.

-제품에 관한 것인지 프로세스에 관한 것인지 분류한다.

-우선순위에 따라 분류한다.

-소프트웨어에 미치는 영향의 범위에 따라 분류한다.

 

2.개념 모델링

-요구사항을 보다 쉽게 이해할 수 있도록 현실 세계의 상황을 단순화하여 개념적으로 표현한 것을 모델이라고 함

-모델을 만드는 과정을 모델링이라고 한다.

-개념 모델은 개체들과 그들 간의 관계 및 종속성을 반영한다.

-요구사항 분석의 핵심이다.

-이해관계자별로 관점이 다양하니 개념 모델도 다양하게 표현한다.

-종류 : 유스케이스 다이어그램, DFD, 상태 모델, 목표기반 모델, 객체 모델 등이 있다.

-모델링 표기는 UML을 사용

 

3.요구사항 할당

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

-구성 요소들 간에 어떻게 작용하는지 분석하는 과정에서 추가 요구사항이 발견될 수 있다.

 

4.요구사항 협상

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

-충돌되는 경우 어느 한 쪽으로 맞추기 보다는 적절한 기준점을 찾아 합의해야 한다.

-우선순위를 부여하면 문제 해결에 도움

 

5.정형 분석

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

-요구사항 분석의 마지막 단계

 

*요구사항 확인 기법*

 

1.요구사항 검토

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

-가장 일반적인 요구사항 검증 방법

 

2.프로토타이핑

-초기 도출된 요구사항을 토대로 프로토타입을 만든 후 대상 시스템의 개발이 진행되는 동안 도출되는 요구사항을 반영하면서 지속적으로 프로토타입을 재작성하는 과정.

-수행하면서 새로운 요구사항이 도출될 수 있다.

-단점 : 프로토타입 제작에만 집중될 수 있다. 사용성이 과대평가. 프로토타입의 개선으로 인한 비용이 부담될 수 있다.

 

4.모델 검증

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

 

5.인수 테스트

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

-각각의 요구사항을 어떻게 확인할 것인지에 대한 계획을 세워야 한다.

 

*UML*

 

1.UML의 개요

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

-구성 요소 사물 관계 다이어그램 등이 있다.

 

2.사물

-모델을 구성하는 가장 중요한 기본요소로, 다이어그램 안에서 관계가 형성될 수 있는 대상들을 말한다.

-구조 사물 : 시스템의 개념적 물리적 요소를 표현(클래스, 유스케이스 , 컴포넌트, 노드)

-행동 사물 : 시간과 공간에 따른 요소들의 행위를 표현(상호작용, 상태 머신)

-그룹 사물 : 요소들을 그룹으로 묶어서 표현(패키지)

-주해 사물 : 부가적인 설명이나 제약조건 등을 표현

 

3.관계 

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

-연관, 집합, 포함, 일반화, 의존, 실체화 관계 등이 있다.

 

4.다이어그램

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

-여러 관점에서 시스템을 가시화한 뷰를 제공함으로써 의사소통에 도움준다.

 

구조적 다이어그램의 종류

-클래스 다이어그램 : 클래스와 클래스가 가지는 속성, 클래스 사이의 관계를 표현한다.

-객체 다이어그램 : 클래스에 속한 사물들 즉 인스턴스를 특정 시점의 객체와 객체 사이의 관계로 표현한다.

-컴포넌트 다이어그램 : 실제 구현 모듈인 컴포넌트 간의 관계나 컴포넌트 간의 인터페이스를 표현한다.

-배치 다이어그램 : 물리적 요서들의 위치를 표현한다.

-복합체 구조 다이어그램 : 클래스나 컴포넌트가 복합 구조를 갖는 경우 그 내부 구조를 표현한다

-패키지 다이어그램 : 유스케이스나 클래스 등의 모델 요소들을 그룹화한 패키지들의 관계를 표현한다.

 

행위 다이어그램의 종류

-유스케이스 다이어그램 : 사용자의 요구를 분석하는 것으로 기능 모델링 작업에 사용한다.

-시퀀스 다이어그램 : 상호 작용하는 객체들이 주고받는 메시지를 표현한다.

-커뮤니케이션 다이어그램 : 동작에 참여하는 객체들이 주고받는 메시지와 객체들 간의 연관까지 표현

-상태 다이어그램 : 하나의 객체가 자신이 속한 클래스의 상태 변화 혹은 다른 객체와의 상화 작용에 따라 상태가 어떻게 변화하는지를 표현

-활동 다이어그램 : 시스템이 어떤 기능을 수행하는지 객체의 처리 로직이나 조건에 따른 처리의 흐름을 순서에 따라 표현한다.

-상화작용 개요 다이어그램 : 상호작용 다이어그램 간의 제어 흐름을 표현한다.

-타이밍 다이어그램 : 객체 상태 변화와 시간 제약을 명시적으로 표현한다.