요구사항 정의
소프트웨어가 어떤 문제를 해결하기 위해 제공하는 서비스에 대한 설명과 정상적으로 운영되는 데 필요한 제약조건 등을 나타냄
- 소프트웨어 개발이나 유지 보수 과정에서 필요한 기준과 근거를 제공함
- 요구사항은 개발하려는 소프트웨어의 전반적인 내용을 확인할 수 있게 하며, 개발에 참여하는 관계자들의 의사소통을 원활하게 함
- 요구사항이 제대로 정의되어야, 이후 과정의 목표와 계획을 수립할 수 있음
요구사항의 유형
일반적으로 기술하는 내용에 따라 기능 요구사항과 비기능 요구사항으로 구분하며, 기술관점과 대상의 범위에 따라 시스템 요구사항과 사용자 요구사항으로 나뉨
- 기능 요구사항(Functional requirements) : 시스템이 무엇을 하는지, 어떤 기능을 하는 지에 대한 사항, 사용자가 시스템을 통해 제공받기를 원하는 기능
- 비기능 요구사항 (Non-functional requirements) : 시스템 장비 구성, 인터페이스, 데이터, 테스트, 보안, 품질 요구사항, 제약사항, 프로젝트 관리, 프로젝트 지원등이 있음 (*기능적인 내용이 아닌 하드웨어, 인터페이스등과 관련 되는 내용은 비기능 요구사항임!)
- 사용자 요구사항 (User requirements) : 사용자 관점에서 본 시스템이 제공해야할 요구사항, 친숙한 표현으로 이해하기 쉽게 작성됨
- 시스템 요구사항 (System requirements) : 개발자 관점에서 본 시스템 전체가 사용자와 다른 시스템에 제공해야할 요구사항. 보다 전문적이고 기술적인 용어로 표현. 소프트웨어 요구사항이라고도 함
요구사항 개발 프로세스
개발 대상에 대한 요구사항을 체계적으로 도출하고 이를 분석한 후 분석 결과를 명세서(Specification Document)에 정리한 다음 마지막으로 이를 확인 및 검증하는 일련의 구조화된 활동. 요구사항 개발 프로세스가 진행되 전에 개발 프로세스가 비즈니스 목적에 부합되는 지, 예산은 적정한 지 등 정보를 수집, 평가한 보고서를 토대로 타당성 조사가 선행되어야함.
요구사항 도출(Requirement Elicitation, 요구사항 수집)
- 시스템, 사용자, 시스템 개발에 관련된 서로 의견 교환하여 요구사항 파악 및 어떻게 수집할 지를 식별하고 이해하는 과정
- 요구사항 도출은 소프트웨어가 해결해야 할 문제를 이해하는 첫 번째 단계
- 도출 단계에서 개발자와 고객 사이의 관계가 만들어지고 이해관계자(Stakeholder)가 식별됨
- 다양한 이해관계자 간의 효율적인 의사 소통이 중요
- 요구사항 도출은 소프트웨어 개발 생명 주기(SDLC: software development life cycle) 동안 지속적으로 반복됨
- 주요기법 : 인터뷰, 설문, 브레인스토밍, 워크샵, 프로토타이핑, 유스케이스 등이 있음
요구사항 분석(Requirement Analysis)
- 요구사항 분석은 개발 대상에 대한 사용자의 요구사항 중 명확하지 않거나 모호하여 이해되지 않는 부분을 발견하고 이를 걸러내기 위한 과정
- 사용자 요구사항의 타당성을 조사하고 비용과 일정에 대한 제약을 설정함
- 내용이 중복되거나 서로 상충되는 요구사항이 있으면 이를 해결함
- 도출된 요구사항들을 토대로 소프트웨어 범위 파악 및 주변환경이 상호작용하는 방법을 이해함
요구사항 명세(Requirement Specification)
- 요구사항 명세는 요구사항을 체계적으로 분석한 후 승인될 수 있도록 문서화하는 것을 의미
- 요구사항을 문서화할 때는 기능 요구사항은 빠짐없이 완전하고 명확하게 기술해야하며, 비기능 요구사항은 필요한 것만 명확하게 기술해야함
- 사용자가 이해하기 쉽고, 개발자가 효과적으로 설계할 수 있도록 작성되어야함
- 설계 과정에서 잘못된 부분이 있을 경우, 그 내용이 요구사항 정의서에서 추적할 수 있어야함
요구사항 확인(Requirement Validation, 요구사항 검증)
- 개발 자원을 요구사항에 할당하기 전에 요구사항 명세서가 정확하고 안전하게 작성되어있는 지를 검토
- 분석가가 요구사항을 정확하게 이해한 후 요구사항 명세서를 작성했는 지 확인하는 것이 필요
- 요구사항 명세서 내용이 이해하기 쉬운 지, 일관성은 있는 지, 회사의 기준에 맞는지, 누락된 기능 없는 지 검증이 중요
- 이해관계자들이 검토해야함
- 일반적으로 요구사항 관리 도구를 이용하여 요구사항 정의 문서들에 대한 형상관리를 수행
요구사항 분석 기법
요구사항 분석 기법은 개발 대상에 대한 사용자의 요구사항 중 명확하지 않거나 모호한 부분을 걸러내기 위한 방법이며, 종류는 아래와 같다.
1) 요구사항 분류 (Requirement Classification)
- 기능 요구사항, 비기능 요구사항으로 분류
- 하나 이상의 상위 요구사항에서 유도된 것인지 또는 이해관계자나 다른 원천(source)으로 직접 발생한 것인지 분류
- 개발 제품 및 개발과정에 관한 것인지 분류
- 우선 순위에 따라 분류
- 소프트웨어에 미치는 영향 범위, 소프트웨어 생명 주기 동안 변경 가능성 여부에 따라 분류
2) 개념 모델링(Conceptual Modeling)
: 요구사항을 보다 쉽게 이해하도록 현실 상황을 단순화하여 개념적으로 표현하는 과정
- 모델은 문제가 발생하는 상황을 쉽게 이해시키고 해결책을 설명할 수 있으며 실세계 문제에 대한 모델링은 소프트웨어 요구사항 분석이ㅡ 핵심임
- 개념 모델은 문제의 주체인 개체(Entity)들과 그들 간의 관계 및 종속성을 반영
- 이해관계자별로 관점이 다양하므로 그에 맞게 개념모델도 다양하게 표현되어야함
- 종류 : 유스케이스 다이어그램(Use Case Diagram), 데이터 흐름 모델(Data Flow Model), 상태 모델(State Model), 목표기반 모델(Goal-based Model), 사용자 인터액션(User Interactions), 객체 모델(Object Model), 데이터 모델(Data Model) 등이 있음
- 모델링 표기 : 주로 UML 사용
3) 요구사항 할당 (Requirement Allocation)
: 요구사항을 만족시키기 위해 구성요소를 식별하는 것, 식별된 구성요소 들간에 어떻게 작용하는 지 분석하는 과정에서 추가적인 요구사항이 발결된 수 있음
4) 요구사항 협상(Requirement Negotiation)
- 요구사항이 서로 충돌될 경우 이를 적절히 해결하는 과정
- 두 명의 이해관계자가 요구하는 요구사항이 충돌되거나, 요구사항과 자원이 서로 충돌되거나, 기능 요구사항과 비기능 요구사항이 서로 충돌할 경우 어느 한 쪽으로 맞추기보다는 적절한 기준점을 찾아 합의해야함
- 각각 요구사항에 우선순위를 부여하면 무엇이 더 중요한 지 인식가능하기에 문제 해결에 도움됨
5) 정형 분석(Formal Analysis)
: 구문(Syntax)과 의미(Semantics)를 갖는 정형화된 언어를 이용해 요구사항을 수학적 기호로 표현한 후 이를 분석하는 과정. 요구사항 분석의 마지막 단계에서 이루어짐
요구사항 확인 기법
- 요구사항 개발 과정을 거쳐 문서화된 요구사항 관련 내용을 확인하고 검증하는 방법
- 요구사항에 자원이 배정되기 전에 문제 파악을 위한 검증을 수행해야함
- 종류 : 요구사항 검토(Requirement Reviews), 프로토타이핑(Prototyping), 모델 검증(Model Verification), 인수 테스트(Acceptance Tests)
요구사항 검토(Requirement Reviews)
- 요구사항 검토는 문서화된 요구사항을 훑어보면서 확인하는 것으로, 가장 일반적인 검증방법이다.
- 검토자들은 요구사항 검토를 통해 명확하지 않은 내용은 없는지, 가정이 잘못되지는 않았는지, 정해놓은 기준을 벗어나지는 않았는지 찾아낸다.
- 검토자 그룹을 구성할 때 구성방법이 중요하며, 고객중심 프로젝트이면 고객 대표자가 꼭 포함되어야함.
- 검토는 시스템 정의서, 시스템 사양서, 소프트웨어 요구사항 명세서등을 완성한 시점에 이루어진다.
프로토타이핑(Prototyping)
- 프로토타이핑은 초기 도출된 요구사항을 토대로 프로토 타입을 만든 후 대상 시스템의 개발이 진행되는 동안 도출되는 요구사항을 반영하면서 지속적으로 프로토타입을 재작성하는 과정임.
- 상품이나 서비스가 출시되기 전에 개발 대상 시스템 또는 일부분을 개략적으로 만든 원형을 프로토타입이라고 함
- 프로토타이핑을 하면서 새로운 요구사항이 도출될 수 있음
- 소프트웨어 요구사항에 대한 소프트웨어 엔지니어의 해석이 맞는 지 확인하기 위한 수단으로 주로 사용됨.
| 장점 | 단점 |
| - 빠르게 제작 가능. 반복되는 제작을 통해 발전된 결과물 얻을 수 있음 - 최종 시스템 완성하기 전에 추가 변경이나 요구사항 같은 피드백을 할 수 있음. - 이해하기 쉬워 사용자와 개발자, 개발자와 개발자끼리 의사소통이 원활해짐 - 개발될 시스템의 사용에 대한 문제점을 시스템 완성 전에 식별할 수 있음 -개선될 수록 요구사항 감소 가능 |
-핵심에서 벗어나 프로토타입 제작에만 집중될 수 있음 -전체 개발 대상이 아닌 일부만 프로토타입으로 제작할 경우, 대상 범위를 잘못 이해하여 사용성이 과대평가될 수 있음 -지속적이고 반복적인 프로토타입의 개선으로 인해 비용 부담이 증가할 수 있음 |
모델 검증(Model Verification)
- 모델 검증은 요구사항 분석 단계에서 개발된 모델이 요구사항을 충족시키는지 검증하는 것
- 객체 모델의 경우 객체들 사이에 존재하는 의사소통 경로(Communication Path)를 검증하기 위하여 정적분석(Static Analtsis)을 수행하는 것이 유용하다.
- 정적분석이란? 직접 실행을 통해서 확인하지 않고 명세서의 정확성이나 일관성들을 확인하거나 분석도구를 사용해 확인하는 방법. 반대로 직접 실행해서 확인하는 건 동적 분석임.
인수 테스트(Acceptance Tests)
- 인수테스트는 사용자가 실제로 사용될 환경에서 요구사항이 모두 충족되는 지 사용자 입장에서 확인하는 과정
- 종류 : 사용자 인수테스트, 운영상의 인수 테스트, 계약 인수테스트, 규정 인수 테스트, 알파 검사, 베타 검사가 있다. (인수테스트 관해서는 시험에 자주 나오니까 이해해두기!!)
****UML(Unified Modeling Language)
시험에 한 문제는 꼭 나올 가능성이 있음! 이해하고 외우기!
1) UML의 개요
- 시스템 분석, 설계, 구현 등 시스템 개발 과정에서 시스템 개발 과정에서 시스템 개발자와 고객 또는 개발자 상호간의 의사소통이 원활하게 이루어지도록 표준화한 대표적인 객체지향 모델링 언어.
- UML을 이용하여 시스템의 구조를 표현하는 6개의 구조 다이어그램과 시스템의 동작을 표현하는 7개의 행위 다이어그램을 작성할 수 있음
- 각각의 다이어그램은 사물과 사물 간의 관계를 용도에 맞게 표현함.
- 구성요소 : 사물, 관계, 다이어그램 등이 있음.
2) 사물(Things)
: 모델을 구성하는 가장 중요한 기본 요소, 다이어그램 안에서 관계가 형성될 수 있는 대상을 말함.
| 사물 | 내용 |
| 구조 사물 (Structual Things) |
-물리적 요소 표현 -class, Use case, Component, Node |
| 행동 사물 (Behavioral Things) |
-시간과 공간에 따른 요소들의 행위 표현 -상호작용, 상태 머신등 |
| 그룹 사물 (Grouping Things) |
-요소들을 그룹으로 묶어서 표현 -Package |
| 주해 사물 (Annotation Things) |
-부가적인 설명, 제약조건 -Note |
3) 관계(Relationships)
: 사물과 사물 사이의 연관성을 표현. 연관 관계, 집합 관계, 포함 관계, 일반화 관계, 의존 관계, 실체화 관계 등이 있음.
연관(Association)관계
: 2개 이상의 사물이 서로 관련되어 있음을 표현
- 사물 사이를 실선으로 연결, 방향성은 화살표로 표현
- 양방향 관계인 경우 화살표 생략하고 실선으로만 표현
- 연관에 참여하는 객체의 개수를 의미하는 다중도를 선 위에 표기함
집합(Aggregation) 관계
: 하나의 사물이 다른 사물에 포함되어 있는 관계를 표현
- 포함하는 쪽과 포함되는 쪽은 서로 독립적
- 포함되는 쪽에서 포함하는 쪽으로 속이 빈 마름모를 연결하여 표현
포함(Composition)관계
: 집합관계의 특수한 형태, 포함하는 사물의 변화가 포함되는 사물에게 영향을 미치는 관계를 표현
- 포함하는 쪽과 포함되는 쪽이 독립적이지 않고 생명주기를 함께함
- 포함되는 쪽에서 포함하는 쪽으로 속이 채워진 마름모를 연결하여 표현
일반화(Generalization) 관계
: 하나의 사물이 다른 사물에 비해 더 일반적인지 구체적인지를 표현함
- 사람은 여자와 남자보다 더 일반적인 개념
- 일반적인 개념을 상위(부모), 구체적인 개념을 하위(자식)이라고 부름
- 구체적인 사물(하위)에서 일반적인 (상위) 사물쪽으로 속이 빈 화살표로 연결
의존(Dependency)관계
: 서로 연관은 있으나 필요에 의해 서로에게 영향을 주는 짧은 시간 동안만 연관을 유지하는 관계를 표현
- 소유하는 관계는 아니지만 사물의 변화가 다른 사물에도 영향을 미치는 관계
- 영향을 주는 사물이 영향을 받는 사물 쪽으로 점선 화살표로 연결하여 표현
실체화(Realization) 관계
: 사물이 할 수 있거나 해야하는 기능(행위, 인터페이스)으로 서로를 그룹화 할 수 있는 관계를 표현
- 사물에서 기능쪽으로 속인 빈 점선 화살표로 연결하여 표현
다이어그램(Diagram)
- 사물과 관계를 도형으로 표현
- 여러 관점에서 가시화한 뷰(view)를 제공하여 의사소통에 도움을 줌
- 정적모델링에서는 구조적 다이어그램 사용하고, 동적 모델링에서는 주로 행위 다이어그램을 사용
*구조적(Structural) 다이어그램의 종류
| 클래스 다이어그램 (class diagram) |
- 클래스와 클래스가 가지는 속성, 클래스 사이의 관계 표현 - 시스템 구조 파악 및 구조상 문제점 도출 가능 |
| 객체 다이어그램 (object diagram) |
-클래스에 속한 사물(객체)들, 즉 인스턴스를 특정 시점의 객체와 객체 사이의 관계로 표현 |
| 컴포넌트 다이어그램 (component diagram) |
-컴포넌트 간의 관계, 인터페이스를 표현 -구현단계에서 사용 |
| 배치 다이어그램 (Deployment diagram) |
- 결과물, 프로세스, 컴포넌트 등 물리적 요소들의 위치 표현 - 노드와 의사소통 경로로 표현 -구현 단계에서 사용 |
| 복합체 구조 다이어그램 (composite structure diagram) |
- 클래스나 컴포넌트가 복합구조를 갖는 경우 그 내부 구조를 표현 |
| 패키지 다이어그램 (package diagram) |
- 유스케이스나 클래스등의 모델 요소들을 그룹화한 패키들의 관계 표현 |
*행위(Behavioral) 다이어그램의 종류
| 유스케이스 다이어그램 (Use case diagram) |
- 사용자의 요구 분석, 기능 모델링 작업에 사용 - 사용자와 사례로 구성 |
| 시퀀스 다이어그램 (Sequence diagram) |
- 상호작용 하는 시스템, 객체들이 주고받는 메시를 표현 |
| 커뮤니케이션 다이어그램 (communication diagram) |
- 시퀀스다이어그램과 같이 동작에 참여하는 객체들이 주고받는 메시지 표현 및 연관까지 표현 |
| 상태 다이어그램 (state diagram) |
- 하나의 객체가 속한 클래스의 상태 변화 혹은 다른 객체와의 상호 작용에 따른 상태 변화 표현 |
| 활동 다이어그램 (activity diagram) |
- 시스템 기능 수행 및 객체 처리 로직, 조건에 따른 처리 흐름 순서 표현 |
| 상호작용 개요 다이어그램 (interaction overview diagram) |
- 상호작용 다이어그램 간의 제어 흐름을 표현 |
| 타이밍 다이어그램 (timing diagram) |
- 객체 상태 변화, 시간 제약을 명시적 표현 |
'정보처리기사 > 정보처리기사 1과목' 카테고리의 다른 글
| 정보처리기사 2020 필기 정리 [1] 소프트웨어 설계 2장 화면 설계 (1) (0) | 2020.07.10 |
|---|---|
| 정보처리기사 2020 필기 정리 [1] 소프트웨어 설계 1장 요구 사항 확인(1) (0) | 2020.07.03 |