8. Mini Project

    8. 1 . Storyboard

        스프링 프로젝트에서 문서화는 프로젝트의 성공과 유지 보수에 매우 중요한 요소이다. 문서화는 개발자와 사용자가 스프링 애플리케이션을 이해하고 사용 할 수 있도록 돕는 역할을 하게 된다. 문서화는 여러가지 형태로 이루어질 수 있으며 아래의 내용을 포함한다. 

        Here's a detailed list of the topics

• 8.1.1 PRD ( Product Requirements Document ):

• 8.1.2 PR ( Product Roadmap ):

• 8.1.3 IA ( Information Architecture ):

• 8.1.4 WF ( WireFrame ):

• 8.1.5 WBS ( Work Breakdown Structure ):

• 8.1.6 Usecase, ERD ...:

8.1.1 Product Requirements Document - PRD :

   - PRD는 제품 요구 사항 문서로 새로운 제품이나 기능을 개발하가 위한 상세 요구사항을 정의하는 문서이다. PRD는 개발팀, 디자인팀, 마케팅팀, QA팀등 다양한 관계자들이 제품의 목적과 기능을 명확히 이해하고 일관된 방향을 작업할 수 있도록 돕는다. 다시 말해 PRD의 주요 목적은 제품의 목표, 기능, 사용자 경험, 일정, 제약사항 등을 명확히 정의하는 것이다. 

   - 주요 구성 요소로는

     1. 개요 (Overview)

        - 제품 설명(Product Description): 제품이 무엇인지, 왜 필요한 지에 대한 간략한 설명.

        - 목표(Goals): 제품이 해결하고자 하는 문제와 이를 통해 달성하고자 하는 비즈니스 목표.

        - 타겟 사용자(Target Users): 제품의 주 사용자를 정의하고 그들의 요구사항와 페인 포인트(Pain Points)를 설명.

     2. 요구 사항 (Requirements)

        - 기능적 요구 사항(Functional Requirements): 제품이 제공해야 하는 기능을 구체적으로 설명합니다.

                                                                   일반적으로 사용자 스토리(User Stories)나 기능 목록으로 표현됩니다.

                                예: "사용자는 이메일과 비밀번호를 사용하여 로그인할 수 있어야 한다."

        - 비기능적 요구사항(Non-functional Requirements): 성능, 보안, 접근성, 유지보수성 등 기능 이외의 요구사항을 포함합니다.

                                예: "시스템은 1초 이내에 응답해야 한다."

     3. 기술적 세부 사항 (Technical Detail)

        - 아키텍처(Architecture): 시스템의 주요 구성 요소와 그 상호작용을 설명하는 다이어그램.

        - 데이터 모델(Data Model): 데이터베이스 스키마, 데이터 흐름 등을 설명.

      4. 제약 사항 및 가정(Constraints and Assumptions)

      - 기술적 제약(Technical Constraints): 사용할 수 있는 기술, 플랫폼, 언어 등에 대한 제한 사항.

      - 비즈니스 제약(Business Constraints): 예산, 시장 출시일 등 비즈니스와 관련된 제한 사항.

      - 가정(Assumptions): 프로젝트 진행 중 사실로 간주하는 사항.

      5.  PRD 작성 시 고려 사항

      - 명확성(Clarity): 모든 요구 사항과 설명은 명확하고 이해하기 쉽게 작성해야 합니다.

      - 완전성(Completeness): 제품 개발에 필요한 모든 정보를 포함해야 합니다.

      - 일관성(Consistency): 문서 전체에서 일관된 용어와 형식을 사용해야 합니다.

      - 우선순위(Priority): 요구 사항의 우선순위를 명확히 하여 중요도에 따라 개발할 수 있도록 합니다.

      - 협업(Collaboration): 이해 관계자들과의 협업을 통해 요구 사항을 정의하고 문서를 작성해야 합니다.

     6. PRD 정리

      - 만들고자 하는 것은 무엇인가?

      - 왜 이 제품을 만들어야 하는가?

      - 제품 개발을 통해 달성하고자 하는 목표가 무엇인가? 

      - 목표 달성을 위한 검증 지표는 무엇인가?

      참고자료 :  https://notion.notion.site/PRD-eb0c758e2f76420197c5896621ef413f

                     https://www.notion.so/templates/design-spec

8.1.2 Product Roadmap - PR :

        1. 개요 (Overview)

        제품 로드맵(Product Roadmap)은 제품 개발의 전략적 계획을 시각적으로 표현한 문서이다. 로드맵은 제품의 목표와 비전, 개발 일정, 주요 마일스톤, 출시 계획 등을 포함하며, 이해 관계자들에게 제품의 방향과 진행 상황을 명확하게 전달하는 도구로 사용된다. 제품 로드맵은 주로 제품 관리자(Product Manager)가 작성하고 유지 관리하며, 경영진, 개발팀, 마케팅팀, 고객 등 다양한 이해 관계자와 공유됩니다. 주의할 점은 하나의 로드맵만 작성하는 것 보다는 경영진 용, 개발팀 용, 고객 용 등으로 각각 다르게 작성하여 관리 하는 것이 실무적으로 유용하다. 

      특별히 정해진 양식은 없으며 작업자/개발자별로 전체 일정에 맞게 작성하여 한 눈에 보기 좋게 나열한다. 

      2. 제품 로드맵의 중요성

        - 전략적 방향 제시: 제품의 장기적인 비전과 목표를 명확히 하여 팀이 일관된 방향으로 작업할 수 있게 합니다.

        - 커뮤니케이션 도구: 이해관계자들과의 원활한 커뮤니케이션을 통해 제품 개발 과정에 대한 투명성을 높입니다.

        - 우선순위 관리: 기능과 마일스톤의 우선순위를 설정하여 자원을 효율적으로 배분하고, 중요한 목표를 달성할 수 있게 합니다.

        - 진행 상황 추적: 제품 개발의 진행 상황을 시각적으로 추적할 수 있어 계획 대비 실제 진행 상황을 쉽게 비교할 수 있습니다.

        - 리스크 관리: 잠재적인 위험 요소를 조기에 식별하고 대응할 수 있도록 돕습니다.

      3. 제품 로드맵 작성 시 고려사항

        - 명확한 비전 설정: 제품의 비전과 목표를 명확히 정의하고 이를 로드맵에 반영합니다.

        - 이해관계자와의 협업: 다양한 이해관계자의 의견을 수렴하여 로드맵을 작성하고, 정기적으로 업데이트합니다.

        - 유연성 유지: 시장 변화나 사용자 피드백에 따라 로드맵을 유연하게 조정할 수 있도록 합니다.

        - 우선순위 명확화: 중요한 기능과 목표를 우선적으로 배치하고, 팀이 집중할 수 있도록 합니다.

        - 적절한 도구 사용: Jira, Trello, Roadmunk, Aha!와 같은 로드맵 관리 도구를 활용하여 시각적이고 체계적으로 관리합니다.

8.1.3 Information Architecture - IA :

        1. 개요 (Overview)

정보 아키텍처(Information Architecture, IA)는 디지털 환경에서 정보의 구조, 조직, 레이블링 및 내비게이션을 설계하는 과정이다. IA는 사용자가 원하는 정보를 쉽게 찾고 이해할 수 있도록 돕기 위해 필수적인 요소이다. 주로 웹사이트, 애플리케이션, 인트라넷 등의 디지털 제품에서 적용된다. .

       2. 정보 아키텍처의 중요성

        - 사용자 경험 향상: 잘 설계된 정보 아키텍처는 사용자가 필요한 정보를 쉽게 찾고, 탐색하며, 이해할 수 있도록 도와준다. 

        - 비즈니스 목표 달성: 사용자 만족도를 높이고, 사용자 참여를 증대시키며, 궁극적으로 비즈니스 목표를 달성하는 데 기여한다. 

        - 일관성 유지: 일관된 정보 구조와 내비게이션을 통해 사용자에게 일관된 경험을 제공한다. 

        - 효율성 증가: 정보의 체계적인 조직과 검색 기능을 통해 사용자가 효율적으로 작업을 수행할 수 있도록 한다. 

정보 아키텍처는 사용자와 비즈니스 요구를 모두 충족하는 효과적인 디지털 환경을 설계하는 데 필수적인 요소이다. IA를 통해 사용자는 원하는 정보를 쉽게 찾고, 조직은 사용자 경험을 향상시키며, 비즈니스 목표를 달성할 수 있다.

8.1.4 WIre Frame - WF :

        1. 개요 (Overview)

와이어프레임(Wireframe)은 웹사이트나 애플리케이션의 구조와 레이아웃을 시각적으로 표현한 초기 설계 도구이다. 와이어프레임은 주로 페이지의 레이아웃, 콘텐츠 배치, 내비게이션 요소 등을 단순하고 추상적인 형태로 나타낸다. 이는 디자인과 개발 과정의 초기 단계에서 아이디어를 시각화하고, 이해관계자들과의 커뮤니케이션을 원활하게 하기 위해 사용됩된다. 

        2. 와이어프레임의 주요 특징

          - 단순함(Simplicity): 와이어프레임은 주로 흑백 또는 회색조로 작성되며, 상세한 그래픽 요소나 색상은 포함되지 않는다. 주요 목표는 레이아웃과 콘텐츠 배치를 명확히 하는 것이다.

          - 기능 강조(Focus on Functionality): 페이지의 각 요소가 어떤 기능을 할 것인지 강조한다. 버튼, 링크, 이미지 자리 등을 단순한 박스와 텍스트로 표시한다.

          - 구조적 표현(Structural Representation): 전체적인 페이지 구조와 정보의 계층적 관계를 보여준다. 페이지 간의 내비게이션 흐름을 포함할 수 있다.

        3. 와이어프레임의 장점

          - 명확한 커뮤니케이션: 디자이너, 개발자, 이해관계자 간의 명확한 커뮤니케이션을 돕는다. 아이디어를 시각적으로 표현하여 오해를 줄인다.

          - 효율적인 설계 과정: 초기 단계에서 레이아웃과 기능을 명확히 하여 개발 과정에서 발생할 수 있는 변경 사항을 줄일 수 있다. 

          - 사용자 중심 디자인: 사용자 피드백을 반영하여 설계를 개선할 수 있다. 사용자 경험(UX)을 최적화하기 위한 기반을 제공한다.

와이어프레임은 웹사이트나 애플리케이션 설계 과정에서 필수적인 도구로, 정보의 구조와 레이아웃을 명확히 하고, 디자인과 개발의 방향성을 제시한다. 이를 통해 프로젝트의 성공 가능성을 높이고, 사용자 경험을 향상 시킬 수 있다.

8.1.5 Work Breakdown Structure - WBS :

        1. 개요 (Overview)

Work Breakdown Structure (WBS)는 프로젝트 관리에서 사용하는 도구로, 프로젝트를 더 작은 구성 요소로 분해해서 체계적으로 정리한 것이다. 쉽게 말하면, 큰 프로젝트를 작은 작업 단위로 쪼개서 관리하는 방법이야.

        2. WBS의 주요 특징

          - 계층 구조: 프로젝트를 단계별로 나눠서 트리 구조로 표현해. 맨 위에는 프로젝트 전체가 있고, 그 아래에 주요 단계, 그 아래에 더 작은 작업들이 차례로 위치한다. .

          - 작업 패키지: 각각의 작은 단위 작업을 '작업 패키지'라고 부르며. 작업 패키지는 실제로 수행해야 하는 구체적인 작업을 의미한다..

          - 세부화: 작업을 점점 더 작은 단위로 세부화해서 관리가 용이하게 만드는 게 핵심이다. 이렇게 하면 어떤 작업이 필요한지, 누가 해야 하는지, 언제까지 해야 하는지 명확하다.

8.1.6 Usecase :

        1. 개요 (Overview)

유스케이스를 통해 시스템이 어떻게 작동하고, 사용자와의 상호작용이 어떻게 이루어지는지를 명확하게 이해할 수 있다. 이를 통해 개발팀과 이해관계자들이 요구사항을 명확히 파악하고, 시스템 설계를 효율적으로 할 수 있다.

        2. 주요 구성 요소

          - 유스케이스 이름 (Use Case Name) : 유스케이스를 식별하는 간단한 이름 , 예: "사용자 로그인"

          - 액터 (Actor) : 시스템과 상호작용하는 사람이나 외부 시스템 , 예: "사용자", "관리자"

          - 목표 (Goal) : 액터가 유스케이스를 통해 달성하고자 하는 목표 , 예: "사용자가 시스템에 로그인한다."

          - 사전 조건 (Preconditions) : 유스케이스 시작 전에 만족해야 하는 조건 , 예: "사용자가 유효한 사용자 이름과 비밀번호를 가지고 있어야 한다."

          - 후행 조건 (Postconditions) : 유스케이스 완료 후 시스템의 상태 , 예: "사용자가 시스템에 성공적으로 로그인된다."

          - 기본 흐름 (Basic Flow) : 유스케이스의 정상적인 진행 시나리오

                                       예:

                                            사용자가 로그인 페이지에 접근한다.

                                            사용자가 사용자 이름과 비밀번호를 입력한다.

                                            사용자가 로그인 버튼을 클릭한다.

                                            시스템이 자격 증명을 확인한다.

                                            자격 증명이 유효하면 사용자가 대시보드 페이지로 리디렉션된다.

          - 대체 흐름 (Alternative Flow) : 기본 흐름에서 벗어난 경우의 시나리오

                                              예:

                                           사용자가 잘못된 비밀번호를 입력하면 시스템이 오류 메시지를 표시하고 다시 입력을 요청한다.

예시 종합 : 

                    Notion Download Link