DA 3일차 - 요구사항

요구사항

요구사항이란 ?

요구사항이란, 비즈니스 Needs를 해결하기 위해서 새로운 무엇을 사용해야 하는데 그 무엇은 어떻게 생겨야 하고 어떻게 사용할 수 있어야 하는가? 에 대한 서술

요구사항에 대한 서술이 부실하면 비즈니스 Needs를 해결할 수 없고 결국 프로젝트는 실패한 것으로 평가

 

요구사항 정의서

추적성 제공 → 요구사항과 개발 산출물, 단계별 산출물 관계 파악

범위 기준선 제공 → 요구사항 수집, 범위 정의, WBS 작성

일정과 원가에 영향 → 요구사항명세서, 범위기술서 작성의 입력물

요구사항 정의서의 어려움

• 요구사항 도출의 어려움 → 도메인에 대한 이해 부족, 의사소통에 관한 일반적인 문제
• 요구사항과 기대의 차이 → 묵시적인 요구사항
• 요구사항 변화관리의 어려움 → 무분별한 요구사항 변경 / 변경 추적 및 대응 체계 필요 : 요구사항 추적표가 그래서 필요해 !

요구사항 정의는 한달에서 한달반정도 진행해 ! (5분의 1 선에서 끝낸다 요구사항 정의를!!)

 

요구사항 수집 및 분석 절차

 

요구사항 수집 → 설문지는 잘 안함 (주로 인터뷰) 

요구사항 명세 → e.g., 첨부파일을 하고 싶다, 그러면 어떻게 할 것인지 !!

제대로 하지 않으면 요구사항 검증 (요구사항 내부 검토 필요 및 요구사항 고객 review 는 필요하다!!)

변경관리 → 변경관리 내의 요구사항 이관 (고객들에게 요구사항을 하나 빼겠습니다 하는것은 하나 더 받겠다는 의미)

 

수집기법

 

 

수집기법 - 인터뷰 가이드라인

• 누구(WHO) : 누가 참여하고 그들의 기반 지식 정도는?
• 무엇(WHAT) : 고객이 요구하는 것이 무엇인가?
• 언제(WHEN) : 시스템 또는 데이터가 언제부터 서비스 되어야 하는가?
• 어디(WHERE) : 어떤 환경에 적용될 것 인가?
• 왜(Why) : 요구사항이 나오게 된 사유는 어떠한가?
• 어떻게(HOW TO) : 어떤 기능을 수행할 것이며 제약조건은 무엇인가?

인터뷰 계획

• 인터뷰를 시작하기 전에 분석가는 사전 준비를 해 두어 기본 지식을 가지고 인터뷰를 들어가야 한다.
• 인터뷰의 목적을 확립해야 한다.
• 누구를 인터뷰할 것인가를 결정해야 한다.
• 인터뷰에 응하는 사람이 준비할 수 있도록 사전에 통보해 주어야 한다.
• 인터뷰하기 이전 질문의 유형과 질문의 구조를 준비해 두어야 한다.

요구사항 분석

• 시스템 목표를 확립하는 과정을 요구사항 분석과정이라 하며, 요구사항 분석은 행동을 취하기 전 문제에 대하여 연구하는 것
• 요구사항 분석은 시스템이 만족시켜야 할 요구사항의 발견, 정제, 모델링, 그리고 명세화하는 과정

요구사항 분석의 특징

• 소프트웨어 시스템의 요구사항 분석은 설계, 코딩 및 시험과는 다른 특징을 많이 가지고 있으며, “어떻게(how to)” 가 아니라
  “무엇(what)”에 초점이 맞춰져 있다.
• 요구사항 분석은 개발과는 다르게 고객들과 협상하여 공동의 목표를 끌어내야 한다.
• 요구사항 분석은 성공을 목표로 한다기 보다는 실패나 실수를 방지하고 프로젝트 초기 단계의 중대한 실수를 최소화하는 데 그 목적

요구사항 분석가의 자질

• 비즈니스나 응용분야에 대한 지식이 필수적이다.
• 하드웨어, 소프트웨어를 포함한 컴퓨터에 대한 기술을 이해하고 있어야 한다.
• 의사소통(Communication)능력
• 사용자들로부터의 모순되는 요구사항을 해결해야 한다.
• 시스템을 만들어야 하므로 상대의 관점(고객의 관점)에서 문제를 볼 수 있는 눈이 필요

요구사항 분석가의 입무

• 사용자는 익숙하지 않은 컴퓨터 전문용어를 불편해 하므로 분석의 결과를 쉬운 용어로 설명해야 함.
• 시스템 개발의 최전방에 앞장서 나가야 하는 역할 이므로 주도적으로 일을 처리해야 함.
• 사용자의 요구사항과 전문지식을 뽑아내는 일을 해야 함.

요구사항 분석의 어려움

• 의사소통 문제
• 요구사항의 계속적인 변화
• 분석도구의 미비
• 문서화의 어려움
• 정치적인 문제
• 일 할당 문제

요구사항 분석의 기본 원칙

• 분석 방법들은 시스템의 계층적이며 구조적인 표현을 가능하게 한다.
• 분석 방법들은 외부(사용자)와의 인터페이스는 물론, 시스템 내부 구성요소들 사이의 인터페이스에 대한 세심한 주의를 필요로 한다.
• 또한 분석 방법들은 분석 이후 단계인 설계와 구현 단계에 필요로 하는 기본 틀을 제공해 준다.
• 정형 명세 언어 이외의 다른 분석 방법

요구사항 명세 만족조건

• 요구사항 명세서는 고객과 개발자 모두 쉽게 이해할 수 있도록 만들어져야 한다.
• 요구사항 명세서에 명시되어 있는 조건들은 고객과 개발자가 동의한 것이어야 한다.
• 요구사항 명세서는 제안된 시스템이 수행할 모든 기능을 명확하게 기술해 놓아야 한다. 시스템이 수행할 기능은 요구사항 명세서의 핵심이다.
• 제안된 시스템에 영향을 미치는 모든 제약조건을 요구사항 명세서에 명시하여야 한다.
• 시스템을 사용하기 위해 필요한 조항들을 검증할 수 있도록 요구사항 명세서에 검증기준을 제시하여야 한다.
• 원하는 시스템의 품질, 상대적인 중요선, 품질의 측정 및 검증 방법 등을 요구사항 명세서에 명시하여야 한다.
• 시스템의 포용성과 오류 조건의 명시되어야 한다.

요구사항 검증

• 사용자 요구가 요구사항 명세서에 올바르게 기술되었는가에 대해 검토하는 활동
• 요구사항이 사용자나 고객의 목적을 완전하게 기술하는가?
• 요구사항 명세가 문서 표준을 따르고, 설계 단계의 기초로 적합한가?
• 요구사항 명세의 내부적 일치성과 완정성이 있는가?
• 기술된 요구사항이 참여자의 기대에 일치하는가?

: 고객이 이야기 한 내용이 다 들어가있나 / 설계 된 내용이 다 들어갔나 / 설계된 것을 개발자들이 개발할 수 있나

 

데이터베이스의 설계

구현 단계에서 사용되는 세 가지 데이터 모델 : 관계 데이터 모델, 계층 데이터 모델, 네트워크 데이터 모델

 

 

DB 설계 시 고려할 점 - M.T.S 체크 ! 

 

M (Master)  - 데이터베이스 설계/ 분석 및 트랜잭션 분석의 기본이고, 요구사항 분석에서 가장 먼저 식별해야한다.

T (Transaction) - M(Master) 들 간의 관계  / 행위자가 하는 행위의 결과 부분 / 상품을 구매하는 주문행위 

S (Statistic) - 운영 시스템의 데이터를 바탕으로 현황파악, 각종 분석/예측 및 AI 알고리즘에 적용하기 위해 만들어지는 재가공 정보

 

예시 : 

TVING 을 설계하기 위해서는 ? (하나의 서비스를 정해서 데이터 설계를 해보는 연습을 해보기!)

 

• 가장 중심으로 밀고 싶은 배너를 가장 크게 나오도록 한다.
• 티빙에는 다양한 컨텐츠들이 존재한다.
• 티빙 홈페이지 상단에는 시리즈, 영화, 라이브, 파라마운트, kbo 로 구분이 된다.
• (해당 컨텐츠를 대분류라고 할 수 있음)
• 검색 버튼을 통해 다양한 컨텐츠를 검색할 수 있다.
• 이모티콘을 누르면, 마이 상세 페이지로 연결된다.
• 티빙 첫 화면에는 유효한 배너가 슬라이드 형식으로 표시된다.
• 배너마다 이미지가 노출되고, 배너 클릭 시 해당 컨텐츠로 이동이 된다.
• 컨텐츠 시리즈 별 각각의 중분류가 존재한다.(시리즈 내 드라마, 예능, 애니메이션, 키즈, 미국시리즈, 영국시리즈, 중국시리즈, 일본시리즈, 해외시리즈)(오늘의 티빙 top 20, 인기 시리즈 컨텐츠, 실시간 인기, 등등)
• 각 시리즈 구분별 값 내에 컨텐츠 헤더 별 주제 제목이 존재한다.
• 지금 방영 중인 인기 시리즈 컨텐츠가 노출된다.
• 주제 카테고리 별 컨텐츠가 노출된다.
• 실시간 인기 시리즈, 새로 공개된 시리즈 컨텐츠가 노출된다.
• 각 컨텐츠 별 방영 시작일시 및 제목, 이미지가 노출된다.
• 각 컨텐츠 회차 별 제목과 내용이 존재한다.