Software Requirements
이 포스트에서는 Software의 Requirements에 대해 집중적으로 다룬다.
Software Requirements
(Recap) FURPS+ 모델
| 분류 | 설명 |
|---|---|
| F (Functional) | 시스템이 해야 할 기능 및 동작 |
| U (Usability) | 사용성, 문서, 도움말 등 |
| R (Reliability) | 신뢰성, 고장률, 복구 가능성 |
| P (Performance) | 반응속도, 처리량, 정확도, 가용성 |
| S (Supportability) | 유지보수성, 포터블성, 설정 가능성 |
| + (Constraints) | 하드웨어/소프트웨어 제약, 법적 요구사항 등 |
Functional Reqs (FR)
-
FURPS+ 에서 F 에 해당
- 기능이나 시스템 서비스에 대한 설명
- 특정 입력/상황에 대한 시스템의 동작을 명세한 것으로 ‘무엇응ㄹ 해야 하는가’를 중심으로 서술
Non-Functional Reqs (NFR)
- FURPS+ 에서 URPS 와 + 에 해당
- 시스템의 품질이나 제약 조건 설명
NFR을 유도하거나 제한할 수 있음.
예시 )
- performance requirements -> components간의 연결 최소화하는 시스템 구성
- security requirements
- 종류
- Quality Attributes : URPS
- Constraints : + (OS, hardware, development languages, etc )
NFR 분류
- Product requirements (제품 요구사항)
소프트웨어 제품 그 자체의 성능이나 품질에 관한 요구사항
- 소프트웨어가 직접적으로 만족시켜야 할 기술적 요건
- 주로 사용자 경험이나 성능과 관련 있음.
- 예시 ) 실행 속도, 가용성, 정확도
- Organizational requirements (조직 요구사항)
소프트웨어 개발 과정에서 조직 내부 정책이나 기준을 따르기 위한 요구사항
- 개발 조직이 자체적으로 정한 규칙이나 절차에 관련
-
표준화, 보안 정책, 개발 방식 등에 영향을 줌
- 예시) 인증방식, 표준 준수
- External requirements (외부 요구사항)
법률, 규제, 외부 기관 등에서 요구하는 강제적인 조건
- 외부 환경에서 오는 요구
- 반드시 따라야 하며, 법적 책임이 따름.
- 예시) 법적 요건, 규제사항
Verifiable Reqs
FR과 NFR의 좋은 요구사항 조건.
- 해당 요구사항이 테스트나 측정을 통해 충족 여부를 확인할 수 있는가 에 초점
-
테스트, 관찰, 측정, 시뮬레이션 등을 통해 충족 여부를 명확히 판단할 수 있는 요구사항
- 사용 이유
- 검증이 안 되는 요구사항은 애매하고 해석이 달라져서 개발자, 테스트 엔지니어, 고객 간 오해 발생 가능성이 큼.
- 명확하고 구체적인 요구사항은 테스트 케이스 작성과 QA 활동 에도 직접적으로 도용됨.
- 측정 항목
| 측정 항목 | 예시 |
|---|---|
| Speed | 응답시간, 초당 처리량 |
| Usability | 교육 시간, 오류율 |
| Reliability | 평균 고장 간격(MTTF), 오류 발생률 |
| Robustness | 장애 발생 후 복구 시간 |
| Portability | 이식성 비율 |
→ “모호한 표현” 대신 정량적 지표 사용 필요
Use Case
사용자(Actor)와 시스템 사이의 상호작용(interaction)을 시나리오 형태로 작성한 것
주로 external behavior에 초점
- 시나리오(Scenario)
- Main Success Scenario : 사용자가 시스템을 정상적으로 사용했을 때의 이상적인 흐름
- Alternate Scenario : 정상 흐름이 아닌, 특정 조건에서 달라지는 흐름이나 예외 사항 (예외처리)
- 즉, UC는 많은 시나리오들을 가지고 있음.
- 요구사항 유효성 검증 (Validation)
- 오류 수정을 후반에 할수록 비용 증가
- 자주 발생하는 오류:
- 누락(30%)
- 모순(10~30%)
- 오류된 사실(10~30%)
- 애매함(5~20%)
SRS (Software Requirement Specification)
소프트웨어 요구사항 명세서
- SRS에는 시스템이 가져야 할 기능, 품질, 제약 조건 등을 명확하고 체계적으로 정리 공식 문서 (계약서)
- 주요 구성
- Introduction
- Current / Proposed System
- Functional & Non-Functional Requirements
- Models (시나리오, Use Case, Diagram 등)
- 요구사항
| 속성 | 설명 |
|---|---|
| Correct | 진짜 사용자가 원하는 것 |
| Unambiguous | 해석이 하나뿐 |
| Complete | 모든 요구 포함 |
| Consistent | 내부 모순 없음 |
| Feasible | 기술적으로 구현 가능 |
| Traceable | 출처 추적 및 구현 연결 가능 |
요구사항 개발 과정
두 가지의 의문점.
- 시스템의 목적을 어떻게 정의할 것인가?
- 어떤 기능이 필요한지, 왜 필요한지 알아내야 함.
- 시스템의 경계를 어떻게 정의할 것인가?
- 시스템이 할 일과 하지 않을 일을 명확히 구분해야 함.
두가지의 핵심 단계가 있음.
- Requirement Elcitation (요구사항 도출)
고객의 언어로 시스템을 정의하는 단계
- 고객이 원하는 것과 기대하는 것을 질문, 인터뷰를 통해 알아냄.
- 고객이 이해할 수 있는 비즈니스 용어, 실생활 표현 사용
- 즉, Customer 중심
- Analysis (요구사항 분석)
개발자가 이해할 수 있는 방식으로 시스템을 재정의하는 단계
- 도출된 요구사항을 기술적으로 구체화하고 구조화
- 개발자 관점에서 시스템의 작동 방식을 정의
단계 과정)
[Requirements] → Use Case Model
→ Analysis Model → Design Model
→ Source Code → Test Cases
// ToDo. Use Case 공부한 것 작성하기