05. 소프트웨어 시스템 기능/비기능 요구사항 명지대학교 융합소프트웨어학부 김정호 교수.

Presentation on theme: "05. 소프트웨어 시스템 기능/비기능 요구사항 명지대학교 융합소프트웨어학부 김정호 교수."— Presentation transcript:

1 05. 소프트웨어 시스템 기능/비기능 요구사항 명지대학교 융합소프트웨어학부 김정호 교수

2 Retrospect 소프트웨어 아키텍처 소프트웨어 아키텍처 필요성 시스템 컨택스트 다이어그램 소프트웨어 시스템의 구조
구조는 요소간의 연결이다. 즉, 시스템의 목적을 달성하는 요소들간의 관계를 나타내는 것이다. 소프트웨어 아키텍처 필요성 시스템이 크고 복잡하다. 다양한 이해관계자의 니즈가 존재한다. 시스템 컨택스트 다이어그램 시스템의 의미를 파악하는데 좋다. 시스템을 블랙박스로 두고 주변에 연동하는 객체를 표현한다.

3 목 차 시스템 요구사항 제약 사항 (비기능 요구사항) 품질 요구사항 (비기능 요구사항) 기능 요구사항 비기능 요구사항
유스케이스 다이어그램 소개 유스케이스 시나리오 작성 제약 사항 (비기능 요구사항) 기술적 제약 사항 조직적 제약 사항 비즈니스 제약 사항 품질 요구사항 (비기능 요구사항) 품질 속성의 분류 ISO/IEC 품질모델 품질 시나리오 작성

4 시스템 요구사항 기능 요구사항(Functional Requirements)
비기능 요구사항(Non-Functional Requirements) * Reperenced by Sungwon Choi, Myoungji Univ.

5 기능 vs. 비기능 요구사항 기능 요구사항 비기능 요구사항
기능(Function)이란 입력(Input)을 받아들여, 정의된 규칙(Rule)에 의해 입력을 변형하여 출력(Output)을 만들어 내는 것 예를 들어 증권시스템의 기능 들은 고객의 정보를 등록하고, 주식을 거래하고, 예수금을 관리한다 비기능 요구사항 사용자의 요구사항 중 기능적이지 않은 부분을 의미한다. 시스템 제약사항 및 품질 속성이 이에 속한다. ‘개발 비용이 저렴하여야 한다’, ‘사용하기 쉬워야 한다(Usability)’, ‘빠르게 반응하여야 한다(Performance)’, ‘문제가 생겨도 즉각 복구되어야 한다(Reliability)’ 등 시스템은 사용자의 요구사항을 수행한다. 다양한 요구사항이 존재하지만, 가장 기본적으로 시스템은 기능을 수행하여야 한다. 기능(Function)이란 입력(Input)을 받아들여, 정의된 규칙(Rule)에 의해 입력을 변형하여 출력(Output)을 만들어 내는 것을 말한다. 예를 들어 증권시스템의 기능 들은 고객의 정보를 등록하고, 주식을 거래하고, 예수금을 관리한다 등이다. 시스템에 대한 요구사항은 단지 기능들에 국한 되지 않는다. ‘개발 비용이 저렴하여야 한다’, ‘사용하기 쉬워야 한다(Usability)’, ‘빠르게 반응하여야 한다(Performance)’, ‘문제가 생겨도 즉각 복구되어야 한다(Reliability)’ 등 기능 이외의 많은 부분 들도 포함한다. 사용자의 요구사항 중 기능적이지 않은 부분을 비기능적 요구사항이라 한다. 기능성은 입력을 출력으로 변형하는 것을 말하는 반면, 비기능성은 변형의 방법에 관한 제약조건을 말한다. 한 학급의 평균을 산출의 예를 들면, 비기능성은 빠르게, 안전하게, 편리하게 등 평균을 산출하는 시스템의 행위를 제약한다. 시스템이 정의된 제약조건을 만족하는 정도를 품질이라 한다. 따라서 비기능성, 품질 및 제약조건은 시점에 따라 다르게 표현되지만 같은 의미로 쓰일 수 있다. 비기능성은 기능성에 비해 모호성(Ambiguity)이 높으므로, 요구사항 정의에 있어 주의가 요구된다. * Reperenced by Sungwon Choi, Myoungji Univ.

6 소프트웨어 아키텍처 결정 요인 아키텍처를 작성할 때 발생할 수 있는 결정 요인 기능 요구사항 제약 사항 (비기능 요구사항)
소프트웨어 아키텍처 결정 요인 아키텍처를 작성할 때 발생할 수 있는 결정 요인 기능 요구사항 시스템이 반드시 수행해야 되는 기능들 제약 사항 (비기능 요구사항) 소프트웨어 개발 시, 이미 결정된 사항들 Ex) 기간, 비용, COTS, etc. 품질 속성 (비기능 요구사항) 소프트웨어 개발할 때 요구되는 품질 속성들 Ex) 가용성(Availability), 성능, 보안, 유지보수성, etc. 소프트웨어 아키텍처 기능 요구사항 품질 속성 제약 사항

7 소프트웨어 아키텍처 결정 요인 아키텍처를 작성할 때 가장 중요한 것은? Terminal Host 호스트 구조

8 소프트웨어 아키텍처 결정 요인 아키텍처를 작성할 때 가장 중요한 것은 ? Server Client
소프트웨어 아키텍처 결정 요인 아키텍처를 작성할 때 가장 중요한 것은 ? Server Client Client – Server 구조

9 소프트웨어 아키텍처 결정 요인 아키텍처를 작성할 때 가장 중요한 것은 ? Middleware DBMS Client
소프트웨어 아키텍처 결정 요인 아키텍처를 작성할 때 가장 중요한 것은 ? Middleware DBMS Client 3-tier 구조

10 소프트웨어 아키텍처 결정 요인 아키텍처를 작성할 때 가장 중요한 것은 ? Thin Client Presentation
소프트웨어 아키텍처 결정 요인 아키텍처를 작성할 때 가장 중요한 것은 ? Thin Client Presentation Middleware DBMS 4-tier 구조

11 소프트웨어 아키텍처 결정 요인 아키텍처를 작성할 때 가장 중요한 것은 ? 품질 속성(Quality)

12 소프트웨어 아키텍처 결정 요인 기능과 품질은 상호 독립적(orthogonal)이다.
소프트웨어 아키텍처 결정 요인 기능과 품질은 상호 독립적(orthogonal)이다. 두개의 다른 시스템에 같은 기능을 구현할 수 있다. 두개의 시스템이 서로 다른 구조를 가지고 있는 것은 품질 속성이 다르기 때문이다. Example> 포탈의 communication channel과 우주 왕복선의 communication channel 아키텍처 구성은 특정한 품질을 높이지만 특정 품질에는 안 좋을 수 있다. 미들웨어를 두는 것은 유지보수에 도움은 되지만 성능을 오히려 저해한다. 이것을 아키텍처 Tradeoff라고 한다. 품질 속성은 반드시 초기 설계에 반영이 되어야 한다. 기능 요구사항을 만족시키는 개발을 한 후에 품질을 더 한다?

13 기능 요구사항 - 유스케이스 유스케이스 분석 기법 사용자 중심 요구사항 모델링 유즈케이스는 각각 독립적
유즈케이스와 액터 간 상호작용을 통해 시스템 분석 사용자 비즈니스와 애플리케이션 영역을 이해 작업 중심적 : Diagram 으로 요구사항 이해 유즈케이스는 각각 독립적 High Priority Use Case = High Priority Requirements 단순한 유즈케이스 나열 : 전체적인 시스템 요구사항 이해 어려움 비기능적인 요구사항은 표현이 어려움 표준 Graphic 표기 Communication 개선, 해석의 Risk 감소

14 기능 요구사항 – 유스케이스 다이어그램 ATM 시스템 예제

15 기능 요구사항 – 유스케이스 시나리오 1. UC_0001: Withdraw cash
1.1 설명고객이 ATM으로부터 자신의 계좌에 입금되어 있는 돈을 출금한다. 1.2이벤트흐름 1.2.1 기본흐름 1. ATM은 고객의 유효성을 확인하기 위해 ‘Check Validity’ 유스케이스를 포함한다. 2. ATM은 사용자에게 인출금액 입력화면을 출력한다. 3. 사용자는 ATM에 인출금액을 입력한다. 4. ATM은 카드를 꺼내어 사용자에게 돌려준다. 5. ATM은 사용자에게 영수증을 발급여부를 물어본다. 6. ATM은 사용자에게 영수증을 발급하여 준다. 7. ATM은 사용자에게 돈을 지급한다. 8. ATM은 초기화면으로 돌아간다. 1.2.2 대안흐름 1.2.3 예외흐름 1.3 조건 1.3.1 선행 조건 1.3.2 후행 조건 1.4 기타

16 제약 사항 비즈니스 제약 사항 기술적 제약 사항 조직적 제약 사항
법률적인 제약 (ex. 개인의 위치를 찾을 경우 반드시 피 위치 추적자의 동의를 사전에 얻어야 한다.) 회사 사규 (ex. 모든 회사 임직원은 자동으로 임직원 시스템에 등록된다.) 비즈니스 목표 (ex. 급변하는 시장에 적응하기 위해 서비스 정보를 임원들에게 주기적으로 보고해야 한다.) … 기술적 제약 사항 Compatibility (ex. Windows OS와 Linux에 모두 porting이 되어야 한다.) Conformance GUI Style (ex. 회사 표준으로 사용하는 GUI Style을 따라야 한다.) 특정 아키텍처 사용 (ex. J2EE 아키텍처를 표준으로 도입한다.) 특정 언어 사용 (ex. 모든 개발 언어는 시스템 portability가 좋은 Java를 사용한다.) 특정 국제 표준 사용 (ex. web service의 기능을 이용한다.) H/W, S/W reuse (ex. 기존 시스템의 재활용 측면에서 아래와 같은 H/W, S/W를 개발에 사용한다.) 조직적 제약 사항 시간 (ex. 본 프로젝트는 2007년 2월 1차 오픈, 2007년 8월 최종 오픈으로 한다.) 비용 (ex. 본 프로젝트는 인건비용과 H/W, S/W 구입 비용을 포함하여 총 xxx를 SKC&C에 지급한다.) 인력 (ex. SOA 전문 인력을 2명 확보해야 하나 1명만 확보되어 시스템 디자인에 투입한다.)

17 품질 속성의 분류 사용자 관점 개발자 관점 사용성 (Usability) 성능 (Performance)
= 효율성 (Efficiency) 신뢰성 (Reliability) 가용성 (Avalability) 안전성 (Safety) 확장성 (Scalability) 유지보수성 (Maintainability) 재사용성 (Reusability) 변경용이성 (modifiability) 이식성 (Portability) 확장개발성(Extendibility) 구축가능성(Buildability) 시험용이성 (Testability)

18 품질 속성 모델 – ISO/IEC 25010 Functional Suitability Performance Efficiency
Functional Completeness Functional Correctness Functional Appropriateness Performance Efficiency Time-Behavior Resource Utilization Capacity Compatibility Co-existence Interoperability Usability Appropriateness Recognisability Learnability Operability User Error Protection User Interface Aesthetics Accessibility Reliability Maturity Availability Fault Tolerance Recoverability Security Confidentiality Integrity Non-Reproduction Accountability Authenticity Maintain-ability Modularity Reusability Analyzability Modifiability Testability Portability Adaptability Installability Replaceability

19 품질 속성 시나리오 품질 속성 시나리오 Stimulus – 시스템에 적용되는 조건들
Response – Stimulus 결과 반영되는 결과들 Source of the stimulus – Stimulus를 발생하는 원인 Environment – Stimulus가 발생할 때 연계되는 외부 조건들 Artifact stimulated – Stimulus에 의해 영향 받는 산출물들 Response measure – System에 반영되는 결과를 수치화 하는 지표

20 품질 속성 시나리오 - 예제 가용성 일반 시나리오 대상(Artifact) : 프로세스 자극 : 예기치 못한 메시지 응답 :
운영자에 통지 후 계속 수행 환경 : 정상 오퍼레이션 응답 측정 : 정지 시간 없음 자극의 원천: 외부에서 시스템

21 품질 속성 시나리오 - 예제 변경용이성 일반 시나리오 대상(Artifact) : 코드 자극의 원천: 개발자 환경 : 설계 시점
응답 측정 : 세 시간 자극 : UI 변경 원함 응답 : 변경으로 인한 부작용은 없음

22 품질 속성 시나리오 - 예제 성능 일반 시나리오 대상(Artifact) : 시스템 자극의 근원 : 사용자 환경 :
정상 오퍼레이션 응답 측정 : 평균 2초 대기시간 자극 : 트랜잭션 초기화 응답 : 트랜잭션이 처리됨

23 품질 속성 시나리오 보안 일반 시나리오 대상(Artifact) : 시스템의 데이터 자극의 근원 : 제대로 식별된 개인 환경 :
정상 운영 자극 : 정보변경시도 응답 : 감사 기록유지 응답 측정 : 하루 이내 올바른 데이터 재저장

24 품질 속성 시나리오 사용성 일반 시나리오 대상(Artifact) : 시스템 자극의 근원 : 사용자 환경 : 실행 시
응답 측정 : 취소는 1초 이내 이루어짐 자극 : 에러의 영향을 최소화하고자 함 응답 : 현재 오퍼레이션을 취소하고자 함

25 품질 속성 시나리오 - 예제 품질 속성 도출, 시나리오 작성 및 순위 결정 품질 요구사항명 요구사항 설명 난이도 중요도 확장성
신규 서비스 추가의 용이성 시스템 개발자가 신규 상품을 시스템에 적용하려 할 때, 기존 상품의 변동 없이 신규 상품(Universal 보험 상품 등은 제외)은 4일 이내, 유사 상품은 4시간 이내에 기간 시스템 및 SFA에 launch해야 한다. (테스트 시간은 제외) 상 성능 Latency 서비스 사용자가 서비스를 사용하려 할 때, 단순한 조회일 경우, 평균 3초 이내(NSP 프로젝트의 범위내 기준으로, 최대 10초 이내), 온라인 통계자료 조회일 경우는 평균 10초(최대 30초) 이내로 처리해야 한다. (예외 특이건에 대하여는 해당시점에 협의하여 성능목표를 정함) 정보 제공성 일마감 지원 서비스 관리자가 일마감 정보를 원할 경우 특정 시간(예: 자정)이후에 일마감 정보 실시간으로 제공해야 한다. 중 월마감 지원 서비스 관리자가 월마감 정보를 원할 경우 수납 마감일 이후 3일 이내에 월마감 정보 제공해야 한다. 실시간성 실시간 처리 정보계 시스템은5분 주기로 정보를 수집해야 한다. 하

26 요구사항 기술서 - 주의사항 읽고 이해하기 쉬운 표현 사용 명확한 표현을 사용 긍정적인 표현을 사용한다.
부정적인 요구사항은 긍정의 의미로 표현한다. 다중부정표현을 피한다. 능동적인 표현을 한다. 요구사항에 충분한 정보를 제공한다. 생략할 것은 과감히 생략한다. Model을 포함하여 설명한다. 명확한 표현을 사용 모호한, 다중의미를 가지는 용어를 피한다. usually, generally, often, normally, typically, user friendly, efficient, flexible, maximize, minimize, improved, easy, simple 일관성있는 용어를 사용한다. Glossary 기술: 조직, 도메인의 표준용어사용

27 Question ?