[현행 시스템 파악]
- 현행 시스템 파악이란,
현재 운영되는 시스템의 구성을 파악하는 활동으로,
시스템 기능, 입출력 뿐 아니라 소프트웨어, 하드웨어, 네트워크 구성 등을 파악하는 활동입니다.
- 현행 시스템 파악 절차는 아래와 같습니다.
1 단계 (시스템 파악) :
구성 현황 파악,
기능 현황 파악,
인터페이스 현황 파악
2 단계 (소프트웨어 파악) :
아키텍쳐 파악,
소프트웨어 구성 파악
3 단계 (하드웨어 파악) :
하드웨어 파악,
네트워크 구성 파악
아래에서 각 세부 절차에 대해 정리하겠습니다.
- 시스템 구성 현황 파악
현행 시스템을 구성하는 요소를 파악하는 것입니다.
주 업무에 해당하는 기간 업무와, 주 업무에 대한 보조 업무에 해당하는 지원 업무로 구분됩니다.
- 시스템 기능 현황 파악
단위 업무 시스템이 현재 제공하고 있는 기능을 파악하는 행위입니다.
시스템을 이루는 기능의 종류를 계층별로 나타내자면,
시스템 - 단위 기능 - 하부 기능 - 세부 기능
위와 같이 시스템은 단위 기능의 합으로 이루어지고, 단위 기능은 하부 기능의 합, 하부 기능은 세부 기능의 합으로 이루어지도록 정리할 수 있습니다.
- 시스템 인터페이스 현황 파악
인터페이스는 기능들 간에 통신하기 위한 데이터 형식을 생각하면 됩니다.
예를들어 단위 기능을 다른 기능이 아직 준비되지 않은 상태에서 개발한다고 할 때,
다른 기능이 없다고 하여 진행을 못하는 것이 아니라,
입력값으로 숫자 2개를 보내주면, 출력값으로 문자를 보내줄 것이다 라고 미리 정해두면 기능의 독립성을 유지한 상태로 개발이 가능하죠.
위에서 말한 것처럼 기능의 입력과 출력 형태를 미리 지정한 것이 인터페이스이고, 소프트웨어 개발시에는 단위별로 기능을 분리하여 인터페이스를 먼저 만들고 기능 구현을 하는 경우가 주가 되기에, 인터페이스의 파악은 곧 시스템의 형태를 알 수 있는 기본적인 행위입니다.
문서로 이를 정리할 때에는,
1. 데이터 형식 : 고정 포맷, 가변 포맷, JSON, XML 등 어떤 형식으로 데이터를 나타내는지
2. 통신규약(프로토콜) : HTTP, TCP/IP, X.25 등 네트워크 통신을 어떤 방식으로 할 것인지
3. 연계 유형 : EAI, FEP 등 기업 내 다양한 시스템이 어떤 방식으로 서로 연동되는지
위와 같은 기준으로 정리하면 좋습니다.
- 시스템 아키텍쳐 구성도 파악
시스템 아키텍쳐 구성도를 사용하여 현황을 파악합니다.
시스템 아키텍쳐 구성도의 예시는 위와 같으며,
위와 같이 시스템을 구성하고 있는 요소들을 시각적으로 확인할 수 있도록 작성되며,
업무 시스템별 아키텍쳐가 다른 경우에는 가장 핵심이 되는 기간 업무 처리 시스템을 기준으로 파악합니다.
- 소프트웨어 구성도 파악
소프트웨어 구성도를 기반으로 단위 업무 시스템의 업무 처리를 위해 설치되어있는 소프트웨어들을 파악합니다.
위와 같은 구성도를 기반으로,
정리하고 파악하면 되며,
| 구분 | 시스템명 | SW 제품명 | 용도 | 라이선스 적용 방식 | 라이선스 개수 |
| 기간 업무 | 도서 대여 | MySQL | DB | 상용 | 1 |
| Apache Tomcat | WAS | 오픈 소스 | 무제한 |
이러한 테이블 형식으로 정보를 정리합니다.
- 하드웨어 구성도 파악
시스템을 구성하는 하드웨어 구조를 파악합니다.
단위 업무 시스템들에 대한
물리적 위치,
주요 사항,
수량,
이중화 적용 여부
등의 정보를 파악합니다.
정보 정리 예시는 아래와 같습니다.
| 구분 | 시스템명 | 서버 용도 | 제품명 | 주요 사양 | 수량 | 이중화 |
| 기간 업무 | 도서 관리 | DB | Dell CD03 | CPU : 6Core RAM : 16GB |
1 | Y |
- 네트워크 구성도 파악
시스템의 네트워크 연결 방식에 대한 구조를 그림으로 표현함으로써 조직 내 서버들의 물리적 위치 관계를 파악하고,
보안 취약성, 네트워크 장애 발생 추적 등의 처리에 활용 할 수 있습니다.
[소프트웨어 개발 환경 종류]
(운영체제)
- 운영체제란, 윈도우즈나 MacOS, Linux 와 같은 컴퓨터 디바이스를 사용하게 만들어주는 시스템 소프트웨어입니다.
디바이스에 필수나 마찬가지로 설치되는 종류의 소프트웨어이므로 대다수의 응용 프로그램을 만들 때에는 운영체제의 위에 돌아가는 소프트웨어를 만드는 것이기에 개발 진행에 비중이 높은 환경 요소입니다.
- 주요 운영체제의 종류는
1. Windows : 개인용 PC 시장에 큰 점유율을 가지는 OS
2. MacOS : Apple Mac 컴퓨터 전용 OS 이면서, Windows 와 같이 개인용 PC 시장의 Mac 디바이스에 필수인 OS
3. UNIX : 대형 컴퓨터 및 서버에서 주로 사용되며, 안정성과 보안성이 뛰어난 다중 사용자용 OS입니다.
4. Linux : UNIX 구조를 기반으로 만들어졌으며, 오픈소스로 누구나 자유롭게 사용할 수 있는 OS입니다.
서버, 클라우드, 임베디드 시스템뿐만 아니라 데스크톱 환경에서도 사용됩니다.
많은 배포판(예: Ubuntu, CentOS, Debian 등)이 존재합니다.
5. Android : 휴대용 디바이스 전용 OS, 무료이며 리눅스 기반입니다.
6. iOS : Apple 의 아이폰 전용 OS, 유료이며 하드웨어에 포함되어 있습니다.
- 운영체제를 선별할 때 고려해야할 사항으로는,
1. 신뢰도 : 메모리 누수, 보안 취약점, 버그 등에 안전한지
2. 성능 : 대규모 작업 처리, 동시 사용자 요청 처리, 가용 메모리 크기
3. 기술 지원 : 공급 업체에서의 기술 지원 여부, 사용자 커뮤니티 활성화 여부, 오픈소스 여부
4. 주변 기기 : 하드웨어가 해당 운영체제를 지원하는지 여부
5. 구축 비용 : 운영체제 선별시 들어갈 라이선스, 유지 관리 등의 비용
(DBMS(Database Management System))
- DBMS 란, 데이터를 저장하고 활용하는 시스템 소프트웨어입니다.
데이터를 효율적으로 저장하고, 저장된 데이터를 안전하게 관리하고, 빠르게 검색할 수 있는 기능 등,
데이터를 다루는 모든 종류의 기능을 제공합니다.
응용 소프트웨어는 이것으로 데이터를 저장하고 활용하는 방식으로 빠르고 안전하게 데이터 처리 기능을 구현할 수 있습니다.
- 주요 DBMS 의 종류는,
1. Oracle : 대규모, 대량 데이터를 안정적으로 처리하는 전문적인 유료 DBMS 입니다.
2. MS-SQL : 중소 규모에 어울리는 안정적인 유료 DBMS 입니다.
3. My-SQL : 오픈소스 무료 DBMS
4. MongoDB : 위와 같은 RDBMS(관계형 데이터베이스) 와는 근본적으로 다른 NoSQL DBMS 입니다.
- DBMS 선별시 고려해야할 사항으로는,
1. 가용성 : 백업 및 복구 편의성, 이중화 및 복제를 지원하는지
2. 성능 : 대용량 데이터 처리 능력
3. 상호 호환성 : 운영체제에서 설치 및 운영이 가능한지 여부
(미들웨어)
- 미들웨어란, 운영체제와 응용 소프트웨어의 사이에 위치하여 운영체제가 제공하는 기능을 응용 소프트웨어 계층에서 쉽고 안정적으로 사용할 수 있게 래핑한 기능을 제공하는 소프트웨어입니다.
응용 소프트웨어를 개발하는 개발자를 대상으로 개발되는 소프트웨어이므로 데이터 교환의 일관성을 유지하기 위한 표준화된 인터페이스가 제공됩니다.
- 미들웨어 선별시 고려해야할 사항으로는,
가용성, 성능, 기술 지원, 구축 비용 등이 있습니다.
(오픈소스 소프트웨어)
- 오픈소스란, 개발자가 개발한 소프트웨어의 소스코드를 무료로 공개하여 누구나 제한 없이 사용 및 개작이 가능하도록 허용한 소프트웨어입니다.
얼마든 변경이 가능하므로 전세계의 개발자들의 개선버전이 올라오며, 무료로 사용이 가능합니다.
- 오픈소스 선별시 고려해야할 사항으로는,
무료로 공개하지만 조건이 붙어있는 다양한 라이선스가 적용되어 있을 수가 있고,
무료인 만큼 소스코드가 에러 및 보안에 안전한지, 앞으로 지속적으로 케어를 받을 수 있을 것인지, 개발자 커뮤니티 상에서 소통이 활발한지 등을 파악해야합니다.
[요구 공학(Requirements Engineering)]
(요구 공학 개요)
- 요구공학이란, 소프트웨어 개발 요구사항을 정의, 문서화, 관리하는 프로세스입니다.
요구공학의 목적은,
이해관계자들에게 효과적인 소통 수단을 제공하고 불필요한 비용을 절감시키는 것입니다.
요구공학에 따라 요구사항을 구조화함으로써 요구사항의 변경 추적이 가능하며 요구사항 손실을 최소화 할 수 있습니다.
- 요구사항 관리 도구
사용자의 요구사항을 관리하는 도구를 활용할 수 있습니다.
요구사항 관리 도구의 주요 기능으로는,
1. 요구사항 변경에 따른 영향도 및 비용 편익 분석
2. 요구사항이 변경된 이력 추적
3. 요구사항을 조직적으로 관리하며 우선순위나 리스크 관리
4. 요구사항 관리 환경 조성, 외부 연동, 협업 환경 제공
- 요구공학 프로세스는,
도출 -> 분석 -> 명세 -> 검증
의 순서로 진행됩니다.
각 프로세스 내용은 아래에 하나씩 정리합니다.
[요구사항 도출]
- 요구사항 도출이란,
요구사항을 어디서 어떻게 수집할지를 결정하는 첫번째 단계입니다.
정확한 요구사항 도출을 위해서는 이해관계자들 간의 효율적인 의사소통이 중요하며,
요구사항 도출로 인하여 이해관계자 및 개발자와 고객 사이의 관계가 명확해집니다.
- 요구사항 도출 기법
고객의 요구사항은 불명확하고 불규칙하게 변하는 경우가 많습니다.
아래와 같은 다양한 도출 기법을 사용하여 최대한 정보를 이끌어내고 요구사항의 골격을 밝혀내야합니다.
1. 인터뷰 : 되도록 많은 관계자들과 대면하여 되도록 다양하고 많은 의견을 듣습니다.
2. 설문 : 관계자들의 진솔한 관심, 정보, 의견을 끌어낼 문항을 준비하여 설문을 돌리고 회수하여 파악합니다.
3. 사용자 스토리 : 사용자가 시스템에 바라는 기능을 이야기 형태로 기술하게 합니다.
4. 업무절차 조사 : 기업 내부 표준, 업무 매뉴얼 등을 조사합니다.
5. 브레인 스토밍 : 대면으로 진행하며, 최대한 많은 요구사항을 수집하기 위한 방법입니다. 스토밍 기법에 훈련된 인원으로 수행합니다.
6. 프로토타이핑 : 예상 기능 일부를 빠르게 구현하여 시제품을 가지고 피드백 진행
7. 유스케이스 : 사용자 요구사항을 사용자, 기능, 관계로 표현합니다.
자주 사용되는 중요한 요구사항 정리 방법이므로 자세한 내용은 아래 항목에 따로 정리합니다.
(유스케이스(Use Case) 정리)
- 유스케이스란, 사용자의 소프트웨어 사용 방식을 추상적인 상호작용으로, 유스케이스 다이어그램을 이용하여 정보를 문서화 합니다.
- 유스케이스 다이어그램이란, 시스템의 기능과 사용자와의 상호작용을 사용자 관점에서 표현한 도표입니다.
시스템의 범위를 파악하기 쉽고, 외부 요소와 시스템 간의 상호 작용을 파악할 수 있습니다.
예시는 위와 같으며,
위에서 보이는 것 처럼 시스템 범위, 기능, 사용자, 그리고 관계를 단순히 표현하였습니다.
- 유스케이스 다이어그램의 구성 요소를 정리하겠습니다.
1. 시스템 범위 : 위 도표의 사각형과 같이 기능들을 하나로 묶는 하나의 시스템 범위입니다.
2. 주 액터(사용자) : 시스템을 사용하는 주체입니다. 주로 사람이지만 다른 시스템일 수도 있고, 최대한 간단하게 표현합니다.
3. 부 액터(사용자) : 주 액터의 목적 달성을 위해 제공되는 외부 시스템입니다.(위의 도표에는 없지만 시스템 경계를 넘어선 다른 시스템이 있다면 이것이 부 액터입니다.)
4. 유스케이스 : 위 도표의 동그라미 부분으로, 사용자에게 제공되는 시스템의 기능을 표현한 것입니다.
5. 관계 : 유스케이스와 유스케이스, 액터와 유스케이스, 액터와 액터 간의 관계를 나타냅니다.
관계는 포함관계, 일반화 관계, 확장 관계가 있습니다.
포함 관계는, 하나의 유스케이스를 실행하기 위해 선행되어야 하는 유스케이스를 의미하며,
유스케이스에서 선행 되어야 할 유스케이스를 향해 점선 화살표를 연결하고 <<include>> 를 붙입니다.
예를들어,
게시판 글 작성에 로그인이 꼭 필요하다면,
글 작성 --<<include>>--> 로그인
이렇게 표현합니다.
일반화 관계는,
유스케이스간의 상위 하위 관계를 표현하는 관계로,
하위 유스케이스에서 상위 유스케이스 방향으로 속이 빈 삼각형 실선 화살표로 표현합니다.
확장 관계는,
한 유스케이스 실행을 위해 필수가 아닌 유스케이스가 있을 때를 표현하는 관계로,
필수가 아닌 유스케이스에서 종속되는 유스케이스를 향해 점선 화살표로 <<extend>> 를 붙입니다.
예를들어,
게시판 글을 작성할 때 그냥 글만 작성할 수도 있고, 파일을 첨부할 수도 있습니다.
파일 첨부는 필수가 아니므로 이 관계는,
글 작성 <--<<extend>>-- 파일 첨부
위와 같습니다.
- 유스케이스 다이어그램 작성 주의사항
1. 유스케이스는 실행순서를 나타내지 않으므로 흐름도처럼 그리지 않습니다.
2. 관계 요소를 과도하게 사용하지 않고 최대한 간결하게 표현합니다.
- 유스케이스 기술서
유스케이스 다이어그램이 시각적으로 간단하게 사용성 정보를 알려준다면, 유스케이스 기술서는 보다 구체적인 서술 문서입니다.
유스케이스 다이어그램에 있는 각각의 유스케이스에 대해 작성하며,
유스케이스 기술서의 구성 요소는 아래와 같습니다.
1. 유스케이스명 : 액터가 달성하고자 하는 목적을 명확히 표현
2. 액터명 : 실제 사람의 이름이 아닌 역할이나 그룹을 나타내는 이름을 사용
3. 개요 : 유스케이스 수행 시나리오를 간략히 요약
4. 사전조건 : 유스케이스 수행을 위한 사전 조건 기술
5. 사후조건 : 유스케이스 수행 후 만족해야 하는 조건 기술
6. 기본흐름 : 목적 달성을 위해 수행되는 완전한 상호작용 흐름을 기술
7. 트리거 : 유스케이스가 시작되는 사건, 기본 흐름의 첫번째로 기술
8. 대체흐름 : 기본 흐름을 벗어나 선택적, 예외적으로 처리되는 흐름을 기술
서술서의 예시는 아래와 같습니다.
| 유스케이스명 | 회원 등록 |
| 액터명 | 주 액터 : 관리자 부 액터 : 회원관리 시스템 |
| 개요 | 관리자가 회원 관리 시스템에 신규 회원을 등록합니다. |
| 사전조건 | 1. 회원 관리 시스템이 정상 동작중이어야 합니다. 2. 회원 등록을 위한 정보 입력시 신분증이 필요합니다. |
| 사후조건 | 1. 회원 관리 시스템에 등록한 회원 정보 검색이 가능해야 합니다. |
| 기본흐름 | 1. 관리자가 회원 등록 메뉴에 진입(트리거) 2. 관리자가 회원 등록 정보를 시스템에 입력 ... |
| 대체흐름 1 | err1 입력 정보 무결성 검증 불가 상태 err1-1. 입력 정보와 원본 정보 불일치 확인 err1-2. ... err2 입력 정보의 중복성 검증 불가 상태 err2-1. 기존 입력 정보를 통해 실제 회원 정보 식별 |
| 대체흐름 2 | ... |
[요구사항 분석]
(요구사항 분석이란)
- 요구사항 분석이란, 요구사항 도출 단계에서 수집한 다양한 요구사항들을 분석하여, 구현해야하는 기능 및 특성을 조정해나가는 활동입니다.
이 단계에서 도출된 요구사항들 중 명확하지 않거나 상충되는 요구사항 등을 분석하여 그 문제점을 해결합니다.
- 요구사항 분석의 특징은 아래와 같습니다.
1. 소프트웨어의 정확한 범위 파악과 외부 환경과의 상호작용 분석이 가능합니다.
2. 요구사항 분석 단계에서의 문서 산출물은 유지보수에 유용하게 활용되므로 잘 작성해 보관하는 것이 좋습니다.
3. 요구사항의 변경은 개발 전체에 영향을 끼치므로 정확한 분석이 필요합니다.
(요구사항 분석 프로세스)
1. 요구사항 분석 :
도출해낸 요구사항을 분석하여 기능적 요구사항과 비기능적 요구사항으로 나눕니다.
기능적 요구사항이란, 시스템 기능, 기술에 대한 요구사항이며,
비기능적 요구사항이란, 성능, 보안 수준, 품질, 안전성에 대한 신뢰도 등의 요구사항입니다.
예를들어 배달 시스템 개발로 보자면,
기능적 요구사항이란, 배달 신청하고 배달 현황을 파악하는 등의 기능,
비기능적 요구사항이란, 동시 사용자 1만명 이상에서도 안정적으로 동작하고, 특정 보안 테스트를 통과해야 한다...
이렇게 나눌 수 있습니다.
2. 개념 모델링 :
분석된 요구사항을 기반으로 실체(Entity) 와 실제간 관계(Relation)를 모델링 하는 작업입니다.
개념 모델링 방법은,
UML(Unified Modeling Language), Usecase Diagram, 데이터 흐름 모델, 상태모델, 목표 기반 모델, 객체 모델, 사용자 인터랙션, 데이터 모델 등의 다양한 방법을 적용할 수 있습니다.
3. 요구사항 협상 :
요구사항들이 서로 상충된 경우 이를 합의하는 과정입니다.
요구사항이 상충되는 대표적인 유형은,
두 명 이상의 이해관계자간 요구사항이 서로 충돌 됨,
요구사항에 대해 보유 자원이 충족되지 않음,
요구사항 자체의 논리적 충돌
위와 같습니다.
요구사항의 상충에 대응하는 모범적 방법은,
요구사항을 포기하기보다는 우선순위를 부여하여 적절한 기준점을 찾는 협의의 과정을 거치는 것이 좋습니다.
4. 정형 분석
요구사항 분석 프로세스의 마지막 단계입니다.
앞서 분석한 요구사항 정보를 수학 기호 등 정형화된 방식으로 표현한 후 최종 분석을 합니다.
(구조적 분석 방법)
- 구조적 분석이란 요구사항의 분석을 도표와 같은 도형 중심의 시각 자료로 정리하고 나타내는 방식입니다.
- 구조적 분석 기본 원칙
1. 추상화 원칙 : 모든 정보를 상세히 나타내는 것이 아닌 중요한 정보만을 간결히 표현
2. 정형화 원칙 : 문제 해결을 정형화된 공학적 방식으로 접근
3. 분할 정복 원칙 : 어려운 문제를 간단하고 작은 하부 문제들로 나누어 해결하는 방식으로 전체 문제를 해결
4. 계층화 : 정보를 계층화하여 나타내므로 이해 및 관리 수고를 줄입니다.
- 구조적 분석 도구 종류
1. 자료 흐름도(DFD, Data Flow Diagram) 및 자료 사전(DD, Data Dictionary)
자료 흐름도란, 기능에 의한 데이터 흐름을 도형으로 표현한 도표입니다.
제어의 흐름이 아닌 데이터의 흐름에 중심을 두고 있으며, 작업 소요시간은 파악이 불가능합니다.
자료 흐름도의 구성은
단말 : 사각형으로 표기, 데이터 입출력의 주체
프로세스 : 타원으로 표기, 데이터 처리 과정
자료 흐름 : 화살표로 표기, 데이터 흐름의 방향
자료 저장소 : 상하 평행성으로 표기, 데이터가 저장되는 장소
이며, 예시 도표는 아래와 같습니다.
자료 사전이란,
자료 흐름도에 사용된 데이터의 이름과 속성을 표기한 메타데이터(데이터의 의미가 아니라 데이터 형태 등 외부적 정보)입니다.
자료사전의 표현 규칙을 예시와 함께 알아보겠습니다.
결제 코드 = {회원 번호} + 결제 요청 시점 timestamp + UUID
위와 같이 결제 코드라는 것을 정의하기 위해 등호를 사용하고,
서로 다른 두 데이터를 합칠 경우 + 를 사용합니다.
중괄호 요소는 반복적으로 사용되는 데이터를 의미합니다.
결제 타입 = ["K" | "N" | 'T"] = *K : 카카오페이, N : 네이버페이, T : 토스페이*
대괄호와 | 를 조합해서 위와 같이 결제 타입에 넣을 수 있는 미리 정해진 상수 목록을 표현할 수도 있고,
** 로 감싸는 것은 주석의 의미입니다.
추가 요구사항 = (상품 요구사항)
소괄호의 경우는 입력하지 않아도 되는 데이터.
이러한 규칙으로 작성하며,
자료사전 문서 형식은 아래와 같이 정리하여 보관합니다.
| 자료 사전 | 설명 |
| 결제 코드 = {회원 번호} + 결제 요청 시점 timestamp + UUID | 결제 코드는 회원별 번호와 결제 요청 시점의 timestamp 를 결합하고, 이에 랜덤 UUID 를 결합함으로써 고유성을 보장합니다. |
| ... | ... |
2. NS(Nassi-Schneiderman) 차트
NS 차트는, 문제 처리 프로세스를 도형을 통해 논리 중심으로 표현한 차트입니다.
순차(절차 코드), 선택(IF 문), 반복(For 문) 의 구조를 명확히 표현하므로 프로젝트 구현이 쉽습니다.
위 차트는 숫자 맞추기 게임을 표현해보았습니다.
위에서 아래로 차례로 시스템 동작을 적으면 되고,
반복시에는 반복되는 부분까지를 감싸면 되며(반복 종료시 반복 종료 표시),
조건문은 삼각형으로 좌우로 참거짓을 나누면 됩니다.
NS 차트의 장점은,
구조적으로 실제 구현이 편하며, 해석하기 쉽다는 것이고,
단점은,
복잡한 로직일 경우 차트의 크기가 커지고, GUI 나 이벤트 처리를 표현하기에는 부적합 하다는 것입니다.
3. HIPO(Hierarchy Input Process Output)
시스템의 기능을 계층 구조의 여러개의 고유 모듈로 분할하여 기능과 데이터의 관계를 표현한 도표입니다.
기능과 더불어 데이터의 의존성을 동시에 표현할 수 있으며, 하향식 소프트웨어 개발에 유용합니다.
HIPO 는 가시적 도표, 총체적 도표, 세부적 도표의 3가지 도표로 나뉘는데,
꼭 3가지를 모두 작성해야 하는 것은 아니며,
중요한 것은 모듈화, 계층화 방식으로 표현했다는 것입니다.
가시적 도표 : 시스템의 전체 기능과 흐름을 트리 형태로 표현한 도표
총체적 도표 : 기능별 입력, 처리, 출력에 대한 전반적 정보를 제공하는 도표
세부적 도표 : 총체적 도표의 기능을 구성하는 기본 요소들을 상세히 기술하는 도표
[요구사항 명세]
- 요구사항 명세란,
분석된 요구사항의 체계적인 검토, 평가, 승인이 가능하도록 문서화하는 것입니다.
- 명세 기법
요구사항의 명세 방식에 따라 정형 / 비정형 명세 기법으로 나뉩니다.
1. 정형 명세 기법
수학적 표현을 사용하여 사용자의 요구사항을 정확히 표현하는 기법입니다.
장점은,
명확하고 오류가 적고 모호성을 쉽게 파악 할 수 있다는 것이고,
단점은,
비교적 어려운 방식이므로 익숙해지기 위해 시간이 걸린다는 것입니다.
2. 비정형 명세 기법
자연어를 사용하여 자유롭게 표현하는 기법입니다.
장점은,
사용자와 개발자 간의 의사전달이 용이하고,
단점은,
모호하며 오류가 포함될 가능성이 있다는 것입니다.
- 명세서 작성시 고려해야할 사항은 아래와 같습니다.
1. 정확성 : 모든 요구사항을 정확히 서술
2. 명백성 : 요구사항을 애매하지 않은 방식으로 명확히 서술
3. 완전성 : 기능, 성능, 제약사항, 속성 등 필요 정보를 모두 완전하게 서술
4. 일관성 : 서술된 요구사항 간 모순 및 상충이 없게 서술
5. 중요도 : 중요도 및 우선순위를 알 수 있도록 서술
6. 수정 가능성 : 추후 요구사항이 수정되더라도 다른 부분에 영향이 최소화 되도록 서술
7. 추적성 : 관련 자료 링크, 산출물 링크 등을 달아서 추적이 용이하게 서술
[요구사항 검증]
- 요구사항 검증은 요구사항을 기반으로 생성된 산출물을 대상으로 요구사항이 올바르게 반영되었는지를 검증하는 작업입니다.
잘못된 설계로 개발이 들어가면 개발 산출물 수정에 비용이 들듯,
잘못된 요구사항을 기반으로 설계가 들어가는 것은 설계 산출물 수정 및 그로인해 만들어지는 개발 산출물 수정에 비용이 들게 되므로 중요한 작업입니다.
- 요구사항 검증에서 파악해야할 사항은 아래와 같습니다.
1. 유효성 : 요구사항을 만족하는 기능을 제공하는지 확인
2. 일관성 : 요구사항들의 상충 여부 확인
3. 완결성 : 산출물이 모든 요구사항을 반영했는지 확인
4. 현실성 : 환경, 예산, 규제 등의 사유로 개발이 가능한지 여부를 확인
5. 검증 가능성 : 요구사항 검증 가능 여부를 확인
(요구사항 검증 기법 종류)
- 요구사항 검토(Review)
요구사항 검토 담당자들이 직접 요구사항 명세서를 검증하는 일반적인 방법입니다.
검증 방식에 따라 아래와 같이 구분합니다.
1. 동료(Peer) 검토 : 요구사항 명세서 작성자가 다수의 이해관계자에게 내용을 직접 설명하며 의견을 나누어 결함 분석
2. 워크스루(Walk Through) : 미리 요구사항 명세서를 배포하여 사전 검토 후 짧은 회의를 통해 결함 분석
3. 인스펙션(Inspection) : 요구사항 명세서 작성자 이외의 전문 검토 그룹이 상세히 결함 분석
- 프로토타이핑
요구사항 검증을 위한 시제품을 신속 간단하게 개발하여, 이를 기반으로 요구사항을 검증하는 방법입니다.
장점은,
즉각적 피드백이 가능하고,
문제점의 사전 식별이 가능하며,
새로운 요구사항이 도출될 수 있다는 것이고,
단점은,
시제품을 개발할 때마다 그에따른 비용이 증가되며,
실제 데이터를 만들 때는 시제품에서 기대되는 수준의 기능을 구현할 수 없을수도 있습니다. (시제품은 껍데기를 만든 것 뿐이기에 실제 개발시 여러 현실적 요소를 반영시 기대 충족이 안 될 수 있음)
- 모델 검증
요구사항 분석 단계에서 개발한 모델을 검증하는 것입니다.
요구사항 모델이 요구사항을 만족하즌지, 요구사항을 정확히 도출하였고 반영하였는지를 검증합니다.
실제 실행을 통해 동적 분석하는 검증이 아닌,
모델 구조 및 의사소통 경로 등을 정적 분석하는 검증입니다.
- 인수 테스트
개발이 완료된 소프트웨어를 인수받아 테스트하여 요구사항을 검증하는 방법입니다.
인수자가 개발자가 아니고 사용자, 혹은 중계자일 경우 사용하는 검증 방식으로,
사용자 입장에서의 테스트 계획을 세워 진행합니다.
'학문' 카테고리의 다른 글
| 정보이론 기초 정리(정보량 + 정보 엔트로피) (구 블로그 글 복구) (0) | 2025.04.09 |
|---|---|
| [정보 처리] 4. UML(Unified Modeling Language) (0) | 2025.04.06 |
| [정보 처리] 2. 소프트웨어 개발 모델 최적화 (0) | 2025.04.03 |
| [정보 처리] 1. 소프트웨어 개발 방법론 (0) | 2025.04.03 |
| 마할라노비스 거리(Mahalanobis Distance) 개인정리 (구 블로그 글 복구) (0) | 2025.04.01 |