[Project] 프로젝트 기획과 분석

📌 개인적인 공간으로 공부를 기록하고 복습하기 위해 사용하는 블로그입니다.
정확하지 않은 정보가 있을 수 있으니 참고바랍니다 :😸
[틀린 내용은 댓글로 남겨주시면 복받으실거에요]

프로젝트 기획과 분석

프로젝트 개요

1. SRS의 정의
   • SRS (Software requirements specification)는 소프트웨어가 무엇을 할 것이며 어떻게 작동할 것으로 예상되는지를 설명하는 문서이다. 또한 제품이 모든 이해 관계자(비즈니스, 사용자)의 요구를 충족시키는데 필요한 기능을 설명한다.
   • 소프트웨어(제품)를 기획/분석, 설계, 구현, 시험 하는데 있어 필요한 종합 설계도와 같다고 볼 수 있다.
2. 프로젝트에서 SRS의 중요 이유
   • 프로젝트의 전체적인 그림을 제공
   • 소프트웨어(제품) 개발에 관련된 모든 팀이 따라야 하는 것의 집합이며 그 원천을 제공하기 때문

사용자 요구사항 정의서

소프트웨어 개발 단계

• RFP(Request For Proposal)를 통해 제안요청을 하고 프로젝트 계약이 완료되면 SRS(Software requirements specification)를 통해 프로젝트의 큰 그림을 설계한다.
• 이때 프로젝트 관리자는 인력, 시간, 돈의 관점에서 성공적인 프로젝트를 수행할 수 있게 전략적으로 접근한다.
• 이 과정을 프로젝트를 도입하고 시행하기 위한 기획의 범주라고 가정했을 때 그 다음은 개발할 소프트웨어를 분석하는 과정이 필요하다.
• 하나의 프로젝트가 올바르고 안정적으로 진행되려면 다음과 같은 과정을 거쳐야한다.
  1. 분석 단계

  소프트웨어를 개발하기 위해서 만들려고 하는 것에 대한 분석이 먼저 이루어져야 한다. 사용자 요구사항 정의서, 유스 케이스 명세서, 요구사항 추적표와 같은 문서를 작성함으로써 보다 구체적으로 분석 필요.

1. 설계 단계

   분석이 끝났다면 실제로 구현하기 위해서 올바른 설계가 필요하다. 설계 또한 이전에 작성됐던 SRS를 기반으로 하여 범주에 벗어나지 않는 설계를 할 필요가 있습니다. 설계 단계에서는 클래스 설계서, 사용자 인터페이스 설계서, 컴포넌트 설계서, 인터페이스 설계서, 아키텍처 설계서, 총괄시험 계획서, 시스템시험 시나리오, 엔티티 관계 모형 기술서, 데이터베이스 설계서, 통합시험 시나리오, 단위시험 케이스, 데이터 전환 및 초기데이터 설계서와 같은 문서를 작성함으로써 보다 구체적으로 설계합니다.

2. 구현 단계

   분석 → 설계의 과정을 통해 실질적인 구현의 준비를 마무리합니다. 구현 단계에서는 실제 개발 작업이 이루어지며 소프트웨어의 모습이 갖춰지는 단계입니다. 프로그램 코드, 단위시험 결과서, DB 생성 스크립트 등을 문서화 하여 개발의 진행 정도를 알 수 있게 가시화 합니다.

3. 시험 단계

   구현이 완료되면 전체적인 테스트를 할 필요가 있습니다. 통합시험 결과서, 시스템시험 결과서, 사용자 지침서, 운영자 지침서, 시스템 설치 결과서, 인수시험 시나리오, 인수시험 결과서와 같은 문서를 작성함으로써 보다 구체적으로 시험을 진행합니다. 또한 시험 단계에서 사용자, 운영자를 위한 지침서(매뉴얼)를 작성합니다.

사용자 요구사항 정의서

분석 단계에서 작성하는 ‘사용자 요구사항 정의서’는 매우 중요 ⇒ 프로젝트 단계에서도 무조건 작성해야 한다. 요구사항 정의서가 나오면 UserFlow를 작성할 수 있고 그것도 꼭 작성해야 한다,,,,!

1. 작성 목적

   시스템의 요구사항을 도출하여 발주자와 내용을 합의하고, 하나의 업무 단위로서 가치를 가지고 수행될 수 있는 업무를 도출하여 업무 내용을 기술합니다.

   NIA(한국정보화진흥원)에서는 사용자 요구사항 정의서의 작성 목적을 위와 같이 정의하고있다. 고객의 요청 사항을 기반으로 SRS의 협의 내용을 적용하고 실제 개발에 적용할 수 있는 수준으로 요구사항을 재정의 하라는 의미다. 문서의 제목 그대로를 이해하는것이 개념을 잡는데 유리할 수 있다.

2. 작성 방법

   산출물 양식의 표를 이용하여 해당 항목에 기술하며 이해하기 쉽고 구체적인 언어표현을 사용한다. 기능적 요구사항과 비기능 요구사항을 그룹핑하여 별도의 표로 작성한다.

   • 기능적 요구사항이란 ‘현금 입출금 시스템’을 만든다고 가정했을 때 ‘현금 출금 기능’과 같은 동작을 수행하는 모든 행위를 의미한다.
   • 반대로 비기능 요구사항이란 ‘시스템 관리자가 조직 변경에 따른 권한 변경이 있을 경우, 이를 1분 이내에 적용할 수 있어야 한다’ 와 같은 성능적인 측면이나 다른 의미의 비기능적인 항목의 모두를 의미한다.

3. 항목 설명

   

사용자 요구사항 정의서 작성해보기

요구사항명	구분	요구사항 설명	중요도
회원등록	기능	회원가입할 때는 이메일과 , 전화번호, 이름의 정보가 필요하다.	상
회원 권한	부기능	회원가입시 접근 권한을 부여할 수 있다.	상
메뉴 보기 및 선택	기능	사용자는 다양한 커피 메뉴를 확인할 수 있어야 한다.	상
메뉴 보기 및 선택	기능	고객은 메뉴에 대한 상세 설명과 가격을 확인할 수 있어야 한다.	중
주문 및 결제	기능	등록된 회원이 등록된 커피를 주문할 경우 커피를 주문할 수 있다.	상
주문 및 결제	기능	주문한 커피를 결제할 수 있어야 하며 다양한 결제 수단을 통해 이루어 질 수 있어야 한다.	상
배달 정보 입력	부기능	사용자는 배달 주소와 연락처를 입력할 수 있어야 한다.	상
장바구니	부기능	커피를 장바구니에 추가 할 수 있어야 한다.	중
장바구니	부기능	장바구니에서 조회 및 결제 기능이 가능해야 한다.	상
쿠폰	부기능	커피 한 잔당 한 개의 스탬프를 적립할 수 있다.	중
리뷰 및 피드백	부기능	사용자는 주문한 커피에 대해 리뷰를 남길 수 있어야 한다.	중
보안요구사항	부기능	사용자의 정보는 암호화되어 저장되어야 한다.	상

기능과 부기능을 구분짓는 것도 조금 어려웠으며 이게 맞나 싶었는데 중요도도 ,,, 꽤나어려웠다 , 실제 애플리케이션이라고 생각하고 시나리오를 명확하게 정해서 작성하면 작성할 때도 구체적으로 작성하기 쉽고 개발할 때도 편리하게 적용가능하다고 한다.

사용자 요구사항 정의서 → 기능정의서로 뻗어 나가야 하고

상이 많으면 우선순위를 정하기 힘들기 때문에 우선순위를 설정하는 것을 잘해야 한다.

아래는 잘된 예시인데 내가 작성한 것에 비해 시나리오가 명확하고 프론트쪽 그리고 기능 같은 것이 명확하게 작성되어있다.

요구사항 정의서에 다른 동기 분은 엄청 구체적으로 작성하던데 나는 막막해서 많이 작성하지는 못한 것 같다. 실제 프로젝트 들어갔을 때는 위의 표보다도 더 구체적으로 시나리오륵 짜서 작성해볼 수 있도록 해야 할 것 같다…..!

Project 카테고리 내 다른 글 보러가기