요구사항 확인 (2) - (소프트웨어 설계) [정보처리기사 필기]

 

요구사항 정의

요구는 시스템에 대한 고객의 요청을 확정한 것. 이를 통해 문제를 해결하기 위한 조건, 제약사항을 정의

요구사항이 제대로 정의되어야 이후 과정의 목표와 계획 수립 가능.

(제약사항은 소프트웨어 시스템의 해결책을 제한한 것)

 

[요구사항 유형]

기능 요구사항

• 시스템이 외형적으로 나타내는 기능과 동작. (기능, 자료, 입출력, 사용자 등)

비기능 요구사항

• 시스템이 제공하는 기능에 직접 관련되지 않은 요구 (성능, 보안, 품질, 안전 등)

사용자 요구사항

• 사용자 관점에서 시스템이 제공해야 할 사항

시스템 요구사항

• 개발자의 관점에서 시스템 전체가 사용자, 다른 시스템에 제공해야 할 요구사항 ( = 소프트웨어 요구사항)

 

[요구사항 개발 프로세스]

[도출 -> 분석-> 명세 -> 확인]

요구사항 도출 (수집)

• 요구사항이 어디에 있고, 어떻게 수집할 것인지 식별, 이해하는 과정
• 개발자 - 고객의 관계 생성, 이해관계자 식별
• 인터뷰, 설문, 브레인스토밍, 프로토타이핑, 유스케이스 등으로 요구사항 도출

요구사항 분석

• 개발 대상에 대한 사용자의 요구사항 중 명확하지 않거나, 모호한 부분 발견하고 거르는 과정
• 사용자 요구사항의 타당성 조사, 비용과 일정에 대한 제약 생성 -> 소프트웨어 범위 파악

요구사항 명세

• 요구사항을 분석한 후 승인될 수 있도록 문서화
• 소프트웨어 요구사항 명세서 : 기능, 특징, 제약조건 등을 명시한 최종산출물

요구사항 확인

• 개발 자원을 할당하기 전에 명세서가 정확하게 작성되었는지 검토하는 과정
• 이해관계자들이 검토, 관리 도구를 사용하여 형상 관리 수행

 

요구사항 분석

 

요구사항 분류 : 요구사항을 명확하게 확인하도록 분류 (기능/비기능, 제품/과정, 우선순위..)

개념 모델링 : 현실 세계의 상호아을 단순화하여 개념적으로 표현 (모델링) -> 주로 UML 사용

요구사항 할당 : 요구사항을 만족시키기 위한 구성요소 식별

요구사항 협상 : 요구사항이 서로 충돌될 경우 적절히 해결 (기준점 찾기, 우선순위 부여)

정형 분석 : 구문과 의미를 가지는 정형화된 언어 사용. 요구사항응ㄹ 수학적 기호로 표현 후 분석

 

요구사항 확인

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

 

요구사항 검토 : 문서화된 요구사항을 확인. 시스템 정의서, 요구사항 명세서 등을 완성하고 실행

프로토타이핑 : 초기 도출된 요구사항을 토대로 프로토타입 생성. 이후 요구사항 도출에 따라 지속적으로 재작성.

장점 : 빠르게 제작 가능, 발전된 결과물, 최종 시스템 이전에 피드백, 문제점 식별 가능.

단점 : 사용자의 관심이 프로토타입 제작에만 집중, 과대평가, 비용

 

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

인수 테스트 : 사용자의 실행환경에서 요구사항이 모두 충족시키는지 확인

 

UML(Unified Modeling Language)

시스템 개발자와 고객, 개발자 상호 간의 의사소통을 위한 표준화된 객체지향 모델링 언어

국제 표준화기구 OMG에서 표준으로 지정.

 

<사물>

모델을 구성하는 기본적인 요소. 관계가 형성될 수 있는 대상

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

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

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

주해 사물 : 부가적인 설명이나 제약조건 등 (노트)

 

<관계>

사물과 사물 사이의 연관성(관계) 표현

연관 관계

2개 이상의 사물이 서로 관련되어 있음 (객체 간 연결, 참조)

실선과 화살표로 연결하여 표현, 양방향일 경우 화살표 없이 실선으로.

관계	의미
n	n개의 객체 연결
0..1	연관된 객체가 없거나, 1개
0..* /*	연관된 객체가 없거나, 다수
n..*	연관된 객체가 적어도 n개 이상
n..m	연관된 객체가 n~m개

 

집합 관계

하나의 사물이 다른 사물에 포함된 관계. 포함하는 쪽 (전체)에서 속이 하얀 마름모를 포함되는 쪽 (부분)으로

포함 관계

집합의 특수로, 전체의 변화가 부분에 영향을 미치는 관계. 색칠된 마름모 사용

의존 관계

사물 사이에 연관은 있으나, 필요에 의해 짧은 시간만 연관을 유지하는 관계.

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

일반화 관계

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

실체화 관계

사물이 할 수 있거나, 해야 하는 기능으로 서로를 그룹화 할 수 있는 관계

 

<다이어그램>

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

 

구조적 다이어그램

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

객체 다이어그램 : 인스턴스를 특정 시점의 객체와 사이 관계로 표현.

컴포넌트 다이어그램 : 구현 단계에서 사용, 컴포넌트 간의 관계, 인터페이스 표현

배치 다이어그램 : 구현 단계에서 사용. 물리적 요소들의 위치 표현

패키지 다이어그램 : 클래스들의 집합인 패키지들의 관계 표현.

 

행위 다이어그램

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

시퀀스 다이어그램 : 사옿 작용하는 시스템, 객체들이 주고받는 메시지 표현

커뮤니케이션 다이어그램 : 객체간 메시지 + 객체들 간의 연관 표현

상태 다이어그램 : 하나의 클래스의 상태가 어떻게 변화하는지 표현.

활동 다이어그램 : 처리 흐름을 순서에 따라 표현

상호작용 개요 다이어그램 : 상호작용 다이어그램 간 제어 흐름 표현

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