공통: 코드스테이츠_Project_설계

윤뿔소·2022년 12월 19일
0

프로젝트

목록 보기
1/4

여기서는 프로젝트 준비 전 기획/분석 단계에서 개발자가 생각해야되고 하면 좋은 부분들을 학습하겠다. 기업의 비즈니스적 관계에 대해서 기술한 경우라 토이나 사이드 프로젝트면 크게 신경 쓰진 말자.

기본 지식

비지니스 관점의 프로젝트 이해

전체적인 흐름의 이해를 위해 읽어보자. 보통 이런 식으로 전개가 된다. 물론 당연히 프로젝트의 성격 차이로 달라질 수 있다.

  1. 과업 발생
    개발팀이 착수해야 할 프로젝트가 발생하는 시점입니다. 예를 들어 A전자 인사팀에서 신규 입사 지원자에 대한 관리를 시스템으로 잘 관리하고 있었지만 기존 시스템이 현 상황과 맞지 않아 ‘고도화'(시스템 개선) 해야 하는 경우가 발생했다고 가정합니다. 대부분의 인사팀에서는 시스템을 고도화 할 수 있는 인력이 확보되지 않은 상태기 때문에 시스템 개선을 위해 신규 인력을 채용하여 프로젝트를 진행하기에는 무리가 따릅니다. 다행히도 A전자 그룹은 많은 계열사를 보유하고 있기 때문에 먼 곳에서 인력을 확보하지 않아도 됩니다. 그러나 계열사 개발팀 인력 또한 엄연히 다른 사업자로 구분되어 있으므로 계약 체결을 포함하여 프로젝트 전반에 대한 논의가 진행되어야 합니다. 즉 니즈가 발생하는 발주처에서 진행되어야 할 과업(프로젝트)이 그 집단의 니즈에 맞게 발생하게 됩니다.

  2. 사업자 선정 및 계약
    A전자 인사팀의 예시를 통해 계속 살펴보겠습니다. 해당 요구사항을 해결해줄 사업자를 선정한 결과 우리 기업의 시스템을 가장 잘 이해하고 있고 비교적 사업자 선정이 용이한 계열사(A전자 SDS)가 있습니다. 이럴때 A전자 인사팀은 계열사를 사업자로 선정합니다. 하지만 삼성전자 수준의 거대 기업이 아니라면 계열사를 사업자로 선정하기는 불가능하므로 요구사항에 맞는 사업을 진행하는 제 3의 기업을 사업자로 선정할 수 있습니다. 또한 조금은 다른 시각에서 자사의 계열사는 아니지만 A계열사를 사업자로 선정할 수 있습니다. 사업자가 선정되면 발주처는 선정된 사업자에게 거래를 제안하고 여러번의 미팅을 거쳐 최종 계약을 진행하게 됩니다. 이때 발주처는 선정된 사업장에 명확한 요구사항과 일정, 사업 비용 등을 명시할 필요가 있습니다. 이러한 행위를 RFP(Request For Proposal, 제안 요청서)로 작성하여 문서화 합니다.
    제안 요청서는 개요와 구축 컨셉, 제안요청사항 정의, 제안서 작성가이드 정의의 내용을 포함합니다. 이때 제안서란 수주할 사업자가 해당 내용을 바탕으로 해당 과업을 이렇게 해결하겠다고 제안하는 행위의 전체를 의미합니다. A전자 인사팀에서 A라고 하는 과업(프로젝트)을 발주 했을 때 고객사에서 사업자 선정을 하고 바로 계약을 맺거나 다른 방법으로 사업을 입찰하여 여러 경쟁사 중 한 사업자가 수주할 수도 있습니다. 이때 제안서를 통해 참여 기업은 고객의 최종 선택을 받을 수 있습니다.

  3. 기획 / 분석
    진행할 프로젝트의 계약을 포함한 전처리가 완료되었다면 프로젝트를 총괄하는 PM (Project Manager)은 프로젝트를 성공적으로 수행하기 위해서 일해야 합니다. 프로젝트 PM을 항해사에 비유 할 수 있습니다. PM의 역량에 따라 프로젝트의 운명이 달라집니다. PM은 사업 내용을 확인하고 그에 맞는 인력과 시간을 확보할 수 있습니다. 결국 계약 관계에 있어 가장 중요한 부분은 인력, 시간, 돈으로 나뉠 수 있는데 PM의 역량에 따라 이 요소들이 조절되거나 결정됩니다. 이렇듯 많은 고민의 과정이 ‘기획' 단계에서 구체화 됩니다. 인력, 시간, 돈을 고려하여 고객의 요구사항을 잘 고민하고 그 과정에서 고객과의 소통을 통해 탄생하는 문서가 SRS (Software requirements specification) 입니다. 여기에서는 앞서 설명드린 대로 설계도와 같아서 앞으로 진행될 프로젝트의 전반적인 내용과 참고해야 할 많은 지표들이 담겨 있습니다.

  4. 설계
    설계 단계는 기획된 SRS의 목표에 따라 그에 맞는 구체적인 설계가 고려되는 과정입니다. 구체적인 설계를 하려면 무엇을 어떻게 설계해야 하는지 그 가이드가 필요할 수 있습니다. 따라서 개발자를 포함한 프로젝트 인원은 그들의 역할에 맞는 특정 내용을 정리하는 문서들을 통해 설계를 구체화 합니다. 개발 관련 학습을 하면서 한번쯤 눈에 익혔을 화면 정의서, 아키텍처 설계서, 클래스 정의서 등이 설계 문서의 일부입니다. 이렇듯 구체화된 설계 구분을 통해 명확한 목표로 사용될 수 있는 설계 작업을 진행합니다.

  5. 구현
    실제로 기획/분석 → 설계 과정을 거친 후 그 가이드에 맞게 개발 업무를 수행하는 과정입니다. 지금까지는 학습을 목표로 1~4 단계를 고민하지 않고 개발 학습에만 집중할 수 있었습니다. 하지만 입사 후 실제 개발 업무를 진행하게 되면 근거 없는 개발은 자원 낭비일 뿐이므로 명확한 목표에 맞게 개발 업무를 진행해야 합니다. 따라서 개발자는 구현 단계에서 개발 본연의 업무에 집중할 수 있도록 기획/분석과 설계의 단계에 적극적일 필요가 있습니다. 우리가 올바르게 개발을 잘 하고 있는지를 알기 위해서 개발된 최소의 단위(동작 단위)로 그 결과를 시험하고 그 결과를 기술하기도 합니다. 개발자들 사이에서는 ‘단위 테스트'라고 많이 언급되고 있습니다. 여러명이 모여서 하나의 프로젝트를 구성하고 있다는 대전제를 잊으면 안됩니다. 내가 개발한것이 올바르게 작동하는가에 대한 정보는 모두에게 공유 되어야 합니다. 그래야 각자의 업무에 집중할 수 있고 전체적인 개발의 결과물이 눈에 보일 수 있기 때문입니다.

  6. 시험
    우리는 옷가게에서 옷을 구매할 때에도 여러 상점을 둘러보며 옷을 입어보고 나에게 잘 어울리는지 가격은 적당한지, 계절에 맞는 소재의 옷인지 등을 꼼꼼하게 검토하고 구매합니다. 이처럼 모든 결정에 앞서 예측하고 그 결과를 미리 알아보는 과정은 매우 중요합니다. 하나의 프로젝트가 완성되고 서비스로 게시되는 입장에서도 비슷합니다. 올바르게 구현이 되었는지, 구현의 결과가 올바른 설계에 의한 것인지 등을 면밀하게 검토할 필요가 있습니다. 결국 시험이 체계적으로 진행되지 않으면 서비스 오픈 이후 많은 리스크를 감수해야 합니다. 이는 프로젝트 실패로 이어질 수 있습니다. 구현 단계에서 ‘단위 테스트'를 통해 올바른 개발이 지속될 수 있는지를 판단했다면 시험 단계에서는 ‘통합 시험'을 통해 완성된 온전한 하나의 서비스가 그 역할을 잘 수행할 수 있는지를 검사합니다. 또한 이 과정에서 서비스 오픈을 위해 사용자나 운영자 관점에서의 지침서(매뉴얼) 등을 작성하기도 합니다.

  7. 서비스 오픈
    모든 준비가 끝나면 서비스가 오픈됩니다. 하지만 프로젝트가 완전히 끝난것은 아닙니다. 유지보수가 남아있기 때문입니다.

  8. 유지보수
    특정 시스템을 사용하는 사용자 입장에서는 그 시스템이 완벽한 시스템이라는 전제하에 사용하게 됩니다. 그래서 오류가 발생하거나 잘 동작하지 않으면 기분이 언짢아집니다. 하지만 개발자의 입장에서 생각해보면 신이 아닌 인간이 작업한 결과물이므로 완벽한 시스템이 될 수 없다는 것을 잘 알고 있습니다. 그렇기 때문에 프로젝트가 계약될 시점에 ‘유지보수'에 대한 항목을 보통 명시합니다. 유지보수 기간은 경우에 따라 다릅니다. 유지보수는 우리가 가전제품을 구매하면 AS 기간을 제공해주는 것과 같습니다. 자동차의 경우에도 신차 구매 기준으로 보통 2년 정도의 워런티 기간을 부여해줍니다. 이는 서비스의 차원이 아니라 완벽한 제품이 나올 수 없다는 한계를 인정하고 그에 대한 사후 관리를 해주겠다는 의미로 이해하는게 더 정확합니다. 결국 유지보수의 과정도 사업비에 포함되는 항목입니다. (우리가 구매한 전자제품이나 차량의 가격에 AS 비용도 이미 포함되어 있다고 생각해야 합니다. 잘 활용해야겠죠?)

프로젝트의 성격

네이버나 카카오 같은 회사(솔루션)들은 <비즈니스 관점에서의 개발 프로젝트 이해>에서 설명한 느낌과 다르지 않은가? 여기에선 다양한 회사의 성격을 알아야한다.

  • 솔루션 : 솔루션이라고 함은 기업에서 개발한 제품이다. 카카오톡이나 배달의 민족 애플리케이션이 대표적. 그 기업의 고유한 자산이자 매출의 원천이 된다. 완벽하게 올바른 의미는 아니지만 현 시점에서 말하는 ‘솔루션 개발 회사'는 이렇듯 우리의 솔루션을 개발하는 회사를 의미한다. 자체 서비스 개발 회사라고도 한다.

  • SI (System Integration) : 시스템 구축을 의미. 사실 기존의 SI 뜻은 요즘에 사용되는 SI와는 의미가 조금 달랐다. 예전에는 기업의 전산시스템을 구축할 때 자체적으로(외부의 힘을 빌리지 않고) 시스템을 구축했다. 하지만 시간이 흐르면서 시스템이 복잡해지고 더 높은 전문성이 요구됨에 따라 특화된 기업과 계약을 맺고 진행하는 형태로 발전하게 되었다. SI라는 의미 자체는 시스템을 구축하는 행위를 압축해서 표현함이 올바른 표현이다.

  • SM (System Management) : 시스템 운영 및 유지보수를 의미. 시스템 개발보다는 개발 완료되어 서비스되는 시스템을 관리하는 관리자로 운영에 초점이 맞춰진 형태를 뜻한다. 예로 들면 대기업 금융 회사의 전산실 업무 담당 등이 있겠다.

이런 식으로 여러가지가 있고, 솔루션 회사에 여러 SI, SM 직무를 도맡아 할 수도 있는 등 짬뽕이 될 수도 있다.
예를 들어, 리의 솔루션을 만들어 낸 A라는 회사가 있는데 이 솔루션을 원하는 다른 기업에 단순히 판매를 해서 사용하게 할 수 있지만 솔루션의 내용과 기능에 따라 그 기업에 특화되게 커스터마이징 해야 하는 경우도 있고(SI) 솔루션을 도입한 기업에서 특정 기간 동안 시스템 운영을 부탁(SM) 할 수 있다. 솔루션 회사에도 부분 수정 요청을 하거나 시스템 운영 계약을 맺을 수 있다는 의미다.

따라서, 두개의 항목 다 대략적인 정리라고 볼 수 있고, 시대에 따라 다르게 정의될 수도 있다. 또한 개발자는 개발만 하는 것이 아니라 하나의 사업 모델이라는 관점에서 그에 맞는 직무를 수행할 수 있는 역량을 키워야 함을 인지할 필요가 있다.

SRS

software requirements specification, 소프트웨어가 무엇을 할 것이며 어떻게 작동할 것으로 예상되는지를 설명하는 문서
제품이 모든 이해 관계자(비즈니스, 사용자)의 요구를 충족시키는데 필요한 기능을 설명

즉, SRS는 프로젝트의 전체적인 그림을 제공한다는 의미. RFP(Request For Proposal)를 통해 제안요청을 하고 프로젝트 계약이 완료되면 SRS(Software requirements specification)를 통해 프로젝트의 큰 그림을 설계한다.

구성

SRS는 아래 목차와 같은 템플릿으로 작성된다. 참조하자

  1. 소개
    1.1 목적 (Purpose)
    이 문서에 요구사항이 명시되어 있는 제품 또는 애플리케이션을 설명한다. 이 SRS가 전체 시스템 중 일부에만 관련된 것이라면 그 부분 또는 하위시스템을 설명한다.
    1.2 문서 규칙 (Document Convention)
    텍스트 스타일, 하이라이트 또는 주석과 같은 모든 표준 또는 표기규칙을 설명한다.
    1.3 독자대상과 읽는 방법 (Intend Audience and Reading Suggestion)
    SRS가 대상으로 하고있는 다양한 독자계층을 나열한다. SRS의 나머지 부분과, SRS가 조직되어 있는 방법을 설명하고, 각각의 독자 계층에 대해 가장 적합한 읽기 순서를 설명한다.
    1.4 프로젝트 범위 (Project Scope)
    설명되고 있는 소프트웨어와 그 목적에 대해 간단하게 설명한다.
    1.5 참조 (Reference)
    이 SRS가 참조하고 있는 모든 문서 또는 다른 리소스를 나열하며, 가능한 경우에는 하이퍼링크도 포함시킨다.

  2. 전체 설명 (Overall Description)
    2.1 제품조망 (Product Perspective)
    제품의 구성과 유래를 설명한다. 제품이 확장되는 제품군의 다음 구성제품인지, 완성된 시스템의 다음 버전인지, 기존 애플리케이션을 대체하는 것인지, 완전히 새로운 제품인지를 설명한다.
    2.2 제품 기능 (Project Feature)
    제품이 가지고있는 주요기능 또는 제품이 수행하는 중요한 기능을 나열한다. 요구사항의 주요 그룹과 그 그룹이 연결되어 있는 방법을 설명하는 최상위 데이터 플로우 다이어그램, 유스케이스 다이어그램, 클래스 다이어그램 등이 도움이 된다.
    2.3 사용자 계층과 특징 (User Classes and Characteristic)
    이 제품을 사용할 것으로 예상되는 사용자계층을 파악하고 그들의 특징을 설명한다.
    2.4 운영 환경 (Operation Environment)
    하드웨어 플랫폼, 운영체계와 버전, 사용자, 서버와 데이터베이스의 지리적 위치 등과 같은 소프트웨어가 동작되는 환경을 설명한다. 시스템이 아무런 문제없이 연동해야 하는 다른 소프트웨어 컴포넌트 또는 애플리케이션을 나열한다.
    2.5 설계 및 구현 제약사항 (Design and Implementation constraint)
    개발자가 선택할 수 있는 사항을 제약하는 모든 요소와 각 제약조건의 이유를 설명한다. 제약 조건은 다음과 같다.

    • 반드시 사용하거나 피해야 하는 기술, 툴, 프로그래밍 언어와 인터페이스.
    • 사용될 웹 브라우저의 유형과 버전과 같이 제품의 운영환경으로 인한 제약.
    • 필요한 개발 규칙 또는 표준(예를 들면 고객의 조직이 소프트웨어를 유지보수 할 예정이라면, 그 조직은 하청업체가 따라야 하는 설계 표기법과 코딩 표준을 명시 할 수 있다.)
    • 이전 제품과의 호환성.
    • 비즈니스 규칙에 따른 제약.
    • 메모리 또는 프로세스의 제약, 크기, 무게, 비용과 같은 하드웨어의 제약.
    • 기존 제품을 개선하는 경우에 따라야 하는 기존 사용자 인터페이스 규칙.
    • XML과 같은 표준 데이터 교환 형식.

2.6 사용자 문서 (User Documentation)
소프트웨어와 함께 제공할 사용자 문서를 나열한다. 사용자 문서로는 사용자 메뉴얼, 온라인 도움말, 교재 등이 있으며 따라야 하는 문서 전달 형식, 표준 또는 툴이 있다면 그것들을 설명한다.
2.7 가정과 종속관계 (Assumptions and Dependencies)
가정이 잘못되거나 이것을 공유하지 않는다면 문제가 발생될 수 있기 때문에 어떤 가정은 프로젝트 위험으로 간주된다. 프로젝트가 통제할 수 없는 외부 요소에 어느정도 종속되는지 또한 설명해야 한다.

  1. 시스템 특징 (System Feature)
    3.1 시스템 특징
    가. 설명과 우선순위 (Description and Priority)
    기능에 대해 간단하게 설명하고 그것이 높은 우선순위인지 낮은 우선순위인지를 나타낸다. 우선순위는 프로젝트 중에 변할 수 있는 동적인 것으로, 요구사항관리 툴을 사용한다면 요구사항 특성의 우선순위를 정의한다.
    나. 자극/응답 순서 (Stimulus / Response Sequence)
    입력 자극(사용자 행동, 외부 장비의 신호 또는 다른 자극)의 순서와 이 기능에 대한 동작을 정의하는 시스템 반응을 나열한다.
    다. 기능 요구사항 (Functional Requirement)
    이 기능과 관련된 상세한 기능 요구사항을 항목으로 나열한다. 이것들은 사용자가 기능의 서비스를 수행하기 위해 또는 유스케이스를 수행하기 위해 사용하는 소프트웨어의 기능들이다.

  2. 외부 인터페이스 요구사항 (External Interface Requirement)
    4.1 사용자 인터페이스 (User Interface)
    시스템이 요구하는 각각의 사용자 인터페이스와 논리적인 특징을 설명한다. 따라야 할 GUI 표준 또는 제품 스타일 가이드에 대한 참조.

    • 폰트, 아이콘, 버튼 레이블, 이미지, 색상 체계, 필드탭 순서, 공통으로 사용되는 컨트롤 등에 대한 표준.
    • 화면 레이아웃 또는 해상도 제약 조건.
    • 도움말 버튼과 같이 모든 화면에 나타나는 표준 버튼, 기능 또는 탐색 링크.
    • 단축키.
    • 메시지 표시 규칙.
    • 소프트웨어 번역을 원활하게 하는 레이아웃 표준.
    • 시각장애자를 위한 기능.
    • 사용자 인터페이스 설계 상세 내용은 SRS가 아닌 별도의 사용자 인터페이스 명세에 문서로 정리한다.

4.2 하드웨어 인터페이스 (Hardware Interface)
시스템의 소프트웨어와 하드웨어 컴포넌트간의 모든 인터페이스의 특징을 설명한다. 설명에는 지원되는 장비 유형, 소프트웨어와 하드웨어간의 데이터와 컨트롤 연동, 사용될 통신 프로토콜 등이 포함된다.
4.3 소프트웨어 인터페이스 (Software Interface)
이 제품과 다른 소프트웨어 컴포넌트(데이터베이스, 운영체제, 툴, 라이브러리, 통합 상업용 컴포넌트)간의 연결을 설명한다. 소프트웨어 컴포넌트 간에 교환되는 메시지, 데이터와 컨트롤 항목을 설명한다.
4.4 통신 인터페이스 (Communication Interface)
이메일, 웹 브라우저, 네트워크 통신 프로토콜, 전자 문서와 같이 제품이 사용할 모든 통신 기능에 대한 요구사항을 설명한다. 관련된 모든 메시지 형태를 정의하고 통신 보안 또는 암호화 문제, 데이터전송률과 동기화 메커니즘을 명시한다.

  1. 기능 이외의 다른 요구사항 (Other Nonfunctional Requirements)
    5.1 성능 요구사항 (Performance Requirement)
    다양한 시스템 운영에 대한 특정 성능 요구사항을 설명한다. 개발자들이 적합한 설계를 선택할 수 있게 만든 논리를 설명한다.
    5.2 안전 요구사항 (Safety Requirement)
    반드시 방지해야 하는 잠재적으로 위험한 행동 뿐만 아니라 반드시 취해야 할 모든 안전장치 또는 행동을 정의한다. 제품이 따라야 하는 보안인증, 정책 또는 규제를 정의한다.
    5.3 보안 요구사항 (Security Requirement)
    제품에 대한 접속과 제품사용에 영향을 미치는 보안, 무결성 또는 사생활 문제, 제품이 사용하거나 만드는 데이터 보호를 모두 명시한다.
    5.4 소프트웨어 품질 특성 (Software Quality Attribute)
    고객 또는 개발자에게 중요한 모든 별도의 품질 특성을 설명한다. 이런 특성들은 명확하고 계량적이며 확인이 가능해야 한다.

  2. 다른 요구사항 (Other Requirement)
    SRS의 다른 부분에서는 다루지 않는 모든 요구사항을 정의한다.

SRS 분석 이후

설계도와 어떻게 프로젝트가 전개되는지 알았다. 개발 작업은 어떻게 구성되는지 각 단계별로 실행해야 할 목록을 문서화 하는 과정을 통해 알아보도록 하자.

일단 그 전에 SRS로 설계와 도입이 끝났다면, 개발할 소프트웨어를 분석하는 과정이 필요하다. 그 단계를 거쳐야한다.

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

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

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

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

작은 프로젝트거나 비즈니스가 포함되지 않았다면 축소해서 해도 된다. 나도 그러기에 여기선 축소해서 하지만 제일 중요한 '사용자 요구사항 정의서'를 빼먹으면 안좋기에 한번 알아보자.

사용자 요구사항 정의서

분석 단계에서 가장 중요한 분석 양식인 사용자 요구사항 정의서를 정의해보자.

1. 작성 목적

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

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

2. 작성 방법

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

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

3. 항목 설명

  • 요구사항 ID : 요구사항별로 유일한 ID를 부여하여 기입.
  • 요구사항명 : 도출된 요구사항을 요약할 수 있는 명칭을 기입.
  • 구분 : 도출된 요구사항을 기능 / 성능 / 품질 / 인터페이스 / 데이터 / 운영 / 제약사항 중에서 선택하여 기재.
  • 요구사항 설명 : 사용자 요구사항을 구체적이고 상세하게 기술.
  • 중요도 : 해당 요구사항의 전체 시스템 구현 측면에서의 중요도를 기술. (상, 중, 하)
  • 비고 : 항목에 포함되지 않으나, 고려해야 할 사항이 있으면 기술.

좋은 요구사항 명세서가 가지고 있는 특징

  • 요구사항 명세서를 읽는 작업자(개발자, 디자이너 등)가 이해하기 쉬워야 한다.
  • 무엇을 어떻게 구현되어야 하는지 명확하게 작성한다.
  • 하나의 요구사항에 여러가지(복수) 요구사항을 작성하지 않는다.
  • 다른 요구사항 모순 또는 중복되지 않게 한다.
  • 애매한 단어를 사용하지 않고 명확하게 기재한다. ( ~ 있으면 좋겠다 → ~ 기능 필요) 오해하지 말아야 할 것이 명령하는 것이 아니고 의견을 모호하게 하지 말고 명확하게 표현하라는 의미이다.
  • 꼭 필요하고 중요한 요구사항은 표시하는 것이 좋다. 다만 모든 요구사항에 남발 해서는 안된다.
  • 동일한 용어를 사용한다. 댓글, 코멘트, 덧글과 같이 모두 같은 의미를 다르게 표현하지 말라는 의미이다.
  • 난이도가 있는 기능이거나 프로젝트 기간이 짧아 모든 요구사항을 구현하기 어려울 상황일 경우, 대체 가능한 다른 방법도 함께 기술하여 전달하는 것이 좋다.

설계 단계

분석 단계에서는 사용자 요구사항을 파악해 작성했다. 이제 넘어와 설계 단계 중 가장 중요한 화면 정의서, 테이블 설계서, API 명세서의 작성 방법들을 알아보자. 우린 개발자이기에 구현에 들어가는 설계도를 작성하듯이 꼼꼼하게 체크하여 최대한 구현 가능한 수준으로 설계하는 과정이 필요하다.

여기도 비즈니스가 중요하지 않다면 아래 3개 항목만 해도 무방하다. 물론 비즈니스가 들어가고 규모가 커진다면 제대로 써야겠지?

화면 정의서

1. 작성 목적

시스템이 제공하는 사용자 인터페이스의 전체 구조와 메뉴 형식, 화면 목록과 화면의 상세 설계 내역을 기술한다.

NIA(한국정보화진흥원)에서는 화면 정의서의 작성 목적을 위와 같이 정의하고 있다. 작성할 부분이 상당히 많은 문서지만 매우 중요한 설계 단계 문서이므로 어떻게 작성하는지 직접 경험해보고 해당 문서를 구현 단계에서 활용하여 개발 할 수 있는 것에 목표를 두면 좋다. 잘 사용할 수 있게 부담없는 걸로 커스터마이징도 가능!

2. 작성 방법

전체 시스템에 대한 사용자 인터페이스의 구조를 사용자에게 제공하는 메뉴 형식으로 기술하고, 화면 및 출력으로 구분하여 목록을 작성하며, 화면의 상세 설계 내용을 화면별로 기술한다.

화면을 쉽고 편리하게 그릴 수 있는 툴을 사용하여 예상하는 화면을 그리고 예상 화면을 문서에 삽입 한 후, 화면에 대한 설명을 추가하여 하나의 화면 정의를 한다. 각 화면에는 화면 아이디를 부여하여 해당 화면을 쉽게 구분할 수 있게 하자. 또한 화면에서 기능 동작에 대한 정의를 함께 표시한다. 해당 동작은 앞서 작성한 사용자 요구사항 정의서의 아이디를 부여하여 두 문서가 연관성을 갖게 한다.

3. 항목 설명

  • 화면 ID : 설계된 화면에 고유값을 부여.
  • 화면명 : 알아볼 수 있는 화면에 대한 제목을 부여.
  • 화면 유형 : 입력 / 출력 중 알맞은 유형을 선택, 기타 유형이 존재한다면 알맞게 작성하자.
  • 메뉴 경로 : 해당 화면이 서비스의 어디에 위치하는지 설명.
  • 화면 개요 : 화면의 간단한 설명을 추가.
  • 화면 미리보기 : 와이어 프레임과 같은 화면 설계 툴을 사용하여 작성된 화면 미리보기 이미지를 삽입하고 해당 화면에서 기능을 수행하는 항목을 번호를 매겨 표시.
  • 기능 번호 : 화면 미리보기에서 표시된 기능의 번호를 기입.
  • 요구사항 아이디 : 해당 기능이 사용자 요구사항 명세서에 기술된 어떤 항목인지를 아이디로 표시.
  • API 활용 여부 : 이 기능이 API를 활용하는 기능인지를 구분.
  • API 주소 : API 활용 여부가 YES라면 어떤 API를 호출하는지 기입.
  • 유효성 체크 : 기능이 동작하는 동안 화면 내에서 필수적으로 사용되어야 할 데이터에 대한 유효성 체크를 한다.
    예) 회원 가입을 할 때 아이디와 비밀번호는 필수로 작성되어야 한다. → 아이디, 비밀번호 기입

테이블 명세서

1. 작성 목적

최종적으로 설계된 테이블과 인덱스를 데이터베이스 공간에 맵핑시키고 저장공간 등의 물리 모델을 기술한다.

작성할 부분이 상당히 많은 문서지만 매우 중요한 설계 단계 문서이므로 어떻게 작성하는지 직접 경험해보고 해당 문서를 구현 단계에서 활용하여 개발 할 수 있는 것에 목표를 두면 좋다.

2. 작성 방법

부서에서 운영하는 데이터베이스 목록을 작성하고, 데이터베이스의 물리적 상세내용을 기술한다.

서비스에서 사용될 테이블을 미리 설계하고 그 내용을 문서화. 구현 단계에서 개발이 진행됨에 따라 테이블 설계서의 내용이 일부 변경될 수 있는 점은 감안하고 작성한다. 다른 문서에 비해 상대적으로 작성하기 쉬울 수 있다. 데이터베이스를 개발 학습시에 많이 다뤄 보았고 개발시 머릿속으로 데이터의 입출력에 대한 고민을 많이 해 보았기 때문이다. 학습이나 개발했을 때를 떠올리며 어떤 테이블을 설계하고 각 테이블이 어떤 관계를 이루는지에 대해 고민하여 설계한다면 많은 도움이 될 수 있다.

3. 항목 설명

  • 데이터베이스 명 : 데이터베이스 명칭을 기입.
  • 테이블 명 : 테이블 명칭을 기입.
  • 요구사항 ID : 테이블이 사용되는 요구사항 정의서의 ID를 맵핑.
  • 테이블 설명 : 테이블의 목적 및 역할을 간략하게 기술.
  • 컬럼명 : 테이블 컬럼의 내용과 특성을 인식할 수 있는 명칭을 기술.
  • 컬럼 ID : 테이블 컬럼 ID를 기술.
  • 타입 및 길이 : 컬럼의 타입과 최대 허용 길이를 기술.
  • NOT NULL : 필수항목 여부를 나타냄.
  • PK (Primary Key) : 주키 여부를 나타냄.
  • FK (Foreign Key) : 외래키를 의미.
  • INX (Index) : 인덱스를 의미.
  • 기본값 : 속성의 기본값이 있는 경우에 그 값을 기술.
  • 제약조건 : 속성의 특이한 제약조건이 있는 경우 기술.

API 명세서

API를 정의하려면 RESTful API를 좀 짚고 넘어가야한다.

REST API

REST(Representational State Transfer) API(Application Programming Interface)
미디어, DB 데이터 등 모든 자원을 의미하는 리소스에 대해 고유한 URI를 부여하고 HTTP Method를 적절히 사용하여 리소스를 제어할 수 있는 수단

여기서 REST API는 URI(URL)로 리소스를 제어한다고 했다. 거기도 좀 짚고 넘어가자

URI의 구성요소

scheme:[//[user[:password]@host[:port]][/path][?query][#fragment]
  • scheme : http 또는 https를 사용합니다.
  • user, password : 데이터가 있는 서버에 접근하기 위해 필요한 ID와 PASSWORD
  • host, port : 서버의 호스트와 포트 번호
  • path : 서버의 상세 경로
  • query : path에 접근하기 위한 추가 정보 (파라미터)
  • fragment : 메인 리소스 내에 존재하는 서브 리소스에 접근할 때 식별하기 위한 정보

관계 나타내기

http://test.com/groups/1/users
  • groups, users : 이와 같이 복수로 표현되는 것들은 보통 여러개의 리소스를 갖을 수 있으므로 복수형으로 표시하고 ‘Collection’ 이라고 부른다.
  • 1 : Collection에 포함된 대상 리소스는 단수형으로 표시하고 ‘Document’라고 부른다.
  • /groups/1/users : Collection과 Document의 관계를 /를 통해 나타낼 수 있다. 그룹이라는 Collection 안에 ‘1’ Document를 나타내고, 해당 Document가 갖고 있는 사용자들을 나타낸다.

특징

HTTP Method로 주고받는 REST API의 특징도 복습하자

  • 서버-클라이언트 구조 (Server-Client Architecture)
  • 무상태성 (Stateless)
  • 캐시 가능 (Cacheable)
  • 일관된 인터페이스 (Uniform Interface)
  • 자체적인 표현 구조 (Self-Descriptiveness)
  • 계층 구조 (Layered System)

규칙

HTTP Method를 바탕으로 한 API 명세서 작성법

  • GET : Query의 ‘SELECT’에 해당한다.
  • POST : Query의 ‘INSERT’에 해당한다.
  • PUT : Query의 ‘UPDATE’에 해당한다.
  • DELETE : Query의 ‘DELETE’에 해당한다.

이런 식의 서류 작성을 거쳐 프로젝트를 만든다면 더 효율적으로, 더 빠르게, 더 손쉽게 개발이 가능하다. 이러한 것들을 알아서 조금의 서류 작성을 끝낸 뒤 피그마 등으로 설계하고 깃헙, 칸반 등을 이용한 개발자의 프로젝트 준비를 통해 구현을 준비해보자.

profile
코뿔소처럼 저돌적으로

0개의 댓글