정보처리기사 필수 학습: 인터페이스 요구사항 완전 정복!!

1.내 ·외부 인터페이스 요구사항

모듈간 연동을 통해 상호작용하는 접속 방법이나 규칙을 정의

데이터를 주고 받으면서 목적을 명확히 정의

인터페이스 :

간접적으로 제어되는 장치와 실행하는 하드웨어 

기존의 소프트웨어와 새로운 소프트웨어를 연결하는 소프트웨어

요구사항 분류

1.기능적 요구사항 [해당하는 기능 중점]

• 내 · 외부 시스템 연계를 통해 수행될 기능과 관련된 요구사항
• 입력,처리과정,출력등 소프트웨어가 가자야할 기능적 속성에 대한 요구사항\

ex) 주문창,장바구니추가...

 

2.비기능적 요구사항 

• 시스템 기능에 관련되지않은 요구사항
• 성능,용의성,신뢰성,보안성,운용성,안정성...

ex)데이터복구,로그,보안,백업..

 

 

요구사항  검증 방법 ★

종류	설명
동료검토 (Peer Review)	- 2~3명이 진행하는 리뷰의 형태 - 요구사항 명세서 작성자가 요구사항 명세서를 설명하고, 이해 관계자들이 설명을 들으면서 결함을 발견해 나가는 형태
워크스루 (Walk Through)	- 시스템 개발 단계마다 실시하는 비정형 검토회의 형태 - 오류의 조기 발견이 목적 - 검토 자료를 회의 전에 배포해서 사전 검토 후 짧은 시간 동안 회의를 진행하여 결함을 발견해 나가는 형태 -개발자가 주최
인스펙션 (Inspection)	- 명세서 작성자를 제외한 다른 검토 전문가들이 명세서를 확인하여 결함을 발견해 나가는 형태 - 계획 → 개관 → 준비 → 검토회의 → 재작업 → 추적

 

동료검토( 동료에게 물어보기) , 워크스루(팀 회의에서 의견 물어보기), 인스펙션(공식적 회의)

리팩토링: 동료검토,워크스루,인스펙션을 한후 기능은 그대로고 여기서 가진 오류를 가지고 소스코드를 변경한다.

 

 

FTR(정형 기술 검토 회의)

- 오류를 발견하기 위한 공식적인 검토회의

목적

1. 기준에 따라 했는지 확인

2. 표현에 대한기능, 논리적 오류 발견

3. 관리하기 쉽게 하기

 

FTR 검토지침 ★

1. 제작자가 아닌 제품의 검토에만 집중

2. 문제영역을 명확히 표현

3.제기된 모든 문제를 바로 해결하지않음

4. 검토자들은 사전에 작성한 메모를 공유

5. 논쟁이나 반박을 제한

6. 의제를 정하고 범위를 유지

7. 참가자의 수를 제한하고 사전준비를 철저히 강요

8. 자원과 시간 일정을 할당

9.모든 검토자에게 의미 있는 교육을 행함

10.검토의 과정과 결과를 재검토