1. Use Case Modeling
Use Case Diagram
Relationships
✓ Communication
- Actor와 Use Case간의 유일하게 허용되는 관계
✓ Generalization
- 부모/자식 관계와 유사
- 특정 요소가 일반 요소와 구조 및 동작을 공유
✓ Includes or uses
- 기본 Use Case 인스턴스가 다른 Use Case에 의해 지정된 동작을 포함할 때 사용
- Use Case 간 공통 동작을 모델링
✓ Extends
- 한 Use Case가 다른 Use Case에 기능을 추가하는 경우 사용
- 확장 Use Case는 시작 기본 Use Case의 활동을 계속합니다.
Use Case Scenarios
✓ Use Case는 추상적이고 일반적인 동작을 설명합니다
✓ Use Case는 특정 Actor가 특정 작업을 특정 값으로 수행할 때 발생하는 상황을 설명하지 않습니다
✓ 시나리오: 구체적인 실행 -> Use Case 인스턴스로도 표시됩니다
- 입력 및 출력 매개변수의 변동
- 이벤트 흐름의 변동
✓ 시나리오는 Use Case를 더 큰 요구사항 도출 컨텍스트로 옮깁니다
- 요구 사항 검증
- 주소되지 않은 비기능 요구 사항 확인 -> 성능과 사용성이 일반적
- 더 넓은 시스템 프로토타입 생성
- 테스트 케이스로 잘 흘러갑니다
- 성공 및 실패 시나리오 (주요 및 보조 Use Cas )
✓ 시나리오를 사용하여 Use Case를 구조화할 수 있습니다 -> 하향식 접근
✓ 시나리오 사용으로 모든 가능한 목표 달성 시도를 Use Case가 포괄하게 합니다.
Benefits of Use Case Modeling to Stakeholders
✓ Customers
고객 요구 사항, 시스템 범위, 일정 & 예산, 수용 기준
✓ Users
사용자 요구 사항, 사용자 상호 작용
✓ Project Managers
일정 & 예산, 타당성 & 위험 분석, 개발 진행 상황 추적
✓ System Architects
아키텍처 요구 사항, 기술 선택
✓ System Developers
설계 요구 사항, 시스템 문서화
✓ System Maintainers
시스템 수정 및 진화를 위한 지침
Stakeholder들이 시스템 개발 노력 초기부터 참여 필요.
문제점
✓ Use Case 모델링은 모든 것에 적합하지 않습니다
- 적절한 도구를 적절한 시간에 선택하기
- 자원, 이점, 필요성 간의 균형이 중요합니다
✓ Use Case 모델링을 평가할 때 고려해야 할 사항
- 중요한 품질 속성
- 시스템 및 인간 Actor 간의 균형 (시스템도 Actor가 될 수 있음)
- Use Case 개발 프로세스
- 완전성 대 사용 가능한 자원
Use Case 작성 시 피해야 할 상위 10가지 실수
10. 사용 시나리오 텍스트 대신 기능(구현) 요구 사항 작성하기 X
9. 속성과 메소드를 사용해 용도보다는 사용 방식 설명하기 X
8. 너무 간략하게 Use Case 작성하기 X
7. 사용자 인터페이스로부터 완전히 분리하기 X
6. 경계 객체에 대해 명확한 이름을 사용하지 않기 X
5. 사용자의 관점이 아닌 다른 관점에서 수동태로 작성하기 X
4. 사용자 상호 작용만 설명하고 시스템 응답 무시하기 X
3. 대체 행동계획에 대한 텍스트 생략하기 X
2. Use Case 내부에 초점을 맞추지 않고, 사전후 (전제) 또는 이후에 어떻게 발생하는지 (사후조건)에 집중하기 X
1. 포함(includes) 또는 확장(extends)을 사용할지를 결정하는데 한 달을 소비하는 것은 불필요한 시간 낭비 X
Business Modeling
✓ 비즈니스 이해하기
✓ "비즈니스 시스템" 이해하기
✓ 비즈니스 모델 개발하기
- 비즈니스 Use Case 모델
- 비즈니스 객체 모델
✓ 작업자, 엔티티, 작업 단위
Domain Modeling
✓ 비즈니스 모델의 특수한 경우
✓ 도메인 내의 구체적인 객체를 반영하는 공통 어휘집 생성
✓ 도움이 되는 도구
- 비즈니스 객체
- 현실 세계의 객체
- 이벤트
✓ 일반적으로 UML 클래스 다이어그램으로 표현됩니다.
✓ 때때로 용어 사전으로 대체됩니다.
Use Case Modeling Activities
✓ Use Case 모델링 준비하기(Prepare for use case modeling)
- Stakeholder 분석 수행
- Use Case 프레임워크 선택 및 사용자 정의
- 표준, 템플릿, 도구 선택하기
- 교육 및 멘토링 요구사항 결정하기
✓ 초기 Use Case 모델링 수행하기(Perform initial use case modeling)
- 컨텍스트 다이어그램 개발하기
- 주요 Actor 식별하기
- 개념적 시스템 Use Case 찾아내기 (goal을 바탕으로)
- 초기 Use Case 다이어그램 개발하기
- 개념적 비즈니스 객체 결정/정제하기
✓ 고급 Use Case 모델링 수행하기(Perform advanced use case modeling)
- 기본 Use Case 설명 개발하기
- 기본 Use Case 설명을 상세하게 표현하기
- 확장, 포함 및 일반화 관계 모델링하기
- Use Case를 객체 모델에 매핑하기
- 인스턴스 시나리오 개발하기
✓ 테스트 케이스 및 문서 작성하기(Create test cases and documen -tation)
- 테스트케이스는 인스턴스 시나리오를 바탕으로 제작
✓ Use Case 정리하기(Organize the use cases)
The Context
✓ 시스템의 구성 요소를 정의하는 것에 초점이 맞춰져 있고, 어떤 것이 시스템의 일부가 아닌지 파악해야 함
✓ 외부 엔티티는 후보 액터가 되며, 예를 들면
- 외부 엔티티가 부담할 역할과 책임
요구 사항 파악을 위한 유스케이스 사용(Requirement Capture via Use Cases)
✓ 하나의 유스케이스가 여러 요구 사항을 포함함
✓ 하나의 유스케이스는 많은 구체적인 상호작용과 행동을 포함할 수 있음
✓ 다양한 액터에 의해 시작된 하나의 유스케이스는 다른 이벤트를 트리거할 수 있음
✓ 일반적인 설명은 개요를 그릴 수 있지만, 요구 사항 수집은 대부분 인스턴스 시나리오에서 이루어짐
추가 기능 요구 사항(Extra Functional Requirements)
✓ Use Case는 저수준 시스템 요구 사항을 캡쳐하는 데 모호함이 있음
- …ilities -> 변경 가능성, 확장성, 사용성…
- 성능 ->보안, 용량, …
- 연관, 일반화, 계층 구조, 의존성
✓ 객체 모델링은 이러한 격차를 메우기 위한 방법으로 제안됨
- Use Case에 참여하는 후보 객체를 식별하고 "객체를 Use Case 모델링에서 객체 모델링" 반복 수행
- 제안되는 전형적인 경험에 의한 접근 방식
• 동사 -> Use Case
• 명사 -> 객체
초기 Use Case 모델링(Initial Use Case Modeling)
✓ 시스템의 개념적 이미지 포착 §Actor의 관점에 기반하여 Use Case 찾기
✓ Use Case가 어떤 Actor에게도 가치를 제공하지 않으면 제거할 후보가 될 수 있음
✓ 동일한 세분화 수준에서 Use Case 포착
✓ Actor와 다른 Stakeholder들과 함께 Use Case 및 해당 설명 확인
✓ 개념적 Use Case 설명을 찾고 확인하기 위해 워크숍을 진행할 수 있음 (교육 세션 -> 다중 워크숍 그룹 -> 리뷰 세션)
Use Case Modeling - Describing a Use Case
✓ 이벤트 흐름은 다음과 같이 설명됩니다:
- 자연어 사용
- "액션 순서" 접근법 사용
• 상호작용 다이어그램 및 객체 분해에 잘 매핑됨
- 상태 사용
• 여러 비선형 경로를 나타내기에 좋습니다 (상태 다이어그램)
✓ 블랙박스와 화이트박스 접근법
- 내부 시스템 세부 정보를 표현할지 여부
✓ 블랙박스의 장점들
- 기술적인 해결책을 가정하지 않음
- 사용자에 초점을 맞추어 Actor로부터 한 단계 더 나아감
✓ 화이트박스의 장점들
- 요구사항을 파악할 때 핵심적인 내부 세부 사항에 초점을 맞춤
- 기술적 측면에 대해 고민하기 시작함 -> 무엇이 희망 사항이고, 무엇이 실행 가능한 순서인지 판단할 수 있음
CRUD Matrix (Use Case Evaluation)
✓ Create, Read, Update and Delete use cases
✓ To map use cases to object models
✓ Example:Afinancial planner
Use Case에서 객체로(From Use Cases to Objects)
✓ 도메인 객체 모델링
- 도메인 또는 비즈니스 수준의 추상화
- 참여하는 모든 당사자들이 합의된 이해를 가지고 있어야 하는 시스템의 핵심 요소들을 결정
✓ 분석 객체 모델링
- 논리적 또는 요구 사항 수준의 추상화
- Use Case를 활용하여 시스템 수준의 객체를 추출
✓ 디자인 객체 모델링
- 분석 객체를 구현을 위한 디자인 객체에 매핑
Use Case Realizations
Test Cases
Test Case Design
Traceability via Use Cases
- Specification
- Architecture
- Design
- Implementation
- Testing
Relationship btw Use Case & System Views
Example – Use Case Model
Example – System-level Sequence Diagram
Example – System Context Model
Example – System Test Model (Template)
Example – Entity Class Diagram
Example – Object Interaction Mode
추적성 무시의 결과(Neglecting Traceability Results in)
✓ 수정으로 인한 비용과 시간 증가
✓ 지식의 손실
✓ 오해, 의사소통의 문제
✓ 전체 소프트웨어 개발 생명 주기에서 가장 간단한 부분이지만 매우 중요한 측면을 잃어버림!
예를 들어, 이 Use Case는 어디에서 나온 것인가?
✓ 그러나 이에 대한 대가가 있음
- 상당한 자원 할당이 필요함
2. QUALITY ATTRIBUTES
Critical Applications
✓ 오랜 생명 주기를 가짐
✓ 진화적 업그레이드가 필요함
✓ 지속적이거나 거의 중단 없이 작동해야 함
✓ 하드웨어 디바이스와 상호 작용해야 함
시기성, 신뢰성, 안전성, 상호 운용성 등의 품질 속성에 대한 중요도 할당하기
소프트웨어 품질 속성(Software Quality Attributes)
✓ 소프트웨어 품질: "소프트웨어가 원하는 속성 조합을 가지고 있는 정도(예: 신뢰성, 상호 운용성)"
✓ 품질 속성: 시스템이 사용자에게 제공하는 서비스의 특성
– 서비스: 사용자가 인식하는 시스템의 동작
– 사용자: 시스템과 상호 작용하는 다른 시스템(물리적 또는 인간적)
✓ 중요한 시스템의 속성
– 성능(Performance) : 하드 리얼타임 시스템과 용량 계획으로부터
– 신뢰성(Dependability): 매우 신뢰할 수 있고 내고장성 시스템으로부터
– 보안(Security) : 정부, 은행 및 학계에서 유래한 것
– 안전(Safety): 위험 분석 및 시스템 안전 공학으로부터
품질 속성 균형(Quality Attribute Trade-offs)
✓ 여러 (상반된) 품질 속성을 정량적으로 평가하고 균형을 잡습니다.
✓ 한 번에 여러 품질 속성을 고려하기 위해 단일하고 전체적인 메트릭을 찾아서는 안됩니다.
품질 속성 범주(Quality Attributes Taxonomy)
✓ 관심사(Concerns)
– 시스템의 속성을 판단, 명시 및 측정하는 매개변수
– 요구사항은 관심사로 표현됩니다.
✓ 속성별 요소(Attribute-specific factors)
– 시스템(시스템에 내장된 정책 및 메커니즘 등)과 해당 환경의 속성으로, 관심사에 영향을 미치는 요소
– 속성에 따라 속성별 요소는 관심사에 영향을 미치는 내부 또는 외부 속성입니다.
– 그러나 요소는 독립적이지 않으며, 원인/결과 관계를 가질 수 있습니다.
✓ 방법(Methods)
– 관심사를 어떻게 처리할 것인가: 시스템 개발 중 분석 및 종합 과정, 사용자 및 운영자에 대한 절차 및 교육
Performance
Performance : 시스템이나 구성 요소가 속도, 정확성 또는 메모리 사용량과 같은 주어진 제약 조건 내에서 지정된 기능을 수행하는 정도.
안정성(Dependability)
✓ "안정성은 컴퓨터 시스템의 속성으로, 제공하는 서비스에 정당한 신뢰성을 두는 것이다."
✓ 안정성(Dependability) attributes
– 가용성(Availability) : 사용 준비 (𝛂)
– 신뢰성(Reliability) : 서비스 연속성 (MTTF) ## 10page
– 안전(Safety) : 환경에 대한 재앙적 결과의 발생하지 않음
– 기밀성(Confidentiality) : 무단 정보 공개가 발생하지 않음
– 무결성(Integrity) : 정보에 대한 부적절한 변경이 발생하지 않음
– 유지보수성(Maintainability) : 수리 및 발전의 능력
Dependability Taxonomy
안정성에 영향을 주는 요인들(Impairments to Dependability)
- 시스템의 실패(Fails)는 그 시스템의 동작이 예상되었던 것과 다를 때 발생한다
- 오류(Error)는 수정되지 않으면 실패로 이어질 수 있는 시스템 상태이다.
- 결함(Fault)은 오류의 인정되거나 추정된 원인이다.
Dependability Methods
Security
✓ 위험으로부터의 자유; 안전
✓ 시스템 데이터를 공개, 수정 또는 파괴로부터 보호하기
✓ 컴퓨터 시스템 자체의 보호. 보호 수단은 기술적, 관리적으로 모두 가능함
✓ 특정 보안 정책이 일정한 수준의 확신을 바탕으로 강제되는 속성
✓ 종종 다중 레벨 보안의 경우에는 기밀성을 표시하는 제한된 의미로 사용됩니다.
Security Taxonomy
- 기밀성은 데이터와 프로세스가 무단 공개로부터 보호되어야 한다는 요구사항입니다.
- 무결성은 데이터와 프로세스가 무단 수정으로부터 보호되어야 한다는 요구사항입니다.
- 가용성은 데이터와 프로세스가 인가된 사용자에 대한 서비스 거부로부터 보호되어야 한다는 요구사항입니다.
Safety
✓ "안전은 컴퓨터 시스템의 속성으로, 사고 부재에 걸맞게 신뢰성을 둘 수 있는 것이다."
– 신뢰성은 내부적 결과(서비스가 제공되지 않음)로 정의되는 실패의 발생과 관련이 있다.
– 안전은 외부적 결과(사고 발생)로 정의되는 사고나 미스의 발생과 관련이 있다.
Safety Taxonomy
ISO/IEC 9126 Software engineering — Product quality
✓ 국제 표준 소프트웨어 품질 평가 기준 (1991년 12월)
– 품질 모델(Quality model )
– 내부 메트릭(Internal metrics)
– 외부 메트릭(External metrics)
– 사용 중 품질 메트(Quality in use metrics)
ISO/IEC 25010 SYSTEMS AND SOFTWARE ENGINEERING
✓ 시스템 및 소프트웨어 품질 요구사항 및 평가(SQuaRE) - 시스템 및 소프트웨어 품질 모델 (2011년 3월) SQuaRE는 시스템과 소프트웨어의 품질을
평가하고 요구사항을 정의하기 위한 국제 표준입니다. 이는 다양한 측정 항목과 품질 모델을 제공하여, 개발자와 시스템 엔지니어가 제품의 품질을 객관적으로 판단하고 개선할 수 있게 돕습니다.
ISO 25010 – Product Quality Model
✓ 컴퓨터 시스템의 정적 및 동적 특성을 중점으로 한 특성을 설명합니다.
– 기능 적합성: 완전성, 정확성, 적절성
– 성능 효율: 시간적 요소, 리소스 사용, 용량
– 호환성: 공존, 상호 운용성
– 사용성: 적절성, 학습성, 조작성, 오류 보호, 미적 감각, 접근성
– 신뢰성: 성숙도, 가용성, 내결함성
– 보안: 기밀성, 무결성, 진위성
– 유지보수성: 재사용성, 수정 가능성, 테스트 가능성
– 이식성: 적응성, 설치 용이성, 대체 가능성
ISO 25010 – Quality in Use Model
✓ 특정 맥락(예: 특정 플랫폼에서 사용할 때)에서 제품을 사용하는 것을 고려할 때 적절한 특성을 설명합니다.
- 효과성: 사용자가 목표를 정확하고 완전하게 달성하는 정도
- 효율성: 원하는 정확도로 사용자 목표를 완전하게 달성하기 위해 소비되는 자원
- 만족도: 유용성, 신뢰도, 쾌락, 편안함
- 리스크로부터의 자유: 경제적, 건강, 안전 및 환경적 위험 완화
- 맥락 포괄성: 완전성, 유연성
품질 속성 특성화(Quality Attribute Characterizations)
✓ 적절한 속성 관련 정보를 추출하기 위한 효율적인 질의 프레임워크
✓ 품질 속성 특성화의 카테고리
- 외부 자극: 아키텍처의 반응이나 변경을 일으키는 이벤트들
- 응답: 측정 가능하거나 관찰 가능한 수량
- 아키텍처 결정: 응답을 달성하는 데 직접 영향을 미치는 구성 요소, 커넥터 및 그들의 특성과 같은 아키텍처의 측면들
시나리오(Scenarios)
✓ 시나리오 : 이해 관계자 중 하나가 시스템과 상호 작용하는 것에 대한 짧은 설명
수정 가능성과 같은 불확실한 개발 시기의 품질 구체화
성능이나 가용성과 같은 실행 시기의 품질을 이해하는 데 유용
✓ 유지 관리자의 시나리오는 시스템에 변경을 수행하는 것에 대해 설명합니다(예: 운영 체제 업그레이드 또는 새 기능 추가).
✓ 개발자의 시나리오는 아키텍처를 사용하여 시스템을 구축하거나 성능을 예측하는 것에 대해 설명합니다.
✓ 고객의 시나리오는 제품 라인의 두 번째 제품에 대해서 아키텍처를 재사용하는 방법에 대해 설명합니다.
시나리오 유형(Types of Scenarios)
✓ 사용 사례 시나리오: 사용자가 완성된 실행 중인 시스템과의 상호 작용을 설명합니다.
예: "피크 시간에 웹을 통해 원격 사용자가 데이터베이스 보고서를 요청하고 5초 이내에 받습니다." (성능)
✓ 성장 시나리오: 시스템에 대한 예상되는 미래 변경을 나타냅니다.
예: "기존 데이터베이스 테이블의 크기를 두 배로 늘리면서 평균 검색 시간을 1초로 유지합니다."
✓ 탐색적 시나리오: 현재 디자인의 한계나 경계 조건을 보여 줍니다.
예: "5인월의 노력 이내에 새로운 3D 지도 기능과 지도를 볼 수 있는 가상 현실 인터페이스를 추가합니다."
Eliciting and Prioritizing Scenarios
Utility Tree Example
Architecture Tradeoff Analysis Method (ATAM)
✓ 품질 속성 요구 사항에 관련된 아키텍처 결정의 결과를 평가하는 방법
✓ 위험 식별 방법 - 복잡한 소프트웨어 집약 시스템의 아키텍처 내에서 잠재적 위험 영역을 감지하는 수단
- ATAM은 소프트웨어 개발 수명주기 초기에 수행될 수 있음
- 상대적으로 저렴하고 빠름 (아키텍처 설계 아티팩트를 평가하기 때문)
- ATAM은 아키텍처 명세의 세부 수준에 해당하는 분석을 생성 (측정 가능한 품질 속성을 분석하는 것이 아니라 추세를 식별함)
- ATAM을 통해 아키텍트가 속성이 아키텍처 설계 결정에 어떻게 영향을 받는지 알게 해줌
ATAM’s Goal
✓ 아키텍처에서 다음을 식별
- 위험(Risks): 이루어지지 않은 구조상 중요한 결정이거나 주어진 결과
- 감도 포인트(Sensitivity points): 아키텍처의 매개변수로서 어떤 측정 가능한 품질 속성 응답과 높은 상관 관계가 있는
- 트레이드오프 포인트(Tradeoff point): 품질 속성이 매개변수 변경에 따라 다르게 영향을 받는 경우, 둘 이상의 감도 포인트와 관련된 매개변수
기반 아키텍처 접근법(Architecture-based Approach)
✓ 소프트웨어 아키텍처는 프로젝트를 위한 청사진입니다.
✓ 품질 속성은 아키텍처 비전과 통합함으로써 성공적으로 달성할 수 있습니다.
✓ 소프트웨어 아키텍처는 대상 시스템에 대한 조기 분석을 위한 결과물을 제공합니다.
✓ 소프트웨어 아키텍처는 개발자들이 설계 위험을 조기에 파악하고 과정 초기부터 해결할 수 있도록 도움을 줍니다.
QAW 단계
1. QAW 설명 및 인사말
QAW 운영자들이 QAW의 동기 및 방법의 각 단계에 대해 설명합니다.
2. 사업/프로그램 설명
이해 관계자가 시스템의 사업 및/또는 프로그램 중심의 목표를 제시합니다.
3. 아키텍처 계획 설명
기술적인 이해 관계자가 시스템의 아키텍처 계획(예: 고수준 시스템 설명, 맥락 도면 등)을 제시합니다.
4. 아키텍처 드라이버 확인
운영자와 이해 관계자들이 시스템의 핵심 아키텍처 드라이버에 대한 합의에 이릅니다.
5. 시나리오 브레인스토밍
이해 관계자들이 시스템을 위한 실제 시나리오를 생성합니다.
시나리오는 관련 자극, 환경 조건, 그리고 반응으로 구성됩니다.
운영자가 4단계에서 확인한 아키텍처 드라이버를 각각 다루는 시나리오를 작성합니다.
6. 시나리오 통합
내용이 유사한 시나리오를 통합합니다.
7. 시나리오 우선 순위 정하기
이해 관계자들이 투표 과정을 통해 시나리오의 우선 순위를 결정합니다.
8. 시나리오 세부화
상위 4개 또는 5개 시나리오에 대해 다음 내용을 기술합니다:
- 시나리오에 영향을 주는 사업/프로그램 목표
- 시나리오와 관련된 적절한 품질 속성
3. Requirements Specification
Software Requirements Specification (SRS)
✓ 소프트웨어 요구 사항 문서
✓ 시스템 개발자가 구현해야 할 공식적인 설명
✓ 시스템의 사용자 요구 사항과 시스템 요구 사항의 자세한 명세를 포함
✓ 애자일 개발에서는 요구 사항들이 차례로 수집되고 구체화됨
✓ 시스템의 종류에 따라 요구 사항의 세부 정보 수준 선택 가능 (예: 중요 시스템의 경우 가장 상세한 요구 사항)
✓ 광범위한 목차 및 문서 색인을 포함해야 긴 SRS를 작성합니다.
IEEE-STD-830-1998
1.1 목적
- SRS의 목적을 설명
- SRS의 예정된 대상 독자 지정
1.2 범위
- 생성될 소프트웨어 제품을 이름으로 식별 (예: 호스트 DBMS)
- 소프트웨어 제품이 수행할 기능 및 필요한 경우 수행하지 않을 기능 설명
- 제시된 소프트웨어의 응용, 관련 이점, 목표 및 목표 설명
1.3 정의, 약어 및 축약어
1.4 참조 1.5 개요
- SRS에 포함된 나머지 내용 설명
- SRS가 어떻게 구성되어 있는지 설명
2.1 제품 관점
- 제품을 관련 제품과 비교하여 설명 (예: 독립적인 제품, 더 큰 시스템의 구성 요소)
- 관련 시스템의 요구 사항을 소프트웨어 기능과 연계
- 해당 시스템과 소프트웨어 간의 인터페이스 식별
- 더 큰 시스템의 주요 구성 요소, 상호 연결 및 외부 인터페이스를 보여주는 블록 다이어그램이 도움이 될 수 있음
2.1.1 시스템 인터페이스
- 각 시스템 인터페이스를 나열
- 시스템 요구 사항을 달성하기 위한 소프트웨어의 기능과 인터페이스 설명을 확인
2.1.2 사용자 인터페이스
- 각 인터페이스의 논리적 특성 - 예: 필요한 화면 형식, 페이지 또는 창 레이아웃
- 인터페이스 최적화 측면 - 해야 할 것과 하지 말아야 할 것의 목록 (예: 긴 또는 짧은 오류 메시지 선택)
2.1.3 하드웨어 인터페이스
- 소프트웨어 제품과 하드웨어 구성 요소 간의 각 인터페이스의 논리적 특성 (예: 포트 수, 명령어 집합 등)
- 지원할 기기, 지원 방법, 프로토콜
2.1.4 소프트웨어 인터페이스
- 다른 필수 소프트웨어 제품 사용 (예: 데이터 관리 시스템, 운영 체제 또는 수학 패키지)
- 다른 응용 시스템과의 인터페이스 (예: 미수금 시스템과 종합 원장 시스템 간의 연결)
- 각 필수 소프트웨어 제품의 정보 (이름, 기호, 사양 번호, 버전 번호, 출처)
- 인터페이스 설명 (인터페이스 소프트웨어의 목적 및 메시지 내용과 형식에 관한 인터페이스 정의)
2.1.5 통신 인터페이스
- 로컬 네트워크 프로토콜 등과 같은 통신에 대한 다양한 인터페이스
2.1.6 메모리 제약
- 주기억 장치 및 보조 기억 장치와 관련된 모든 적용 가능한 특성 및 한계
2.1.7 운영
- 사용자 조직의 다양한 작동 모드 (예: 사용자가 시작한 작업)
- 상호 작용하는 작업 기간과 무인 작동 기간 - 데이터 처리 지원 기능
- 백업 및 복구 작업
2.1.8 사이트 적응 요구사항
- 특정 사이트, 임무 또는 운영 모드에 특정한 데이터 또는 초기화 순서 (예: 격자 값, 안전 한계 등)
- 소프트웨어를 특정 설치에 적용하기 위해 수정해야 하는 기능
2.2 제품 기능
- 주요 기능 요약
- 기능은 고객이 이해하기 쉽도록 정리되어야 함
- 텍스트 또는 그래픽 방법을 사용해 다양한 기능과 그들 간의 관계를 표시할 수 있음
2.3 사용자 특성
- 제품의 예상 사용자의 일반적인 특성 (교육 수준, 경험 및 기술 전문성)
- 섹션 3에서 특정 요구 사항이 지정되는 이유
2.4 제약사항
- 규제 정책
- 하드웨어 제한 (예: 신호 타이밍 요구 사항) - 다른 애플리케이션과의 인터페이스
- 병렬 작업 - 감사 기능
- 제어 기능
- 고차 언어 요구 사항
- 신호 핸드셰이크 프로토콜 (예: XON-XOFF, ACK-NACK) - 신뢰성 요구 사항
- 응용 프로그램의 중요성
- 안전 및 보안 고려 사항
2.5 가정 및 종속성
- SRS에 기술된 요구사항에 영향을 주는 요인을 나열 (예: 운영 체제 변경)
3.1 외부 인터페이스 요구 사항
3.1.1 사용자 인터페이스
3.1.2 하드웨어 인터페이스
3.1.3 소프트웨어 인터페이스
3.1.4 통신 인터페이스
3.2 기능 요구 사항
3.2.1 사용자 클래스 1
3.2.1.1 기능 요구 사항 1.1 ...
3.2.1.n 기능 요구 사항 1.n
3.2.2 사용자 클래스 2 ...
3.2.m 사용자 클래스 m
3.2.m.1 기능 요구 사항 m.1 ...
3.2.m.n 기능 요구 사항 m.n
3.3 성능 요구 사항
3.4 설계 제약 사항
3.5 소프트웨어 시스템 특성
- 신뢰성
- 가용성
- 보안
- 유지 관리성
- 이식성
3.6 기타 요구 사항
- 시스템 모드
- 사용자 클래스
- 객체
- 기능
- 자극
- 응답
- 기능 계층 구조
IEEE Std 830-1998은 요구 사항 명세서의 품질을 8가지 속성으로 정의합니다.
✓ 정확성
✓ 모호하지 않음
✓ 완전성
✓ 일관성
✓ 중요도 및/또는 안정성에 따른 순위
✓ 검증 가능성
✓ 수정 가능성
✓ 추적 가능성
4. Managing Software Requirements
요구 사항 검증(Requirements Validation)
✓ 고객이 실제로 원하는 시스템을 정의하는지 확인하는 과정
✓ 수행해야 할 검사 유형:
- 타당성 검사 - 다른 이해당사자들이 필요로 하는 추가 또는 다른 기능 식별
- 일관성 검사 - 모순적인 제약 조건이나 동일한 시스템 기능의 다른 설명이 있는지 확인
- 완전성 검사 - 시스템 사용자가 의도한 기능과 제약 조건을 모두 정의하는 요구 사항이 요구 사항 문서에 포함되어 있는지 확인
- 현실성 검사 - 시스템 개발 예산 및 일정을 고려하여 요구 사항이 실제로 구현 가능한지 확인
- 검증 가능성 - 테스트 세트를 사용하여 요구 사항이 검증 가능한지 확인
요구 사항 검증 기법(Requirements Validation Techniques)
✓ 요구 사항 검토 - 검토자 팀이 체계적으로 요구 사항을 분석하여 오류와 불일치를 확인합니다.
✓ 프로토타이핑 - 실행 가능한 시스템 모델이 최종 사용자와 고객에게 보여져 실제 요구 사항을 충족하는지 확인합니다.
✓ 테스트 케이스 생성 - 테스트 설계가 어려울 경우 또는 불가능한 경우, 일반적으로 이는 요구 사항이 구현하기 어렵고 재고해야 함을 의미합니다.
요구 사항 관리(Requirements Management)
시스템 요구 사항 변경을 이해하고 통제하는 과정
개별 요구 사항을 추적하고 종속된 요구 사항 간의 연결을 유지
요구 사항 변경의 영향 평가
변경 제안 작성 및 시스템 요구 사항과 연결하는 공식적인 프로세스 설정
요구 사항 수집 과정에서 요구 사항 변경을 관리하는 방법 계획하기
요구 사항이 변경되는 이유(Why do requirements changes?)
✓ 외부 요인: 팀이 통제할 수 없는 요인
- 경제, 정부 규제, 시장 및 소비자 선호도의 변화로 인한 해결해야 할 문제의 변화
- 사용자가 원하는 것에 대한 인식 또는 사용자 자체가 변화하여 사용자의 생각이 변함
- 새로운 하드웨어, 소프트웨어 및 네트워킹 기술과 같은 외부 환경의 변화
- 새로운 시스템이 사용자의 작업 방식에 영향을 줌
✓ 내부 요인
- 요구 사항을 수집하기 위해 적절한 이해당사자에게 적절한 시기에 올바른 질문을 하지 못한 경우
- 요구 사항 변경을 관리하기 위한 현실적인 프로세스 적용 실패
요구 사항 변경 관리 프로세스(Process for Managing Requirements Changes)
1. 요구 사항 변경 관리 프로세스
2. 변화가 불가피한 것을 인식하고 계획하기
3. 요구 사항을 기준으로 삼기
4. 변화를 통제하기 위한 단일 채널 설정 - 영향을 파악하고 공식적인 결정을 내리기
5. 변화 관리 시스템을 사용하여 변경 사항을 추적하기
6. 계층적으로 변화를 관리하기
요구 사항 기준 설정(Baseline the Requirements)
✓ 기준(알려진 요구 사항) - 비전 문서, 소프트웨어 요구 사항 및 사용 사례 모델에 있는 아이템화된 요구 사항의 모음
✓ 새로운 요구 사항에 대한 요청은 기준과 비교하여
– 어디에 들어갈 것인지
– 다른 요구 사항과 충돌을 일으키는지 여부
✓ 변경 사항이 승인되면, 그 변경의 발전을 관리할 수 있습니다.
– 비전에서 소프트웨어 요구 사항으로
– 소프트웨어 요구 사항에서 적절한 기술 설계 문서 및 모델로, 그리고 코드 및 테스트 절차로
변경 요청 및 결함 추적 시스템(Change Request and Defect Tracking System)
✓ 변경 요청의 중앙 집중식 저장소
✓ 웹 기반 항목 입력: 물리적 위치와 관계없이 가능
✓ 자동 상태 추적 및 추세 분석 기능
✓ 제어되지 않은 변경 방지를 위한 방화벽
✓ 영향을 받는 당사자에 대한 자동 알림 기능
변경 관리 위원회(Change Control Board (CCB))
✓ 변경 정보를 다음 사항을 고려하고 결정을 내리는 변경 관리 위원회에 전송합니다:
- 변경이 비용과 기능에 미치는 영향
- 변경이 고객 및 다른 외부 이해 관계자에게 미치는 영향
- 변경이 시스템을 불안정하게 만들 가능성 the change to destabilize the system
파장 효과(Ripple Effects)
✓ 한 요구 사항의 변경은 다른 관련 요구 사항, 설계 또는 다른 하위 시스템에 파장 효과를 줄 수 있습니다.
✓ 명시적인 프로세스가 없으면 변경이 대개 코드에서 직접 "하향식"으로 발생합니다.
- "역행" 파장 효과 일으키기 - 코드 변경 -> 설계 수준 변경 -> 요구 사항 변화 -> 비전에 미치는 영향
- 각 문서가 모두 통제 아래에 있으면 역행 파장 효과를 관리할 수 있습니다.
- 프로그래머는 실제로 코드에 직접 새로운 기능과 요구 사항을 도입할 권한이 없습니다.
✓ 모든 새로운 기능/요구 사항은 프로젝트와 관련된 비용, 일정, 신뢰성 및 위험에 영향을 줍니다.
계층적 변화 관리(Manage Change Hierarchy)
✓ 이 파장 효과를 완화하기 위해 요구 사항 변경은 하향식 계층 방식으로 수행되어야 합니다.
- 기준 비전 문서에 대한 변경 사항을 별도의 "델타" 문서에 기록할 수 있습니다.
- 새로운 기준 요구 사항 세트를 재생성합니다.
- 추적 가능성 링크를 따라서 설계, 코드 및 테스트 계획을 적절하게 변경합니다.
요구 사항 구성 관리(Requirements Configuration Management)
✓ 요구 사항에 대한 무단 및 잠재적으로 파괴적인 변경 방지
✓ 요구 사항의 수정 사항을 보존
✓ 이전 버전의 검색 및/또는 재구성을 용이하게 함 ("롤백" 기능)
✓ 시스템에 대한 점진적 개선이나 업데이트를 위한 조직적 기준 "릴리스 전략"을 관리 지원
✓ 동시 업데이트 또는 충돌하거나 조정되지 않은 업데이트를 방지
변경 이력(Change History)
✓ 각 요구 사항에 대한 변경 사항을 유지합니다.
✓ 요구 사항의 현재 상태를 포착하며, 요구 사항의 모든 속성의 현재 값을 포함합니다.
✓ 요구 사항의 이전 변경 사항에 대한 연대기를 제공합니다.
✓ 도구가 필요합니다.
- 요구 사항 텍스트와 속성 값의 모든 변경 사항을 자동으로 감지하고 포착하는 것
- 변경의 저자와 변경 날짜 및 시간을 기록하는 것
- 변경의 연대기와 변경 저자를 표시하는 것
- 변경 설명을 입력하여 변경 사항을 문서로 만드는 것 (변경이 이루어진 이유를 설명하는 한 두 문장, 변경과 관련된 프로젝트 메모를 참조하는 등)
요구공학(Requirements Engineering) 1
1. Introduction to Requirements Engineering Our Goal Customer Needs -> Software Design 요구 사항이란 무엇인가요? ✓ 시스템에 의해 충족되거나 제공되어야 하는 특성이나 서비스입니다. ✓ "사용자가 문제를 해결
bestinvestments.tistory.com
댓글