I. 소프트웨어 설계 - 인터페이스 설계 (1)

(1) 내/외부 인터페이스 요구사항

 1. 내/외부 인터페이스 요구사항의 개념

  - 내/외부 인터페이스란 조직 내/외부에 존재하는 시스템이 연동을 통해 상호 작용하기 위한 접송 방법이나 규칙을 의미

  - 요구사항이란 존재하는 시스템들이 특정 기능을 수행하기 위한 접속방법이나 규칙에 대한 필수적 요구사항을 뜻함

 

 2. 내/ 외부 인터페이스 요구사항의 구성

  - 이름, 연계 대상 시스템, 연계 범위 및 내용, 연계방식, 송신 데이터, 인터페이스 주기, 기타 고려사항으로 구성됨

 

 3. 내/외부 인터페이스 요구사항의 분류

분류	설명
기능적 요구사항	내/외부 인터페이스 연계를 통해 수행될 기능과 관련되어 소프트웨어가 가져야 하는 기능적 속성에 대한 요구사항
비기능적 요구사항	내/외부 인터페이스 연계시 성능, 용이성, 신뢰도, 보안성, 운용상의 제약, 안정성 등 시스템과 관련된 요구사항

*커스터마이징 (Customizing) :  개발된 IT 솔루션이나 웹사이트 등을 구입 또는 이용하고자 하는 사람이 원하는 형태로 재구성 또는 재설계

*FTP (File Transfer Protocol) :  TCP/IP 프로토콜을 가지고 서버와 클라이언트 사이에서 파일 전송을 하기 위한 프로토콜

 

4. 내/외부 인터페이스 요구사항 분석 방안

  1) 내/외부 인터페이스 관련 요구사항 식별 및 분류

 

순서	프로세스	설명
1	요구사항 식별	내/외부 인터페이스 관련 명세서 및 현황 자료 준비
2	내/외부 인터페이스 관련 명세서 및 현황 자료 준비	- 현행 시스템의 대내외 연계도, 연계 인터페이스 목록, 시스템 간 연계 업무에 대한 업무 프로세스나 업무 처리 기준 정의서 준비 - 기존 시스템을 커스터마이징해서 재사용 등 인터페이스 기술 요건이 이미 정의된 경우는 해당 자료 준비
3	기능 요구사항 및 비기능 요구사항 분류	- 내/ 외부 인터페이스 요구사항 정의서의 내용을 검토하여 기능 요구사항과 비기능 요구사항으로 분류

 

 2) 내/외부 인터페이스 요구사항 명세서 구체화

순서	프로세스	설명
1	요구사항 정의서 세분화	- 내/외부 인터페이스 요구사항 정의서 내용을 확인하여 분해가 필요할 경우 적절한 수준으로 세분화
2	내/외부 인터페이스 요구사항 내용의 이해 및 수정	- 내/외부 인터페이스 요구사항 정의서의 요구 내용을 이해하고 수정이 필요할 경우 수정하거나 구체화 - 응용 시스템의 기능 요구사항 분석 과정에서 작성한 유스케이스 다이어그램, 데이터 흐름도, 시스템 연관도 등 요구 분석 산출물들을 활용
3	누락된 내/외부 인터페이스 요구사항 신규 정의	- 요구사항을 비교, 검토하여 담당자 확인을 통해 누락 여부 검토하고 필요시 추가 - 제안요청서, 수행 계획서, 이해관계자와의 인터뷰를 기반으로 누락 조건 요구사항 명세서에 추가 - 요구사항 정의서를 이용하여 연계 대상시스템, 방식, 주기, 데이터 정보가 누락된 경우 보완
4	내/외부 인터페이스 요구사항 정리	- 수정, 추가의 경우 요구사항 목록과 요구사항 정의서 정리 - 요구사항에 대한 우선순위를 확인하고 중요도에 따라 우선순위 표기 - 수정된 요구사항 목록과 요구사항 정의서의 내용을 이해관계자들에게 공유

 

(2) 요구공학

 1. 요구공학(Requirement Engineering)의 개념

  - 사용자의 요구가 반영된 시스템을 개발하기 위하여 요구사항에 대한 추출, 분석, 명세, 검증, 관리하는 구조화 활동

 

 2. 요구공학의 목적

  - 이해관계자 사이의 효과적인 의사소통 수단제공 및 시스템 개발 요구사항의 공통된 이해 설정

  - 요구사항 누락 방지, 불필요한 비용 절감, 요구사항 변경 추적 가능

 

 3. 요구사항의 분류

  - 기능적 요구사항과 비기능적 요구사항으로 분류

구분	기능적 요구사항	비기능적 요구사항
개념	- 시스템이 제공하는 기능, 서비스에 대한 요구사항	- 시스템이 수행하는 기능 이외의 사항, 시스템 구축에 대한 제약사항에 관한 요구 사항
도출 방법	- 특정 입력에 대해 시스템이 어떻게 반응해야 하는지에 대한 기술 - 특정 상황에 대해 시스템이 어떻게 동작해야 하는지에 대한 기술	- 품질 속성에 관련하여 시스템이 갖춰야 할 사항에 관한 기술 - 시스템이 준수해야 할 제한 조건에 관한 기술
특성	- 기능성, 완전성, 일관성	- 신뢰성, 사용성, 효율성, 유지보수성, 이식성
사례	- 온라인 홈페이지에서는 쇼핑카트에 주문하고자 하는 품목을 저장하는 장바구니 기능을 제공해야한다. - 상품의 결제수단은 신용카드, 무통장입금, 포인트 결제가 가능하다.	- 특정 함수의 호출시간은 3초를 넘기지 않아야한다. - 시스템은 하루 24시간 가동되어야 하며 가동률 99.5%를 만족해야 한다. - 시스템은 운영되는 동안 패치 및 업그레이드가 가능해야한다.

 

 4. 요구공학 프로세스

  - 요구사항 개발 단계 (CMM Level 3 프로세스 영역)

프로세스	내용	기법/산출물
요구사항 추출	- 추상적 요구에 대한 정보를 구체적 요구사항을 표현하는 활동 - 고객분석, 조직환경 분석, 요구사항 분류, 요구사항 정제, 요구사항 소스 관리	인터뷰, 브레인스토밍, 델파이 기법, 롤플레이, 워크숍, 프로토타입, 설문지
요구사항 분석	- 요구사항에 대해 분석을 통해 완전성과 일관성을 확보 - 요구사항 모델링, 우선순위 부여, 수행할 요구사항 선정, 요구사항 협의	유스케이스 기반 분석 (UML, 모델링)
요구사항 명세	- 정형화된 요구사항을 생성하는 활동 - 요구사항 명세 기준 정의, 요구사항 명세서 작성, 요구사항 추적 관련 정보 저장	요구사항 명세서
요구사항 검증	- 올바르게 기술되었는지 검토 - 요구사항 검토, 용어 검증, 베이스라인 수립	베이스라인 수립, 요구사항 추적표

 

- 요구사항 개발 단계의 주요 기법

주요 기법	설명
인터뷰 (Interview)	이해관계자와 대화를 통해 정보를 구하는 공식적, 비공식적 정보 수집
델파이 기법 (Delphi Method)	전문가의 경험적 지식을 통한 문제 해결 및 미례예측 기법
롤 플레이 (Role Playing)	현실에 일어날 장면 설정 후 여러 사람이 연기를 통해 요구사항 분석
UML (Unified Modeling Language)	산출물을 명세화, 시각화, 문서화 할 시 모델링 기술과 방법론을 통합해 만든 모델링 언어
모델링 (Modeling)	물리현상을 특정한 목적에 대응하여 이용하기 쉬운 형식으로 표현하는 기법
요구사항 명세서 (Requirement Specification)	소프트웨어의 요구사항을 분석하고 정의하는 단계에서 작성되는 최종 산출물
베이스라인 (Baseline)	공학적, 관리적, 획득적 측면을 고려하여 정한 하나의 분기점
요구사항 추적표	요구사항 정의서를 기준으로 최종 산출물이 어떻게 반영되고 변경되었는지 확인이 가능한 문서

 

- 요구사항 명세 원리 및 검증 항목

항목	설명
명확성	각각의 요구 사항 명세 내용은 하나의 의미만 부여해야 함
완전성	기능, 성능, 속성, 인터페이스, 설계 제약 등에 관한 시스템 요구사항이 포함되어야 함
검증 가능성	요구사항 내용의 충족 여부와 달성 정도에 대한 확인이 가능해야 함
일관성	요구사항의 내용간 상호 모순이 없어야 함
수정 용이성	요구사항 변경시 수정이 쉬워야 함
추적 가능성	각 요구사항 근거에 대한 추적과 상호참조가 가능해야 함
개발 후 이용성	시스템 개발 후 운영 및 유지보수에 효과적인 이용이 가능해야 함

 2) 요구사항 관리단계 (CMM Level 2 프로세스 영역)

  - 요구사항 관리는 요구사항 변경에 대해 일치성과 무결성을 제공하기위해 변경제어와 추적 등의 관리를 수행 하는 활동

순서	프로세스	내용	기법/산출물
1	요구사항 협상	가용한 자원과 수용 가능한 위험 수준에서 구현 가능한 기능 협상	우선순위 설정, 시뮬레이션
2	요구사항 기준선	공식적으로 검토되고 합의된 요구사항 명세서	공식회의, 형상관리
3	요구사항 변경관리	요구사항 기준선을 기반으로 모든 변경을 공식적으로 통제하기 위한 기법	형상통제 위원회, 영향도 분석
4	요구사항 확인 및 검증	슷템이 이해관계자가 기대한 요구사항에 부합하는지 확인	확인 및 검증

 

  -요구사항 검증 방법

구분	유형	설명
정형 기술 검토	동료 검토 (Peer Review)	- 2~3명에서 진행하는 리뷰의 형태 - 요구사항 명세서 작성자가 설명, 이해관계자가 들으면서 결함을 발견하는 형태
	워크 스루 (Walk Through)	- 오류를 조기에 검출하는데 목적 - 회의 전에 자료를 배포해서 사전 검토한 후 짧은 시간동안 회의를 진행하는 형태
	인스펙션 (Inspection)	- 저작자 외의 다른 전문가 또는 팀이 검사하여 오류를 찾아내는 공식적 검토
프로토 타이핑 활용	- 개발할 시스템에 대해 주요 기능을 약식으로 개발하여 최종 사용자나 고객을 대상으로 시연하여 시스템 작동 모습을 경험하게 하고 요구사항 확인
테스트 케이스 활용	- 테스트케이스를 생성하여 추후 요구사항이 현실적으로 테스트 가능한지를 검토
CASE 도구 활용	- 구조화된 명세서에 대해서는 일관성 분석을 제공하는 CASE도구 사용가능 - 대규모 개발의 경우 다양한 이해관계자의 요구사항 명세서 검토가 필요하므로 형상 관리 수행이 가능한 CASE 도구 이용