2장 요구사항 확인

누런강냉이 2021. 6. 26. 19:16

2021. 6. 26. 19:16

요구사항 정의

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

소프트웨어 개발이나 유지 보수 과정에서 필요한 기준과 근거 제공
개발하려는 소프트웨어 전반적 내용을 확인할 수 있게 하여 개발에 참여하는 이해관계자들 간 의사소통을 원활히 하는데 도움을 줌.
요구사항이 제대로 정의되어야 과정의 목표와 계획 수립 가능

기능 요구사항

시스템이 무엇을 하는지, 어떤 기능을 하는지
시스템의 입력이나 출력으로 무엇이 포함되어야 하고, 어떤 데이터를 저장하거나 연산을 수행해야 하는지
시스템이 반드시 수행해야 하는 기능
사용자가 시스템을 통해 제공받길 원하는 기능

비기능 요구사항

시스템 장비 구성 요구사항
성능 요구사항
인터페이스 요구사항
데이터 요구사항
테스트 요구사항
보안 여구사항
품질 요구사항
제약사항
프로젝트 관리 요구사항
프로젝트 지원 요구사항

사용자 요구사항

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

시스템 요구사항 (소프트웨어 요구사항)

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

요구사항 개발 프로세스

도출(Elicitation)
- 요구사항이 어딨고, 어떻게 수집할 것인지 식별하고 이해하는 과정
- 인터뷰, 설문, 브레인스토밍, 워크샵, 프로토타이핑, 유스케이스
분석(Analysis)
- 요구사항 중 명확하지 않거나 이해되지 않는 부분을 발견하고 이를 걸러내기 위한 과정
- 기법
  - 요구사항 분류 (Requirements Classification)
  - 개념 모델링 (Conceptual Modeling)
    - 요구사항을 개념적으로 표현한 것을 모델, 이러한 모델을 만드는 과정이 모델링.
    - 유스케이스 다이어그램, 데이터흐름 모델, 상태 모델, 목표 기반 모델, 사용자 인터랙션, 객체 모델, 데이터 모델 등..
    - 표기는 주로 UML(Unifield Modeling Language 통합 모델링 언어) 사용
  - 요구사항 할당 (Allocation)
    - 요구사항을 만족시키기 위한 구성 요소를 식별하는 것
  - 요구사항 협상 (Negotiation)
    - 요구사항이 서로 충돌될 경우 적절히 해결하는 과정
    - 우선순위를 부여하면 도움
  - 정형 분석 (Formal Analysis)
    - 구문(Syntax)과 의미(Semantics)를 갖는 정형화된 언어를 이용해 요구사항을 수학적 기호로 표현한 후 이를 분석하는 과정.
    - 분석 단계 중 마지막 단계에서 이뤄짐.
명세(Specification)
- 요구사항을 체계적으로 분석 후 승인될 수 있도록 문서화하는 것
확인(Validation)
- 요구사항 명세서가 정확하고 완전히 작성됐는지 검토하는 활동
- 기법
  - 요구사항 검토(Reviews)
    - 문서화된 요구사항을 훑어보며 확인하는 것
  - 프로토타이핑(Prototyping)
    - 초기 도출된 요구사항을 토대로 프로토타입(Prototype)을 만든 후 대상 시스템 개발이 진행되는 동안 도출되는 요구사항을 반영하며 지속적으로 프로토타입을 재작성하는 것.
    - 장점
      - 빠르게 제작 가능. 반복된 제작을 통해 발전된 결과물 도출 가능
      - 최종 시스템 완성 전 추가/변경 요구사항이나 아이디어 등에 대한 피드백 가능
      - 이해하기 쉬워 사용자/개발자 혹은 개발자/개발자 사이의 원활한 의사소통 가능
      - 개발될 시스템 사용에 대한 문제점을 시스템 완성 전 식별 가능
      - 프로토타입이 개선될수록 변동 가능한 요구사항들 감소
    - 단점
      - 사용자의 관심이 핵심에서 벗어나 프로토타입에 집중될 수 있음
      - 개발 대상의 일부만을 대상으로 프로토타입이 제작된 경우, 대상 범위를 잘못 이해해 사용성이 과대평가될 수 있음
      - 지속적이고 반복적인 프로토타입의 개선으로 인한 비용 부담
  - 모델 검증(Model Verification)
    - 요구사항 분석 단계에서 개발된 모델이 요구사항을 충족시키는지 검증하는 것.
    - 분석 도구를 사용해 확인하는 정적 분석을 수행하는 것이 유용
  - 인수 테스트(Acceptance Tests)
    - 사용자가 실제로 사용될 환경에서 요구사항들이 모두 충족되는지 사용자 입장에서 확인하는 과정
    - 사용자 인수 테스트, 운영상 인수 테스트, 계약 인수 테스트, 규정 인수 테스트, 알파 검사, 베타 검사

UML

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

사물

모델을 구성하는 가장 중요한 기본 요소.

구조 사물(Structural Things)
- 시스템의 개념적, 물리적 요소 표현
- 클래스, 유스케이스, 컴포넌트, 노드 등
행동 사물(Behavioral Things)
- 시간과 공간에 따른 요소들의 행위 표현
- 상호작용, 상태 머신 등
그룹 사물
- 요소들을 그룹으로 묶어 표현
- 패키지
주해 사물 (Annotation Things)
- 부가적 설명이나 제약조건 표현
- 노트

관계

다중도

1 : 1개의 객체가 연관
n : n개의 객체가 연관
0..1 : 연관된 객체가 없거나 1개
0..* 또는 * : 연관된 객체가 없거나 다수
1..* : 연관된 객체가 적어도 1개 이상
n..* : 연관된 객체가 적어도 n개 이상
n..m : 연관된 객체가 최소 n개에서 최대 m개이다.

연관(Association) 관계

2개 이상의 사물이 서로 관련되어 있음을 표현

ex)

1 1

사람────>집

사람이 집 소유. 사람은 자기가 소유하는 집을 알지만 집은 누구에 의해 자신이 소유되는지 모름

사람 쪽에 표기된 다중도가 1이므로 집은 한 사람에 의해서만 소유될 수 있음

집 쪽에 표기된 다중도가 1이므로 사람은 집을 한 채만 소유할 수 있음

ex2)

1..* 1..*

선생님────학생

선생님과 학생은 서로 관계가 있음. (누구의 소유 관계 x)

선생님은 적어도 한 명 이상의 학생으로부터 관계가 있다.(가르친다.)

학생은 적어도 한 명 이상의 선생님으로부터 관계가 있다.(배운다.)

집합(Aggregation) 관계

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

ex)

컴퓨터◇────프린터

프린터는 컴퓨터에 연결해 사용할 수 있으며, 다른 컴퓨터에 연결해서 사용할 수도 있다.

포함(Compostion) 관계

집합 관계의 특수한 형태. 포함하는 사물의 변화가 포함되는 사물에게 영향을 미치는 관계

ex)

문◆────열쇠

문을 열 수 있는 키는 하나이다. 해당 키로 다른 문은 열 수 없으며, 문이 없어지면 키도 더 이상 필요하지 않다.

일반화(Generalization) 관계

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

ex)

동물

◁ ▷

/ ＼ (실선으로 표현)

사자 호랑이

동물에는 사자와 호랑이가 있다.

의존(Dependency) 관계

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

ex)

등급--------->할인율 (점선으로 표현)

등급이 높으면 할인율을 적용, 낮으면 적용하지 않는다.

실체화(Realization) 관계

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

ex)

날 수 있는

◁ ▷

/ ＼ (점선으로 표현)

/ ＼

비행기 새

다이어그램(Diagram)

사물의 관계를 도형으로 표현.

정적 모델링

사용자가 요구한 기능을 구현하는데 필요한 자료들의 논리적 구조를 표현한 것.
구조적 다이어그램을 사용하여 표현
- 클래스 다이어그램
  - 클래스와 클래스가 갖는 속성, 클래스 사이 관계 표현
  - 시스템 구조 파악, 구조상 문제점 도출 가능
  - UML을 이용한 대표적 정적 모델링
  - 클래스 다이어그램
  - 구성 요소
    - 클래스
      - 클래스 이름, 속성, 오퍼레이션 3개 구획으로 표현. 그 중 속성과 오퍼레이션은 생략 가능
      - 속성 : 클래스의 상태나 정보 표현
        
        일반 형식 : [접근 제어자] 속성명 : 자료형 [다중성(배열)][=초기값] (대괄호내 값은 생략 가능)
        
        접근 제어자
        
        public : +
        
        private : -
        
        protected : #
        
        package ~
      - 오퍼레이션 : 클래스가 수행할 수 있는 동작. 함수라고도 한다.
        
        일반 형식 : [접근제어자] 오퍼레이션명(매개변수1 : 자료형1, 매개변수 2 : 자료형 2, ...) : 반환자료형
    - 제약조건 : 속성에 입력될 값에 대한 제약조건이나 오퍼레이션 수행 전후 지정해야 할 조건
    - 관계 : 클래스와 클래스 사이 연관성 표현 (UML에서 학습한 관계와 같다.)
- 객체 다이어그램
  - 클래스에 속한 객체들, 즉 인스턴스(Instance)를 특정 시점의 객체와 객체 사이 고나계로 표현
- 컴포넌트 다이어그램
  - 컴포넌트 간의 관계나 컴포넌트 간 인터페이스 표현. 구현 단계에서 사용
- 배치 다이어그램(Deployment)
  - 물리적 요소들의 위치 표현. 구현 단계에서 사용
- 복합체 구조 다이어그램(Compositive Structure)
  - 클래스나 컴포넌트가 복합 구조를 갖는 경우 그 내부 구조를 표현
- 패키지 다이어그램
  - 유스케이스나 클래스 등 모델 요소들을 그룹화한 패키지들의 관계 표현

동적 모델링

시스템의 내부 구성요소들의 상태가 시간의 흐름에 따라 변화하는 과정과 변화하는 과정에서 발생하는 상호 작용을 표현한 것
행위 다이어그램을 사용하여 표현
- 유스케이스 다이어그램
  - 사용자의 요구를 분석하는 것. 기능 모델링(사용자 요구사항을 분석해 개발될 시스템이 갖춰야 할 기능을 정리 후 사용자와 정리된 내용을 공유하기 위해 표현하는 것) 작업에 사용
  - User와 Use Case로 구성되며 Use Case간 여러 형태의 관계로 이뤄짐
  - 유스케이스 다이어그램
  - 구성 요소
    - 시스템 범위 : 시스템 내부에서 수행되는 기능들을 외부 시스템과 구분하기 위한 범위
    - 액터
      - 시스템과 상호작용을 하는 모든 외부 요소.
      - 주액터
        
        시스템을 사용함으로써 이득을 얻는 대상
      - 부액터
        
        주액터의 목적 달성을 위해 시스템에 서비스를 제공하는 외부 시스템
    - 유스케이스
      - 사용자가 보는 관점에서 시스템이 액터에게 제공하는 서비스 또는 기능
      - 더 이상 분할되지 않는 기능의 단위
      - 액터에 의해 수행되며, 액터가 관찰할 수 있는 결과 산출
      - 유스케이스 명세서
        
        유스케이스 안에서 액터와 시스템 간 상호 작용 과정을 글로 자세히 표현한 것.
        
        각 유스케이스 명세서에 작성된 사건 흐름을 참고해 활동 다이어그램 작성
    - 관계
      - 액터 - 유스케이스, 유스케이스 - 유스케이스간 나타날 수 있다.
      - 포함 관계
        
        두 개 이상의 유스케이스에 공통적으로 적용되는 기능을 별도로 분리해 새로운 유스케이스로 만든 경우, 원래의 유스케이스와 새롭게 분리된 유스케이스와의 관계
      - 확장 관계
        
        유스케이스가 특정 조건에 부합돼 유스케이스의 기능이 확장될 때 원래의 유스케이스와 확장된 유스케이스간의 관계
      - 일반화 관계
        
        유사한 액터나 유스케이스를 하나의 그룹으로 묶고 싶을 때 그보다 일반적인 액터나 유스케이스를 만ㄷ르어 이들을 연결하여 표현하는 관계
- 시퀀스 다이어그램
  - 시스템이나 객체들이 주고받는 메시지 표현
  - 시퀀스 다이어그램
  - 구성 요소
    - 액터 : 시스템으로부터 서비스를 요청하는 외부 요소
    - 객체 : 메시지를 주고받는 주체
    - 라이프라인 : 객체가 메모리에 존재한느 기간
    - 활성 상자 : 객체가 메시지를 주고받으며 구동되고 있음을 표현
    - 메시지
      - 객체가 상호 작용을 위해 주고받는 메시지.
      - 종류
        
        의미 : 동기
        기능 : 메시지를 보낸 후 결과가 반환될 때까지 기다린다.
        
        의미 : 비동기
        기능 : 메시지를 보낸 후 결과가 반환될 때까지 기다리지 않고 다른 작업을 수행함.
        
        의미 : 생성
        기능 : 메시지를 받는 새로운 객체 생성
        
        의미 : 응답
        기능 : 동기 메시지에 대한 수행 결과
    - 객체 소멸 : 해당 객체가 더 이상 메모리에 존재하지 않음을 의미
    - 프레임 : 다이어그램 전체 또는 일부를 묶어 표현
- 커뮤니케이션 다이어그램
  - 객체들이 주고받는 메시지뿐만 아니라 객체들 간 연관까지 표현\
  - 커뮤니케이션 다이어그램
  - 액터 : 시스템으로부터 서비스를 요청하는 외부 요소
  - 객체 : 메시지를 주고받는 주체
  - 링크 : 객체들 간의 관계를 표현하는 데 사용
  - 메시지 : 객체가 상호 작용을 위해 주고받는 메시지. 시퀀스 다이어그램에서와 동일하다.
- 상태 다이어그램
  - 하나의 객체가 자신이 속한 클래스의 상태 변화 혹은 상호 작용에 따라 상태가 어떻게 변화하는지 표현
  - 상태 다이어그램
  - 구성 요소
    - 상태 : 객체의 상태 표현
      - 시작 상태 : 상태 시작 표현
      - 종료 상태 : 상태 종료 표현
    - 상태 전환 : 상태 사이의 흐름.
    - 이벤트 : 상태에 변화를 주는 현상
    - 프레임 : 상태 다이어그램 범위 표현
- 활동 다이어그램
  - 어떤 기능을 수행하는지 객체 처리 로직이나 조건에 따른 처리 흐름을 순서에 따라 표현
  - 활동 다이어그램
  - 구성요소
    - 액션 / 액티비티 : 액션은 더 이상 분해될 수 없는 단일 작업, 액티비티는 몇 개의 액션으로 분리될 수 있는 작업.
    - 제어 흐름 : 실행의 흐름 표현
    - 노드
      - 시작 노드
        
        액션이나 액티비티가 시작됨을 의미
      - 종료 노드
        
        액티비티 안의 모든 흘므이 종료됨을 의미
      - 조건 노드
        
        조건에 따라 제어의 흐름이 분리됨을 표현
      - 병합 노드
        
        여러 경로의 흐름이 하나로 합쳐짐을 표현
        
        ※ 조건 노드와 병합 노드 둘 다 마름모로 표현. 들어오는 제어 흐름이 하나면 조건, 여러 개면 병합.
      - 포크 노드
        
        액티비티의 흐름이 분리되어 수행됨을 표현
      - 조인 노드
        
        액티비티의 흐름이 다시 합쳐짐을 표현
        
        ※ 포크 노드와 조인 노드 둘 다 굵은 선으로 표현. 들어오는 액티비티 흐름이 하나면 포크, 여러 개면 조인
    - 스윔레인 : 액티비티 수행 담당 주체 구분
- 상호작용 개요 다이어그램(Interaction Overview)
  - 상호작용 다이어그램 간 제어 흐름 표현
- 타이밍 다이어그램
  - 객체 상태 변화와 시간 제약을 명시적으로 표현

'그 외 공부 > 정처기-실기(완)' 카테고리의 다른 글

6장 화면 설계 (0)	2021.07.02
5장 서버 프로그램 구현 (0)	2021.06.29
4장 통합 구현 (0)	2021.06.27
3장 데이터 입*출력 구현 (0)	2021.06.27
1장 프로그래밍 언어 활용 (0)	2021.06.14

누런강냉이