소프트웨어 엔지니어링의 기능적 요구 사항은 무엇입니까?
찰스 무어
기능적 요구사항이란 무엇입니까?
A 기능적 요구 사항 (FR)은 소프트웨어가 제공해야 하는 서비스에 대한 설명입니다. 소프트웨어 시스템이나 그 구성 요소를 설명합니다. 함수는 소프트웨어 시스템에 대한 입력, 동작 및 출력일 뿐입니다. 이는 계산, 데이터 조작, 비즈니스 프로세스, 사용자 상호 작용 또는 시스템이 수행할 기능을 정의하는 기타 특정 기능일 수 있습니다. 소프트웨어 엔지니어링의 기능적 요구사항이라고도 합니다. 기능 사양.
소프트웨어 엔지니어링 및 시스템 엔지니어링에서 기능 요구 사항은 보낸 사람의 필요성에 대한 상위 수준 추상 설명부터 자세한 수학적 기능 요구 사항 사양까지 다양합니다. 기능성 소프트웨어 요구사항은 시스템의 의도된 동작을 포착하는 데 도움이 됩니다.
기능 요구사항 문서에는 무엇이 포함되어야 합니까?
기능 요구사항 문서를 작성하는 방법은 다음과 같습니다.
시스템의 기능적 요구 사항에는 다음 사항이 포함되어야 합니다.
- 모든 화면에서 수행되는 작업의 세부 정보
- 데이터 처리 로직을 시스템에 입력해야 합니다.
- 시스템 보고서 또는 기타 출력에 대한 설명이 있어야 합니다.
- 시스템에서 수행되는 작업 흐름에 대한 완전한 정보
- 시스템에서 데이터를 생성/수정/삭제할 수 있는 사람이 누구인지 명확하게 정의해야 합니다.
- 시스템이 해당 규제 및 규정 준수 요구 사항을 충족하는 방법을 기능 문서에 포착해야 합니다.
기능적 요구사항의 이점
다음은 일반적인 기능 요구사항 문서 작성의 장단점입니다.
- 애플리케이션이 해당 애플리케이션의 기능 요구 사항에 언급된 모든 기능을 제공하는지 확인하는 데 도움이 됩니다.
- 기능 요구사항 문서는 시스템 또는 해당 하위 시스템 중 하나의 기능을 정의하는 데 도움이 됩니다.
- 요구사항 분석과 함께 기능적 요구사항은 누락된 요구사항을 식별하는 데 도움이 됩니다. 예상되는 시스템 서비스와 동작을 명확하게 정의하는 데 도움이 됩니다.
- 기능적 요구사항 수집 단계에서 발견된 오류는 수정 비용이 가장 저렴합니다.
- 사용자 목표, 작업 또는 활동 지원
기능 요구 사항의 유형
다음은 가장 일반적인 기능 요구 사항 유형입니다.
- 거래 처리
- 비즈니스 규칙
- 인증 요구 사항
- 보고 요구 사항
- 관리 기능
- 승인 수준
- 감사 추적
- 외부 인터페이스
- 이력 데이터 관리
- 법적 및 규제 요구 사항
기능적 요구사항의 예
다음은 널리 사용되는 기능적 요구사항의 예입니다.
- 소프트웨어는 ABC 연락처 관리 시스템에 대해 고객을 자동으로 확인합니다.
- 판매 시스템에서는 사용자가 고객 판매를 기록할 수 있어야 합니다.
- 애플리케이션의 모든 창에 대한 배경색은 파란색이고 0진수 RGB 색상 값은 0000xXNUMXFF입니다.
- 관리자급 직원만이 매출 데이터를 볼 수 있는 권한을 갖습니다.
- 소프트웨어 시스템은 뱅킹 API와 통합되어야 합니다.
- 소프트웨어 시스템은 통과해야합니다 제 508 접근성 요구 사항.
비기능적 요구사항과 기능적 요구사항
다음은 기능적 요구사항과 비기능적 요구사항의 주요 차이점입니다. 소프트웨어 공학:
| 파라미터 | 기능적 요구 사항 | 비기능적 요구사항 |
|---|---|---|
| 그것이 무엇인지 | 동사 | Attributes |
| 요구 사항 | 필수입니다 | 필수사항은 아닙니다 |
| 캡처 유형 | 사용 사례에서 캡처됩니다. | 이는 품질 속성으로 캡처됩니다. |
| 최종 결과 | 제품 기능 | 제품 속성 |
| 캡처 | 캡처가 용이함 | 캡처하기 어려움 |
| 목표 | 소프트웨어의 기능을 확인하는 데 도움이 됩니다. | 소프트웨어의 성능을 확인하는 데 도움이 됩니다. |
| 초점 영역 | 사용자 요구사항에 집중 | 사용자의 기대에 집중합니다. |
| 문서 | 제품의 기능을 설명하세요. | 제품의 작동 방식을 설명합니다. |
| 테스트 유형 | 시스템, 통합, 엔드투엔드(End to End)와 같은 기능 테스트 API 테스트등 | 성능, 스트레스, 유용성 등의 비기능 테스트 보안 테스트등 |
| 테스트 실행 | 테스트 실행은 비기능 테스트 전에 수행됩니다. | 기능 테스트 후 |
| 제품 정보 | 제품 특징 | 제품 속성 |
기능 요구 사항의 모범 사례
기능 요구사항 문서 개발에 대한 중요한 모범 사례는 다음과 같습니다.
- 두 가지 요구 사항을 하나로 결합하지 마십시오. 요구사항을 세분화하여 유지하세요.
- 각 요구사항을 최대한 완전하고 정확하게 작성해야 합니다.
- 문서에는 모든 기술적 요구사항의 초안이 작성되어야 합니다.
- 성공적인 소프트웨어 제공에 기여하는 목표 및 원칙에 모든 요구 사항을 매핑합니다.
- 인터뷰, 워크숍, 일상적인 커뮤니케이션을 통해 요구 사항을 이끌어냅니다.
- 요구 사항에 실질적으로 영향을 미치는 알려진 검증된 제약 조건이 있는 경우 문서화해야 하는 중요한 상태입니다.
- 문서의 모든 가정을 문서화하는 것이 필요합니다.
기능적 요구사항을 작성하는 동안의 실수
다음은 기능 요구사항 문서를 작성하는 동안 흔히 저지르는 몇 가지 실수입니다.
- 개발자에게 혼란을 줄 수 있는 부당한 추가 정보를 넣는 행위
- 요구 사항 문서에 충분한 세부 정보를 넣지 않았습니다.
- 요구 사항 자체를 제외한 모든 규칙이나 예, 범위 지정 설명 또는 목표를 추가합니다.
- 요구 사항을 완전하고 정확하며 명확하게 설명하는 데 반드시 필요한 중요한 정보를 생략했습니다.
- 일부 전문가는 요구 사항이 수정될 때 올바른 진실을 찾는 대신 문서화된 요구 사항을 방어하기 시작합니다.
- 목표나 원칙에 매핑되지 않은 요구 사항입니다.
주요 학습
- 소프트웨어 엔지니어링의 기능적 요구사항 설명: 기능적 요구사항은 시스템 또는 해당 구성 요소를 정의합니다.
- 기능 요구 사항 문서에는 데이터 처리 논리와 시스템에서 수행되는 워크플로에 대한 완전한 정보가 포함되어야 합니다.
- 요구사항 분석과 함께 기능적 요구사항을 통해 누락된 요구사항을 식별하는 데 도움이 됩니다.
- 거래 수정, 조정 및 취소, 비즈니스 규칙, 인증 요구 사항, 보고 요구 사항, 관리 기능, 권한 부여 수준, 감사 추적, 외부 인터페이스, 기록 데이터 관리, 법적 또는 규제 요구 사항은 다양한 유형의 기능 요구 사항입니다.
- 두 가지 요구 사항을 하나로 결합하지 않는 것이 좋습니다. 요구사항을 세분화하여 유지하세요.
- 개발자를 혼란스럽게 할 수 있는 부당한 추가 정보를 기능 요구 사항 문서에 넣는 것은 피해야 합니다. 이러한 요구 사항이 실제 테스트 절차로 어떻게 변환되는지 이해하려면 다음에서 이 가이드를 살펴보는 것이 좋습니다. 기능 테스트.
