기능하지 않는 요건
Non-functional requirement시스템 엔지니어링 및 요건 엔지니어링에서 NFR(Non-functional requirement)은 특정 행동이 아닌 시스템 작동 판단에 사용할 수 있는 기준을 지정하는 요건이다.이러한 요구 사항은 특정 동작 또는 기능을 정의하는 기능 요건과 대조됩니다.기능요건의 실장 계획은 시스템 설계에 상세하게 기재되어 있습니다.비기능적 요구사항의 구현 계획은 일반적으로 아키텍처적으로 중요한 [1]요구사항이기 때문에 시스템 아키텍처에 자세히 설명되어 있습니다.
정의.
일반적으로 기능요건은 시스템이 무엇을 해야 하는지를 정의하고 비기능요건은 시스템이 어떻게 해야 하는지를 정의합니다.기능요건은 일반적으로 "시스템은 <요건>을 수행해야 한다", 개별 동작 또는 시스템의 일부이며, 아마도 명시적으로 수학적 기능, 블랙박스 설명 입력, 출력, 프로세스 및 제어 기능모델 또는 IPO 모델의 의미일 것이다.이와는 대조적으로 비기능적 요건은 특정 기능이 아닌 시스템 전체 또는 특정 측면의 전체 특성인 "시스템이 <요구사항이어야 한다"의 형태이다.시스템의 전체 속성은 일반적으로 개발 프로젝트의 성공 여부를 나타냅니다.
비기능적 요구사항은 종종 시스템의 "품질 속성"으로 잘못 불리지만, 그 둘 사이에는 차이가 있습니다.비기능적 요건은 소프트웨어 시스템이 어떻게 동작해야 하는지를 평가하는 기준이며, 소프트웨어 시스템은 비기능적 요건을 충족하기 위해 특정 품질 속성을 가져야 합니다.즉, 시스템이 「안전」, 「고가용성」, 「휴대용」, 「확장성」등이라고 하는 것은, 그 품질 속성에 대해서입니다.비기능적 요건의 다른 용어로는 "자격", "품질 목표", "서비스 품질 요건", "제약", "비동작 요건"[2] 또는 "기술 요건"[3]이 있습니다.비공식적으로는 안정성이나 휴대성 등의 속성으로 인해 이러한 속성을 "유틸리티"라고 부르기도 합니다.품질(비기능적 요건)은 크게 두 가지 범주로 나눌 수 있습니다.
- 동작 중(실행 시)에 관찰할 수 있는 안전, 보안, 사용성 등의 실행 품질.
- 테스트 가능성, 유지보수성, 확장성 및 확장성 등의 진화적 품질은 시스템의 [4][5]정적 구조에 구현됩니다.
예
시스템은 사용자에게 데이터베이스 내의 레코드 수를 표시하도록 요구될 수 있다.이것은 기능상의 요건입니다.이 번호가 얼마나 최신이어야 하는지는 기능하지 않는 요건입니다.숫자를 실시간으로 갱신할 필요가 있는 경우 시스템 설계자는 변경되는 레코드 수의 허용 가능한 짧은 간격 내에 시스템이 레코드 수를 표시할 수 있는지 확인해야 합니다.
충분한 네트워크 대역폭은 시스템의 기능상 요건이 아닐 수 있습니다.기타 예는 다음과 같습니다.
- 접근성
- 적응성
- 감사성과 관리
- 가용성(서비스 수준 계약 참조)
- 지원하다
- 기동 시간
- 용량, 현재 및 예측
- 인정.
- 준수
- 구성 관리
- 비용, 초기 및 라이프 사이클 비용
- 데이터 무결성
- data 보유
- 다른 당사자에 대한 의존
- 도입
- 개발 환경
- 디저스터 리커버리
- 문서
- 내구성
- 효율성(특정 부하에 대한 자원 소비량)
- 효과(노력 대비 퍼포먼스 향상)
- 탄력성
- 감정적인 요인(재미있거나, 흥미를 느끼거나, 「와!」 등)요인")
- 환경 보호
- 에스크로
- 이용 가능성
- 확장성(기능 추가 및 다음 주요 버전 업그레이드 시 커스터마이즈 이월)
- 장애 관리
- 폴트 톨러런스(운영체제 감시, 측정, 관리 등)
- 유연성(예: 미래의 요건 변경에 대응하기 위한)
- 설치 공간 감소 - exe 파일 크기 감소
- 통합성(컴포넌트 통합 기능 등)
- 국제화와 현지화
- 상호 운용성
- 법적 및 라이센스 문제 또는 특허 침해 회피 가능성
- 유지보수성(예를 들어 평균 수리 시간 – MTTR)
- 관리
- 메모리 최적화
- 변경 가능성
- 네트워크 토폴로지
- 오픈 소스
- 조작성
- 퍼포먼스/응답시간(퍼포먼스 엔지니어링)
- 플랫폼 호환성
- 프라이버시(프라이버시 법령 준수)
- 휴대성
- 품질(예: 발견된 고장, 전달된 고장, 고장 제거 효과)
- 가독성
- 신뢰성(예를 들어 평균 고장 간격(MTBF/MTTF))
- 리포트
- 내장해성
- 자원 제약(프로세서 속도, 메모리, 디스크 공간, 네트워크 대역폭 등)
- 응답시간
- 재사용 가능성
- 견고성
- 안전 또는 안전 요소
- 확장성(수평, 수직)
- 보안(사이버 및 물리)
- 소프트웨어, 도구, 표준 등호환성
- 안정성.
- 지원성
- 테스트 가능성
- 스루풋
- 투명성
- 대상 사용자 커뮤니티별 사용성(인적 요인)
- 볼륨 테스트
「 」를 참조해 주세요.
- ISO/IEC 25010:2011
- IT 소프트웨어 품질 컨소시엄
- ISO/IEC 9126
- 후루
- 요건 분석
- 사용 편의성 요건
- 비기능적 요건 프레임워크
- 아키텍처상 중요한 요건
- SNAP 포인트
레퍼런스
- ^ Chen, Lianping; Ali Babar, Muhammad; Nuseibeh, Bashar (2013). "Characterizing Architecturally Significant Requirements". IEEE Software. 30 (2): 38–45. doi:10.1109/MS.2012.174. hdl:10344/3061.
- ^ Stellman, Andrew; Greene, Jennifer (2005). Applied Software Project Management. O'Reilly Media. p. 113. ISBN 978-0-596-00948-9. Archived from the original on 2015-02-09.
- ^ Ambler, Scott. "Technical (Non-Functional) Requirements: An Agile Introduction". Agile Modelling. Ambysoft Inc. Retrieved 5 October 2018.
- ^ Wiegers, Karl; Beatty, Joy (2013). Software Requirements, Third Edition. Microsoft Press. ISBN 978-0-7356-7966-5.
- ^ Young, Ralph R. (2001). Effective Requirements Practices. Addison-Wesley. ISBN 978-0-201-70912-4.
외부 링크
- Petter L. H. Eide (2005). "Quantification and Traceability of Requirements". Idi.ntnu.bo. Retrieved 3 October 2017.
- Dalbey, John. "Nonfunctional Requirements". Csc.calpoly.edu. Retrieved 3 October 2017.
- "Modeling Non-Functional Aspects in Service Oriented Architecture" (PDF). Cs.umb.edu. Archived from the original (PDF) on 24 July 2011. Retrieved 3 October 2017.
- "Non-Functional Requirements: Do User Stories Really Help?". Methodsandtools.com. Retrieved 3 October 2017.
- "Non-Functional Requirements Be Here - CISQ - Consortium for IT Software Quality". it-cisq.org. Retrieved 3 October 2017.
| 품질 |
| ||||
|---|---|---|---|---|---|
| 표준 및 목록 | |||||
| 과정 | |||||
