기능 요구 사항 문서

기능 요구 사항 문서 (FRD)는 응용 프로그램의 기능 요구 사항에 대한 공식적인 설명입니다. 계약과 동일한 목적으로 사용됩니다. 여기에서 개발자는 지정된 기능을 제공하는 데 동의합니다. 고객은 제품이 FRD에 명시된 기능을 제공하는 경우 만족스러운 제품을 찾는 데 동의합니다.

기능적 요구 사항은 시스템의 의도 된 동작을 포착합니다. 이 동작은 시스템이 수행하는 데 필요한 서비스, 작업 또는 기능으로 표현 될 수 있습니다. 문서는 특정 프로젝트의 필요에 맞게 조정되어야합니다. 시스템 계산, 데이터 조작 및 처리, 사용자 인터페이스 및 응용 프로그램과의 상호 작용 등을 정의합니다.

기능 요구 사항 문서 (FRD)에는 다음과 같은 특성이 있습니다.

  • 애플리케이션이 향후 몇 년 동안 비즈니스 목표 및 비즈니스 프로세스 측면에서 가치를 제공함을 보여줍니다.

  • 여기에는 응용 프로그램에 대한 전체 요구 사항이 포함되어 있습니다. FRD에 명시되지 않은 것을 가정 할 여지가 없습니다.

  • 솔루션 독립적입니다. ERD는 애플리케이션의 작동 방식이 아니라 애플리케이션이 수행해야하는 작업에 대한 설명입니다. FRD는 개발자에게 디자인을 맡기지 않습니다. 따라서 특정 기술의 사용에 대한 언급은 FRD에서 완전히 부적절합니다.

기능 요구 사항은 다음을 포함해야합니다.

  • 설명 data 시스템에 입력

  • 설명 operations 각 화면에서 수행

  • 설명 work-flows 시스템에서 수행

  • 설명 system reports 또는 기타 출력

  • 누가 들어갈 수 있습니까? data 시스템에?

  • 시스템이 적용 가능한 것을 충족하는 방법 regulatory requirements?

기능 사양은 일반 사용자가 읽을 수 있도록 설계되었습니다. 독자는 시스템을 이해해야하지만이 문서를 이해하기 위해 기술적 지식이 필요하지 않습니다.

기능적 요구 사항 결과물

BRD (비즈니스 요구 사항 문서)는 다음으로 구성됩니다.

  • Functional Requirements− 개발중인 시스템에 대한 세부 요구 사항이 포함 된 문서. 이러한 요구 사항은 시스템이 보유해야하는 기능적 특징과 기능을 정의합니다. 비즈니스 사례에서 확인 된 모든 가정과 제약이 여전히 정확하고 최신 상태인지 확인하십시오.

  • Business Process Model − 프로세스의 현재 상태 모델 ( "있는 그대로"모델) 또는 프로세스가되어야하는 개념 ( "모델이 될"모델)

  • System Context Diagram − 컨텍스트 다이어그램은 시스템 경계, 시스템과 상호 작용하는 외부 및 내부 개체, 이러한 외부 및 내부 개체 간의 관련 데이터 흐름을 보여줍니다.

  • Flow Diagrams (as-is or to-be)− 다이어그램은 비즈니스 프로세스에 대한 작업 순서 또는 데이터 이동을 그래픽으로 묘사합니다. 모델의 복잡성에 따라 하나 이상의 흐름도가 포함됩니다.

  • Business Rules and Data Requirements − 비즈니스 규칙은 비즈니스의 일부 측면을 정의하거나 제한하며 데이터 제약, 기본값, 값 범위, 카디널리티, 데이터 유형, 계산, 예외, 필수 요소 및 데이터의 관계 무결성을 정의하는 데 사용됩니다.

  • Data Models − 엔티티 관계 다이어그램, 엔티티 설명, 클래스 다이어그램

  • Conceptual Model − 비즈니스 기능에 대한 다양한 엔티티와 이들이 서로 관련되는 방식에 대한 높은 수준의 표시.

  • Logical Model − 비즈니스 기능과 관련된 특정 엔티티, 속성 및 관계를 설명하고 비즈니스, 기술 또는 개념적 환경에서 데이터의 모든 정의, 특성 및 관계를 나타냅니다.

  • Data Dictionary and Glossary − 데이터베이스 또는 유사한 데이터 관리 시스템의 기반이되는 데이터 모델을 구성하는 데이터 요소, 필드, 테이블 및 기타 엔티티에 대한 자세한 정보 모음.

  • Stakeholder Map− 제안 된 변경 및 요구 사항에 대한 영향 / 권한 수준의 영향을받는 모든 이해 관계자를 식별합니다. 이 문서는 프로젝트 관리 방법론 (PMM)의 시작 단계에서 개발되었으며 프로젝트 관리자가 소유하지만 프로세스 전반에 걸쳐 신규 / 변경된 이해 관계자가 식별되면 프로젝트 팀이 업데이트해야합니다.

  • Requirements Traceability Matrix − 개별 기능 요구 사항과 기타 기능 요구 사항, 사용 사례 / 사용자 스토리, 아키텍처 및 디자인 요소, 코드 모듈, 테스트 사례 및 비즈니스 규칙을 포함한 기타 유형의 시스템 아티팩트 간의 논리적 링크를 보여주는 표.