[화면설계서] 요구사항정의서 샘플

요구사항정의서는 프로젝트 또는 제품 개발 과정에서 사용자나 고객의 요구사항을 명확히 정의하고 이를 문서화한 자료입니다. 이 문서는 개발 팀과 이해관계자 간의 커뮤니케이션 도구로 사용되며, 프로젝트 성공의 핵심 요소 중 하나입니다.

1. 요구사항정의서 샘플 구성

1.1. 문서 개요

• 제목: 요구사항정의서
• 버전: 1.0 (혹은 현재 버전)
• 작성일: YYYY-MM-DD
• 작성자: 작성자 이름 및 소속 부서
• 승인자: 승인자 이름 및 소속 부서
• 목적: 이 문서의 목적과 범위를 간략히 설명

1.2. 프로젝트 개요

• 프로젝트 명: 프로젝트의 이름
• 프로젝트 배경: 프로젝트의 배경과 필요성
• 목표: 프로젝트의 주요 목표와 기대 효과
• 이해관계자: 프로젝트에 관련된 주요 이해관계자 리스트 (예: 고객, 최종 사용자, 개발 팀, 관리 팀 등)

1.3. 시스템 개요

• 시스템 개요: 개발할 시스템 또는 제품의 전반적인 개요
• 범위: 시스템이 포함하는 기능과 범위 정의
• 제약사항: 예산, 일정, 기술적 제약 등의 제한사항

1.4. 요구사항 상세

• 기능 요구사항
  • 기능명: 기능의 이름
  • 설명: 해당 기능의 상세 설명
  • 우선순위: 기능의 중요도 (예: 필수, 중요, 선택)
  • 입출력 데이터: 입력 및 출력 데이터의 정의
  • 연관 기능: 연관된 기능 및 시스템 구성 요소
• 비기능 요구사항
  • 성능 요구사항: 시스템의 성능 지표 (예: 응답 시간, 처리량)
  • 보안 요구사항: 보안 관련 요구사항 (예: 인증, 권한 관리)
  • 사용성 요구사항: 사용자 인터페이스 및 접근성 요구사항
  • 운영 및 유지보수 요구사항: 운영 환경, 유지보수 절차

1.5. 시스템 아키텍처

• 시스템 구성도: 시스템의 구성 요소와 그 관계를 도식화
• 데이터 흐름도: 데이터가 시스템 내에서 어떻게 흐르는지 도식화

1.6. 요구사항 추적성 매트릭스

• 요구사항 ID: 각 요구사항에 고유 ID 부여
• 설계 문서 참조: 해당 요구사항이 반영된 설계 문서의 참조
• 테스트 케이스 참조: 요구사항을 검증하는 테스트 케이스의 참조

1.7. 변경 관리

• 변경 이력: 문서의 변경 내역 기록 (날짜, 변경 사항, 변경자 등)
• 변경 요청 절차: 요구사항 변경 시 처리 절차

1.8. 승인 및 서명

• 승인 서명: 요구사항정의서의 승인자 서명란
• 서명일: 서명 날짜

2. 요구사항정의서 작성 방법

1. 이해관계자와 협의: 프로젝트 이해관계자와 긴밀히 협의하여 요구사항을 수집하고 문서화합니다.
2. 요구사항 명확화: 수집된 요구사항이 모호하지 않도록 명확히 기술합니다.
3. 우선순위 부여: 각 요구사항의 중요도에 따라 우선순위를 부여합니다.
4. 추적 가능성 확보: 각 요구사항이 설계, 구현, 테스트 단계에서 어떻게 반영되고 검증되는지 추적할 수 있도록 합니다.
5. 변경 관리: 요구사항 변경 시 문서에 반영하고 이를 체계적으로 관리할 수 있는 절차를 마련합니다.

요구사항정의서는 프로젝트 성공의 필수적인 요소이므로, 충분한 시간을 들여 명확하고 체계적으로 작성하는 것이 중요합니다.

[요구사항정의서 샘플]

요구사항정의서 샘플

화면ID	구분	분류	유형	어드민	부서	요구사항
FO_001	공통	로그인	신규	X	마케팅_홍길동	카카오톡 간편로그인 기능을 추가해주세요.
FO_002	공통	약관동의	수정	O	정보보안	00항목을 추가해주세요.

논의사항	수용여부	답변내용	담당자	반영일	반영확인	비고
​	​	​	​	​	​	​
​	​	​	​	​	​	​

요구사항정의서 표준 템플릿

항목설명예시

화면 ID	화면을 구분하는 고유 ID입니다. PM의 판단에 따라 넣을 수 있으며, 커뮤니케이션의 기준이 됩니다.	Fo_001, Bo_002
구분	요구사항이 공통인지, 특정 화면에만 적용되는지 여부를 정의합니다.	공통, 특정화면
분류	IA(Information Architecture) 상의 카테고리 분류명을 기재합니다.	메인화면 > 사용자관리
유형	신규 정의, 수정 등 요구사항의 유형을 기재합니다.	신규, 수정
어드민	어드민과의 연동 필요 여부를 정의합니다.	필요, 불필요
부서(담당자명)	요구사항을 요청한 부서와 담당자명을 기재합니다.	기획부서 (홍길동)
요구사항	요구사항을 간단하고 핵심적으로 정의합니다.	사용자 등록 기능 추가
논의사항	요구사항에 대해 논의된 내용을 기재합니다.	기능 추가 범위 논의
수용 여부	논의 끝에 결정된 수용 여부를 표기합니다.	O, X
답변 내용	요구사항 수용 시, 수용 방식이나 대체 방안을 명확히 기재합니다.	일정 조정 후 수용
담당자/반영일	요구사항을 반영한 담당자와 반영일을 기재합니다.	개발팀/2024-09-15
반영 확인	최종 결과를 확인했음을 기록합니다.	확인 완료

각 항목의 작성 방법 및 팁

1. 화면 ID:
   • 화면 ID는 프로젝트의 규모에 따라 결정됩니다. 일반적으로 Fo_001, Bo_002와 같이 프론트엔드와 백엔드를 구분하고, 일관된 기준과 숫자로 관리합니다.
2. 구분:
   • 이 항목은 요구사항이 전체 시스템에 영향을 미치는지, 아니면 특정 화면이나 모듈에만 적용되는지를 명확히 정의합니다.
3. 분류:
   • IA 상의 카테고리 또는 댑스(Depth)로 나누어 상세화할 수 있으며, 이 정보는 프로젝트 구조를 이해하는 데 필수적입니다.
4. 유형:
   • 요구사항이 RFP(제안 요청서)에서 정의된 기본 요건인지, 아니면 신규 정의나 수정이 필요한지에 따라 유형을 정의합니다.
5. 어드민:
   • 어드민 시스템과의 연동이 필요한 경우, 해당 여부를 명확히 기재하여 개발 범위와 일정을 명확히 합니다.
6. 부서(담당자명):
   • 요청 부서와 담당자를 명시하여 커뮤니케이션 채널을 명확히 합니다. 프로젝트 범위에 따라 담당자만 적거나, 부서와 함께 기재할 수 있습니다.
7. 요구사항:
   • 요구사항은 핵심 내용만 간단히 정의하고, 관련 파일이나 이메일 내용을 비고란에 참고하도록 기재합니다.
8. 논의사항:
   • 요구사항에 대해 논의된 사항을 기록하며, 회의록으로 대체될 수 있습니다.
9. 수용 여부:
   • 요구사항 수용 여부를 O, X 등으로 표기하고, 일정 등을 고려해 신중히 결정합니다.
10. 답변 내용:
    • 수용된 요구사항에 대해 구체적인 대응 방안을 기재합니다. 더 나은 대안이나 타협된 계획이 있을 경우 이를 명확히 설명합니다.
11. 담당자/반영일:
    • 요구사항을 반영한 담당자와 예상 반영일을 기재하여 일정을 관리합니다.
12. 반영 확인:
    • 최종 결과를 담당자가 확인했음을 명확히 기록하여, 향후 발생할 수 있는 이슈를 예방합니다.

이 템플릿을 활용하면 프로젝트 요구사항을 체계적으로 관리하고, 명확한 커뮤니케이션을 통해 성공적인 프로젝트 진행에 기여할 수 있습니다.

 

---

기획은 검정색입니다.

"졸업 가운의 색이 검정인 이유는 검정이 성취와 권력의 색이기 때문입니다."

 

질문 환영합니다. 댓글 남겨주세요.
thinkhub