[F-Lab 모각코 챌린지] 64일차 - 프로젝트 준비 방법
F-Lab 모각코 챌린지 64일차 - 프로젝트 준비 방법. 실용주의 프로그래머에서 소개하는 프로젝트 준비 시 고려 할 만한 사항들 입니다. '칠판', '요구사항 정의' 방법들의 사용법을 소개합니다
![[F-Lab 모각코 챌린지] 64일차 - 프로젝트 준비 방법](/content/images/size/w1200/2023/07/f_lab_mogacko-9-15.png)
칠판
정보들을 '칠판' 에 적고 해당 정보들의 조합으로 문제의 해결 방안을 도출해라
칠판의 적용 방법
- 현재 가지고 있는 가장 큰 문제를 적는다
- 그 문제의 다른 정보들을 수집하여 그 주변에 기록한다
- 2번 에서 적은 정보들의 연관관계를 찾아내거나 자신의 추측, 관찰을 적어본다
- 1번에서 기록한 문제 해결을 위해 다른 여러 사람들의 정보나 조언을 기록하고, 연관 관계를 찾고 추측하고 문제의 해결 방법을 찾는다
요구사항의 구렁텅이
완성 이라는 것은 더 이상 더할 것이 없을 때가 아니라, 더 이상 빼낼 것이 없을 때 얻게 되는 것이다
요구사항은 수집하는 것이 아니라 채굴하는 것이다
비 개발자의 요구사항은 가정과 오해, 정치의 지층들 속 깊히 묻혀져 있기 때문이다
요구사항 채굴하기
진정한 요구사항은 어떤 것이 성취되어야 한다는 진술 이라는 것이다
다음의 말을 생각해보자
해당 직원의 관리자와 인사부에서만 그의 기록을 열람할 수 있다
이 진술은 요구사항일까?
이 진술 속엔 비즈니스 정책이 내포되어 있다. 정책은 수시로 바뀐다. 따라서 요구사항 속에 그걸 고정하는 건 그리 좋은 생각이 아니다
사용자의 말은 요구사항 일 수도 있고, 그 기능을 설명하기 위해 자신이 알고 있는 비슷한 동작의 전혀 다른 기술의 이름을 말 할 수도 있다.
사용자들이 어떤 말을 어떻게 하느냐 보다, 왜 그 말을 했는지 내재적 이유를 알아내는 것이 더 중요하다
사용자 처럼 생각하기 위해 사용자와 함께 일하라
요구사항 문서화
전문가라면 사용자가 말한 요구사항들을 기록해서 토론 할 때 기초 자료로 사용할 수 있도록 문서화 하려 할 것이다
잘 알려진 몇가지 문서화 방법들을 소개한다
유스케이스
이바 야콥슨은 요구사항을 갈무리하는 유스케이스 개념을 제안했다.
- 시스템의 특정한 사용
use
를 설명한다 - 사용자의 인터페이스 차원에서가 아니고, 좀더 추상적인 차원에서 유스케이스를 정의한다
사용하는 사람의 손에 적응할 수 있어야 성공적인 도구다
유스 케이스 템플릿
유스케이스를 보는 하나의 관점은 목적 지향성을 강조하는 것이다
앨리스 테어 코번은 이 접근법을 설명하는 논문을 썼는데, 여기에는 함께 사용할 수 있는 템플릿도 있다
아래는 그 템플릿 이다
코번의 유스케이스 템플릿
A. 특징적인 정보
- 맥락 안에서의 목표
- 범위
- 수준
- 선행조건
- 성공적인 종료 조건
- 실패로 간주할 종료 조건
- 주행위자
- 발동 조건
B. 주된 성공 시나리오
C. 확장된 경우들
D. 변이된 경우들
E. 관련 정보
- 우선순위
- 수행 목표
- 빈도
- 상위 유스 케이스
- 하위 유스 케이스들
- 주행위자와 상호작용하는 수단
- 부행위자들
- 부행위자들과 상호작용하는 수단
F. 일정
G. 해결되지 않은 문제
유스케이스 다이어그램
작업 흐름workflow
는 UML 활동 다이어그램으로 갈무리를 할 수 있다
어떠한 표기법에 얽메이지 말고 여러분의 청중과 요구사항을 가장 잘 소통할 수 있는 방법이라면 무엇이든 사용하도록 하라
지나치게 자세한 명세
요구사항 문서를 만들 때 생기는 큰 위험은 지나치게 자세히 서술하는 것이다
요구사항은 아키텍처가 아니다. 요구사항은 설계가 아니며, 사용자 인터페이스도 아니다. 요구사항은 필요다
더 멀리보기
우리는 Y2K 문제에 관해, 몇 바이트를 아끼려고 전전긍긍하던 근시안적인 프로그래머들을 종종 비난한다
하지만 그건 시스템 분석가와 설계자의 문제라고 할 수 있다. Y2K 문제는 대략 두 가지 주요 원인에 의해 발생했다
- 현 비즈니스 관행 너머를 보는 데 실패했다
- DRY 원칙을 어겼다
업계에서는 컴퓨터가 등장하기 한참 이전부터 연도를 두 자리로 줄여 사용하고 있었다.
아키텍처가 자료 입력, 보고, 저장 등을 위해 두 자리 숫자 년도를 필요로 했을지라도, 두 자리 숫자가 실은 날짜를 줄여 쓴 것이라는 사실을 '알고있는' DATE 라는 추상화가 있어야 했다
구체적인 것보다 추상적인 것이 더 오래간다
"그럼 이 장은, 미래를 예측 하라는 말인가?"
아니다.
요구사항은 단지 날짜가 사용된다는 것만 명시할 것이다
아마도 날짜 관련 수학 연산이 필요할 것이라는 암시가 있을 수도 있다
혹 다양한 형태의 이차 저장 장치에 날짜가 저장될 수도 있다고 말해주는지 모른다.
이런 것들이 DATE 모듈 혹은 클래스의 진정한 요구사항이다
용어 사전 유지하기
프로젝트 용어 사전을 만들고 유지하라
프로젝트에 참가하는 모든 사람이 일관성을 위해 동일한 용어 사전을 사용해야 한다
말을 끄집어내라
웹에 배포하면 우리는 각 독자가 원하는 것을 줄 수 있다
프로젝트 후원자들은 비즈니스 목표가 충족 되었는지 확인하기 위해 매우 높은 추상 차원에서 이리저리 항해해 볼 수 있다