인터페이스 요구사항 쉽게 이야기하기

출처: PhotoMIX-company on Pixabay

 

 요구사항 중에서 인터페이스 요구사항이라고 하는 것이 있습니다.

이 인터페이스 요구사항이라고 하는 건 뭘까요?

 

Q. 인터페이스 요구사항은 뭔가요?

 

 인터페이스 요구사항이란 인터페이스의 설계 및 구현 전에 사용자들의 요구사항 명세서에 정확하고 완전히 기술되어있는지 검토하고 개발 범위의 기준인 베이스라인을 설정하는 것을 의미합니다.

 

 검토에 따른 검증 절차가 있는데요.

검증절차는 1. 인터페이스 요구사항 검토 계획 수립 -> 2. 인터페이스 요구사항 검토 및 오류 수정 -> 3. 인터페이스 요구사항 베이스라인 설정 이 3단계로 진행됩니다.

 

인터페이스 요구사항 검토 계획 수립 단계에서는 인터페이스 요구사항 검토 체크리스트를 작성합니다.

인터페이스 요구사항 검토 및 오류 수정 단계에서는 체크리스트 항목에 따라 인터페이스 요구사항 명세서를 검토합니다.

인터페이스 요구사항 베이스라인 설정 단계에서는 설계 및 구현을 위해 요구사항 명세서의 베이스 라인을 설정하게 됩니다.

 

Q. 요구사항 검증 방법에는 어떤 것들이 있나요?

 

 요구사항을 정리하고 작성을 하는 데 문제는 이것이 잘 적힌 것인가? 혹은 내가 잘 적은 건가? 알 수 있는 방법 즉, 검증이 필요합니다. 이 검증 방법으로는 동료 검토(Peer Review), 워크 스루(Walk Through), 인스펙션(Inspection) 3가지가 있습니다.

 

 동료 검토(Peer Review)방법은 정말 동료가 검토해주는 것입니다. 만든 요구사항 명세서를 동료에게 보여주는 것이죠. "나 이거 잘 만들었어?" 이렇게 말이죠.

 

 워크 스루(Walk Through)방법은 조금 더 넓은 범위의 검토방식으로 동료뿐만 아니라 개발자라던지 자문위원이라던지 조금 더 넓은 범위의 사람들과 함께 요구사항 명세서를 보고 검토 받는 것입니다. "저는 요구사항을 이렇게 정리했습니다. 어떻게 생각하시나요?"

 

 인스펙션(Inspection)방법은 워크 스루보다 더 넓습니다. 모든 사람에게 다 나누어주면서 공개적인 검토 심의회 같은 게 열리는 것입니다. 더 많은 사람들이 검토에 참여하게 됩니다.

 

 * 요구사항을 테스트가 가능해야하는 데 테스트를 할 수 있도록 작성된 문서를 [테스트 케이스]라고 합니다.

 

Q. 요구사항 검증 항목은 어떤 것들이 있을까요?

 

 요구사항 검증항목은 요구사항 명세서를 작성할 때 생각해야하는 항목과 동일하게 평가받게 되는데요.

바로 완전성 일관성, 명확성, 기능성, 검증가능성, 추적가능성, 변경요구성입니다.

 

Q. 인터페이스 방법을 명세화한다는 건 어떤 건가요?

 

 내/외부 시스템이 연동되어 작동할 때 인터페이스별 송/수신 방법, 송/수신 데이터, 오류 식별 및 처리 방법에 대한 문서를 명확하게 정리하는 것을 인터페이스 방법을 명세화 한다고 합니다.

이 명세화를 하기 위해서는 시스템 연계 기술을 비롯해서 통신 유형, 처리 유형, 발행 주기 등이 뒷받침 되어야 합니다.

 

Q. 시스템 연계 기술, 통신 유형, 처리 유형은 뭘까?

 

 발행 주기는 발행하는 기간일테니 별 문제 없는 데 시스템 연계 기술이나 통신 유형, 처리 유형은 뭘까요?

 

[시스템 연계 기술]

 

 개발할 시스템과 내/외부 시스템을 연계시키기 위한 기술을 의미한다고 합니다.

 

- DB Link: 데이터베이스에서 제공하는 DB Link 객체 방법을 이용하는 것을 말합니다.

 

- API/Open API: 송신 시스템의 데이터베이스에서 데이터를 읽어와 제공하는 애플리케이션 프로그래밍 인터페이스를 말합니다.

 

- 연계 솔루션: EAI서버(송/수신 데이터 처리 진행 현황을 계속 감시하고 통제하기 위한 서버)와 송수신 시스템에 설치되는 클라이언트를 이용하는 방법입니다.

 

- Socket: 서버는 통신을 위해서 소켓을 필요로 합니다. 포트를 할당하고 클라이언트와 연결하는 네트워크 기법을 말합니다.

 

- 웹서비스: 서식 프로토콜을 이용하는 연계 서비스를 말합니다.

 

[통신 유형]

 

 내부 데이터와 외부 데이터를 어떻게 송신할 것인가?에 대한 내용입니다.

단방향, 동기, 비동기 3가지가 있는 데

 

- 단방향의 경우: 시스템에서 요청을 하고 응답이 없는 경우 즉, 요청만 계속 하는 경우입니다.

 

- 동기의 경우: 요청하고나서 다시 응답이 올때까지 대기하는 경우입니다.

 

- 비동기의 경우: 요청을 하고 나서 응답이 올때까지 계속 기다리는 것이 아니라 다른 일을 하다가 응답이 오면 응답 온 내용에 대해서 진행하는 경우입니다.

 

[처리 유형]

 

 긴급한 것이냐? 아니냐? / 데이터가 많냐? 적냐? 로 처리 유형을 나누게 됩니다.

실시간 방식, 지연 처리방식, 배치 방식 이렇게 3가지로 나뉘게 되는데.

 

- 실시간 방식의 경우 "야~! 그 때 그 때 처리하자!"라는 방식입니다.

 

- 지연 처리방식의 경우 "데이터 계속 들어오는 거 아는 데 조금만 모았다가 처리하자!"라는 방식입니다. 왜 모아서 처리하는가? 그 이유는 통신비용이 부담이 될 경우 이 방식을 사용하기도 합니다.

 

- 배치 방식의 경우는 대량의 데이터를 한 꺼번에 처리하고자 할 때 "큰 거 간다!"라는 느낌입니다.

 

Q. 미들웨어란 무엇인가요?

 

 미들 웨어란 운영체제와 해당 운영체제에서 실행되는 프로그램 사이에 기타 추가적인 서비스가 필요한 경우 제공하는 소프트웨어입니다.

표준화된 인터페이스를 제공함으로서 시스템 간의 데이터 교환에 일관성을 보장합니다.

 

종류로는 DB, RPC, MOM, TP-Monitor, ORB, WAS가 있습니다.

 

- DB(DataBase): 데이터베이스 벤더에서 제공하는 클라이언트와 원격 데이터베이스를 연결하기 위한 것입니다.

 

- RPC(Romote Procedure Call): 멀리 떨어져있는 프로시저를 호출할 때 이 원격 프로시저를 마치 로컬 프로시저처럼 호출할 수 있는 방식입니다.

 

- MOM(Message Oriented Middleware): 메세지 기반의 비동기형 메세지를 전달하는 방식의 미들웨어로 온라인보다는 이기종간 분산데이터 시스템의 데이터 동기를 위해 사용됩니다.

 

- TP-Monitor(Transaction Processing Monitor): 항공기, 철도 예약 업무와 같은 온라인 트랜지션 업무에서 트랜잭션을 처리 및 감시하는 미들웨어로서 사용자 수가 증가해도 빠른 응답속도를 유지해야하는 경우에 사용됩니다.

 

- ORB(Object Request Broker): 객체 지향 미들웨어로 코바 표준 스펙을 구현한 미들웨어로서 TP-Monitor의 장점인 트랜스잭션처리와 모니터링등을 추가로 구현한 제품도 있습니다.

 

- WAS(Web Application Server): 정적인 콘텐츠를 처리하는 웹 서버와 달리 사용자의 요구에 따라 변하는 동적인 컨텐처를 처리하기 위한 것으로 클라이언트 서버보다는 웹 환경 구현을 위한 것입니다.

 

 

참고:https://devinus.tistory.com/10

[정보처리기사] 미들웨어(Middleware) 솔루션 종류