[ 정보처리기사 ] 소프트웨어 설계 - 요구 사항
작성일 21-02-01 17:39
페이지 정보
작성자 웹지기 조회 4,088회 댓글 0건본문
❖ 요구사항의 개념 및 특징
• 제공하는 서비스에 대한 설명
• 정상적인 운영에 필요한 제약조건 등
❖ 요구사항의 유형
기능 요구사항(Functional requirements)
• 시스템이 무엇을 하는지에 대한 사항
• 시스템이 어떤 기능을 하는지에 대한 사항
• 시스템의 입력이나 출력으로 무엇이 포함되어야 하는지, 시스템이 어떤 데이터를 저장
하거나 연산을 수행해야 하는지에 대한 사항
• 시스템이 반드시 수행해야 하는 기능
• 사용자가 시스템을 통해 제공받기를 원하는 기능
비기능 요구사항(Non-functional requirements)
• 시스템 장비 구성 요구사항
• 성능 요구사항
• 인터페이스 요구사항
• 데이터 요구사항
• 테스트 요구사항
• 보안 요구사항
• 품질 요구사항
• 제약사항
• 프로젝트 관리 요구사항
• 프로젝트 지원 요구사항
❖ 요구사항의 유형
사용자 요구사항(User requirements)
• 사용자 관점에서 본 시스템이 제공해야 할 요구사항
• 사용자를 위한 것으로 친숙한 표현으로 이해하기 쉽게 작성됨
시스템 요구사항(System requirements)
• 개발자 관점에서 본 시스템 전체가 사용자와 다른 시스템에 제공해야 할 요구사항
• 사용자 요구사항에 비해 전문적이고 기술적인 용어로 표현됨
• 소프트웨어 요구사항이라고도 함
❖ 요구사항 개발 프로세스
도출(Elicitation)
• 소프트웨어 개발 생명 주기동안 지속적으로 반복
• 기법 : 인터뷰, 설문, 브레인스토밍, 워크샵, 프로토타이핑, 유스케이스 등
분석(Analysis)
• 요구사항들을 토대로 소프트웨어의 범위 파악
• 소프트웨어와 주변 환경이 상호 작용하는 방법 이해
명세(Specification)
• 기능 요구사항은 빠짐없이 완전하고 명확하게 기술
• 비기능 요구사항은 필요한 것만 명확하게 기술
확인(Validation)
• 명세서의 내용이 이해하기 쉬운지, 일관성은 있는지,
회사의 기준에는 맞는지, 누락된 기능 없이 완전한지
여부 등을 검증(Verification)하는 것이 중요
❖ 요구공학(Requirements Engineering)
요구사항 변경의 원인과 처리 방법을 이해하고
요구사항 관리 프로세스의 품질을 개선하여
소프트웨어 프로젝트 실패를 최소화하는 것이 목표
❖ 소프트웨어 요구사항 명세서
1. 소개
1.1 목적
1.2 문서 규칙
1.3 프로젝트 범위
1.4 참조
2. 전반적인 설명
2.1 제품 관점
2.2 사용자 클래스 및 특징
2.3 운영환경
2.4 설계 및 구현 제약 조건
2.5 가정 및 의존성
3. 시스템 기능
3.1 시스템 기능
3.1.1 설명
3.1.2 기능적 요구 사항
4. 데이터 요구 사항
4.1 논리 데이터 모델
4.2 데이터 사전
4.3 보고서
4.4 데이터 수집, 무결성, 보존 및 폐기
5. 외부 인터페이스 요구 사항
5.1 사용자 인터페이스
5.2 소프트웨어 인터페이스
5.3 하드웨어 인터페이스
5.4 통신 인터페이스
6. 품질 속성
6.1 사용성
6.2 성능
6.3 보안
6.4 안전
6.X 기타
7. 국제화 및 현지화 요구
8. 기타 요구 사항
부록 A : 용어 사전
부록 B : 분석 모델
❖ 요구사항 분석 기법
• 개발 대상에 대한 사용자의 요구사항 중 명확하지 않거나 모호한 부분을 걸러내기 위한 방법
• 종류 : 요구사항 분류, 개념 모델링, 요구사항 할당, 요구사항 협상, 정형 분석
❖ 요구사항 기법
1)요구사항 분류(Requirement Classification)
•기능 요구사항과 비기능 요구사항으로 분류
•하나 이상의 상위 요구사항에서 유도된 것인지
또는 이해관계자나 다른 원천(Source)으로부터
직접 발생한 것인지 분류
•개발할 제품에 관한 것인지 개발 과정에 관한
것인지 분류
•우선순위에 따라 분류
•소프트웨어에 미치는 영향의 범위에 따라 분류
•소프트웨어 생명 주기 동안에 변경될 가능성이
있는지 여부에 따라 분류
2)개념 모델링(Conceptual Modeling)
•개념 모델은 문제의 주체인 개체(Entity)들과
그들 간의 관계 및 종속성 반영
•요구사항을 이해하는 이해관계자별로 관점이
다양하므로 그에 맞게 개념 모델도 다양하게
표현되어야 함
•종류 : 유스케이스 다이어그램(Use Case Diagram),
데이터 흐름 모델(Data Flow Model),
상태 모델(State Model),
목표기반 모델(Goal-Based Model),
사용자 인터액션(User Interactions),
객체 모델(Object Model),
데이터 모델(Data Model) 등
• 모델링 표기 : UML(Unified Modeling Language)
3)요구사항 할당(Requirement Allocation)
•식별된 구성 요소들 간에 어떻게 작용하는지
분석하는 과정에서 추가적인 요구사항이 발견
될 수 있음
4)요구사항 협상(Requirement Negotiation)
•요구사항이 서로 충돌되는 경우 어느 한 쪽으로
맞추기보다는 적절한 기준점을 찾아 합의해야 함
•요구사항이 서로 충돌되는 경우에 각각에 우선
순위를 부여하면, 무엇이 더 중요한지를 인식할
수 있으므로 문제 해결에 도움이 될 수 있음
5)정형 분석(Formal Analysis)
•구문(Syntax)과 의미(Semantics)를 갖는
정형화된 언어를 이용해 요구사항을 수학적
기호로 표현한 후 이를 분석 과정
• 정형 분석(Formal Analysis)은 요구사항
분석의 마지막 단계에서 이루어짐
❖ 요구사항 확인
• 문서화된 요구사항 관련 내용을 확인하고 검증
• 요구사항 관리 도구를 이용해 형상 관리 수행
• 기법 : 요구사항 검토(Requirement Reviews),
프로토타이핑(Prototyping),
모델 검증(Model Verification),
인수 테스트(Acceptance Tests) 등
❖ 요구사항 검토
• 요구사항 검토자 그룹을 구성할 때는 구성 방법이 중요
• 검토는 시스템 정의서(System Definition Document),
시스템 사양서(System Specification),
소프트웨어 요구사항 명세서
(SRS; Software Requirements Specification Document)를
완성한 시점 등에서 이루어짐
❖ 프로토타이핑
• 상품이나 서비스가 출시되기 전에 개발 대상 시스템 또는 그 일부분을
개략적으로 만든 원형
장점
피드백 반영이 수월
사용자, 개발자 사이의 의사소통 원활
시스템 문제점을 사전에 식별
단점
핵심을 벗어난 프로토타입 제작에 집중될 가능성
사용성이 과대평가될 가능성
프로토타입 개선으로 비용 부담
❖ 모델 검증
• 요구사항 분석 단계에서 개발된 모델이 요구사항을 충족시키는지 검증하는 것
• 정적 분석(Static Analysis) 수행
- 실행을 통한 확인(동적 분석)이 아니라
- 명세서의 정확성, 일관성 등을 확인, 분석 도구를 사용해 확인
❖ 인수 테스트
• 사용자 입장에서 확인하는 과정
사용자 인수 테스트 - 사용자가 시스템 사용의 적절성 여부 확인
운영상의 인수 테스트 - 시스템 관리자가 시스템 인수 시 수행
백업/복원, 재난 복구, 사용자 관리, 유지보수,
보안 취약성에 대한 정기 점검 과련 기능 등 확인
계약 인수 테스트 - 계약상의 인수/검수 조건을 준수하는지 여부 확인
규정 인수 테스트 - 정부 지침, 법규, 규정 등 규정에 맞게 개발하였는지 확인
알파 검사 - 실제 사용자가 개발 장소, 개발자 앞에서 수행하는 검사 기법
통제된 환경에서 행해지며, 오류와 사용상의 문제점을 사용자와 개발자가 함께 확인하면서 기록
베타 검사 - 최종 사용자가 여러 명의 사용자 앞에서 행하는 검사 기법
추천0
비추천 0
댓글목록
등록된 댓글이 없습니다.