[정처기 실기] 2장 - 요구사항 확인

현행 시스템 파악

시스템 파악 절차

시스템 구성 / 기능 / 인터페이스 파악 --> 아키텍처. 소프트웨어 구성 파악 --> 하드웨어, 네트워크 구성 파악

 

개발 기술 환경 파악

• 운영체제: 컴퓨터 시스템의 자원들을 효율적으로 관리하며, 사용자가 컴퓨터를 편리하고 효율적으로 사용할 수 있도록 환경을 제공하는 소프트웨어. (Windows, UNIX, Linux, Mac OS...)
• DBMS: 사용자와 데이터베이스 사이에서 사용자의 요구에 따라 정보를 생성해주고, 데이터베이스를 관리해 주는 소프트웨어. (Oracle, MySQL, MongoDB, SQLite...)
• 웹 어플리케이션 서버 (WAS): 정적인 콘텐츠 처리를 하는 웹 서버와 달리 사용자의 요구에 따라 변하는 동적인 콘텐츠를 처리하기 위해 사용되는 미들웨어. (Tomcat, JEUS, WebLogic...)
• Open Source: 누구나 별다른 제한 없이 사용할 수 있도록 소스 코드를 공개한 것으로, 오픈 소스 라이선스를 만족하는 소프트웨어
  
  

요구사항 정의

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

• 기능 요구사항: 시스템이 무엇을 하는지, 어떤 기능을 하는지에 대한 사항
• 비기능 요구사항: 소프트웨어의 기능들에 대한 조건 또는 제약사항
• 사용자 요구사항: 사용자 관점에서 본 시스템이 제공해야 할 요구사항
• 시스템 요구사항: 개발자 관점에서 본 시스템 전체가 사용자와 다른 시스템에 제공해야 할 요구사항

 

요구사항 개발 프로세스: 도출 --> 분석 --> 명세 --> 확인

• 도출: 요구사항이 어디에 있는지, 어떻게 수집할 것인지를 식별하고 이해. SDLC 동안 지속적으로 반복. 인터뷰, 설문, 브레인스토밍, 워크샵, 프로토타이핑, 유스케이스.
• 분석: 요구사항 중 명확하지 않거나 모호하여 이해되지 않는 부분을 발견하고 이를 걸러내기 위한 과정
• 명세: 요구사항을 체계적으로 분석한 후 승인될 수 있도록 문서화하는 것을 의미
• 확인: 요구사항 명세서가 정확하고 완전하게 작성되었는지를 검토

 

요구사항 분석 기법

• 요구사항 분류
• 개념 모델링: 요구사항을 보다 쉽게 이해할 수 있도록 현실 세계의 상황을 단순화하여 개념적으로 표현한 모델을 만드는 과정. UML을 이용.
• 요구사항 할당: 요구사항을 만족시키기 위한 구성 요소들을 식별
• 요구사항 협상: 요구사항이 서로 충돌될 경우 이를 적절히 해결
• 정형 분석: 구문(Syntax)과 의미(Semantics)를 갖는 정형화된 언어를 이용해 요구사항을 수학적 기호로 표현한 후 이를 분석하는 과정. 요구사항 분석의 마지막 단계에서 이루어짐.

 

요구사항 확인 기법

• 요구사항 검토: 문서화된 요구사항을 훑어보면서 확인하는 것
• 프로토타이핑: 도출된 요구사항을 토대로 프로토타입을 만듦
• 모델 검증: 분석 단계에서 개발된 모델이 요구사항을 충족시키는지 검증
• 인수 테스트: 사용자가 실제 사용될 환경에서 사용자 입장에서 확인

 

UML

jooona.tistory.com/101?category=845669

[소프트웨어 설계] UML

 

유스케이스(Use Case) 다이어그램

유스케이스 다이어그램: 개발될 시스템과 관련된 외부 요소들, 즉 사용자와 다른 외부 시스템들이 개발될 시스템을 이용해 수행할 수 있는 기능을 사용자의 관점에서 표현한 것.

 

구성요소

• 시스템 / 시스템 범위: 시스템 내부에서 수행되는 기능들을 외부 시스템과 구분하기 위해 시스템 내부의 유스케이스들을 사각형으로 묶어 시스템의 범위를 표현
• 액터: 시스템과 상호작용을 하는 모든 외부 요소. 액터의 이름은 구체적이면 안됨.
• 주액터: 시스템을 사용함으로써 이득을 얻는 대상. 주로 사람이 해당.
• 부액터: 주액터의 목적 달성을 위해 시스템에 서비스를 제공하는 외부 시스템.
• 유스케이스: 사용자가 보는 관점에서 시스템이 액터에게 제공하는 서비스 또는 기능을 표현한 것.

관계

• 포함(include) 관계: 두 개 이상의 유스케이스에 공통적으로 적용되는 기능을 별도로 분리하여 새로운 유스케이스로 만든 경우, 원래의 유스케이스와 새롭게 분리된 유스케이스와의 관계.
• 확장(extend) 관계: 유스케이스가 특정 조건에 부합되어 유스케이스의 기능이 확장될 때.
• 일반화(generalization) 관계: 유사한 액터나 유스케이스를 하나의 그룹으로 묶고 싶을 때 그보다 일반적인 액터나 유스케이스를 만들어 이들을 연결하여 표현하는 관계.

 

활동(Activity) 다이어그램

활동 다이어그램: 사용자의 관점에서 시스템이 수행하는 기능을 처리 흐름에 따라 순서대로 표현한 것.

 

구성요소

• 액션: 더 이상 분해할 수 없는 단일 작업.
• 액티비티: 몇 개의 액션으로 분리될 수 있는 작업.
• 제어 흐름: 실행의 흐름을 표현.
• 시작 노드: 액션 또는 액티비티가 시작됨을 의미.
• 종료 노드: 액티비티 안의 흐름이 종료됨을 의미.
• 조건 노드: 조건에 따라 제어의 흐름이 분리됨을 표현.
• 병합 노드: 여러 경로의 흐름이 하나로 합쳐짐을 표현.
• 포크 노드: 액티비티의 흐름이 분리되어 수행됨을 표현.
• 조인 노드: 분리되어 수행되던 액티비티의 흐름이 다시 합쳐짐을 표현.
• 스윔레인: 액티비티 수행을 담당하는 주체를 구분.

 

클래스(Class) 다이어그램

클래스 다이어그램: 시스템을 구성하는 클래스, 클래스의 특성인 속성과 오퍼레이션, 클래스 사이의 관계, 속성과 오퍼레이션에 대한 제약 조건을 표현한 것.

 

클래스: 각각의 객체들이 갖는 속성과 오퍼레이션(동작)을 표현한다.

속성: 클래스의 상태나 정보를 표현한다.

오퍼레이션: 클래스가 수행할 수 있는 동작. 함수, 메서드라고도 한다.

 

제약조건: 속성에 입력될 값에 대한 제약조건이나 오퍼레이션 수행 전후에 지정해야 할 조건

 

관계: 클래스와 클래스 사이의 연관성. 연관 관계, 집합 관계, 포함 관계, 일반화 관계, 의존 관계

 

시퀀스(Sequence) 다이어그램

시퀀스 다이어그램: 시스템이나 객체들이 메시지를 주고받으며 시간의 흐름에 따라 상호 작용하는 과정을 액터, 객체, 메시지 등의 요소를 사용하여 그림으로 표현한 것.

 

구성요소

• 액터: 시스템으로부터 서비스를 요청하는 외부 요소. 사람이나 외부 시스템을 의미.
• 객체: 메시지를 주고받은 주체.
• 라이프라인: 객체가 메모리에 존재하는 기간.
• 활성 상자: 객체가 메시지를 주고받으며 구동되고 있음을 표현.
• 메시지: 객체가 상호작용을 위해 주고받는 메시지.
• 객체 소멸: 객체가 더 이상 메모리에 존재하지 않음을 의미.
• 프레임: 다이어그램의 전체 또는 일부를 묶어 표현.

 

커뮤니케이션(Communication) 다이어그램

커뮤니케이션 다이어그램: 시스템이나 객체들이 메시지를 주고받으며 시간의 흐름에 따라 상호 작용하는 과정을 그림으로 표현.

 

구성요소

• 액터: 시스템으로부터 서비스를 요청하는 외부 요소. 사람이나 외부 시스템을 의미.
• 객체: 메시지를 주고받는 주체.
• 링크: 객체들 간의 관계를 표현하는 데 사용.
• 메시지: 객체가 상호 작용을 위해 주고받는 메시지.

 

상태(State) 다이어그램

상태 다이어그램: 객체들 사이에 발생하는 이벤트에 의한 객체들의 상태 변화를 그림으로 표현.

 

구성요소

• 상태: 객체의 상태를 표현.
• 시작 상태: 상태의 시작을 표현.
• 종료 상태: 상태의 종료를 표현.
• 상태 전환: 상태 사이의 흐름, 변화를 화살표로 표현.
• 이벤트: 상태에 변화를 주는 현상.
• 프레임: 상태 다이어그램의 범위를 표현.

 

 

* 이 글은 시나공 정보처리기사 실기 책을 토대로 작성되었습니다.