1-4 진행에 해야 할 프로젝트의 사용자와 시스템에 관계

우리가 현재 진행하고 있는 프로젝트는 문서 관리(게시판)입니다.

기존에는 수기로 작성되던 문서를 시스템에서 작성하고 사용할 수 있게 하는 게 우리에 목표입니다.

최종적인 목표는 웹환경에서 구동되는 게시판입니다.

그러기 때문에 사용자가 어떠한 입력을 하고, 시스템은 어떠한 반응을 보이고, 어떠한 처리를 해야하는지

파악하기 위해서 작성된 문서 입니다. 이름하여 SRS(System Requirement Specification)입니다.

이것을 작성해서 사용자가 입력해야 할 것들을 정의하고, 시스템은 무슨 처리를 해야하고 무엇을 사용자에게

보여줄 것인지 생각하면서 작성하셔야 합니다.

Vision Document는 이해가 되지 않을 부분은 없다고 생각합니다. 그러한 이유는 특별한 지식이 없어도 읽을 수 있게 작성

되기 때문입니다. 프로젝트의 목적과 사업성 및 그 프로젝트가 가지고 있는 기능 이것이 핵심내용이기 때문입니다.

하지만 SRS는 어느정도 시스템을 알아야하기 때문에 선수지식이 살짝 필요합니다. 그렇다고 아키텍처를 적용한 상태가

아니기 때문에 자세한 시스템에 상황은 설명 되지 않습니다. 

나중에 애자일 방법론으로 적용해서 프로젝트를 진행할때는 다른 방식으로 진행하게 될거 같습니다. 이 부분에 약점은  

그때 가서 다시 한번 설명드리겠습니다

SRS에 자세한 내용은 문서를 통해서 확인하시고, 목차에 내용을 설명 드릴게요.

1. 프로젝트 개요 

 1.1. 목적 [프로젝트에 목적입니다. Vision Document의 내용과 유사합니다.]

 

 1.2. 범위 [프로젝트가 어디까지 진행 해야하는지 나타내는 것입니다.]

 1.3. 관계자 [프로젝트를 누가 진행 할것인지 담당자는 누구인지 이런것을 기록하는 항목입니다.]

2. 제약사항 & 전제 조건 [프로젝트에 제약 사항 및 전제조건 ex)빠른 속도와 웹 환경으로 를 기록하는 항목입니다.]

3. 위험 요소 [현재 프로젝트에 위험 요소가 무엇인지 ex)기술력이 충분하지 않음 를 기록하는 항목입니다.]

4. 기능적 요구사항 

 4.1. 주요 기능 [프로젝트의 목적에 맞는 기능을 기록합니다.]

 4.2. Actor [어떠한 사람이 프로젝트가 구현되어 있을때 사용하는지 기록하는 항목입니다. ex)관리자, 회원 .비회원] 

 4.3. 유즈케이스 [시스템과 사용자간에 입력과 출력 어떠한 것을 해야 할지 적는 항목입니다]

 4.4 응용 프로그램 

 4.5 기능성 요구사항 상세 [고객이 요구한 기능적 요구사항 ex) 글 삭제 기능이 필요해요 이런것을 적는 것입니다.]

5. 비기능성 요구사항 상세 [아키텍처적인 부분을 적는 항목입니다. ex)글을 읽을때 10초내에 화면에 출력되야합니다]

6. 용어집 [어려운 용어는 알기 쉽도록 설명을 달아줍니다.  ex)조회수: 사용자가 그 글을 읽은 수]

이러한 내용으로 구성됩니다.

사실 분석단계(Domain Model)에서는 소프트웨어적인 지식은 그다지 필요하지 않습니다. 지금 필요한 것은

소위 비지니스 로직(업무가 어떤식으로 돌아가는가)에 집중하고. 그것을 찾아내고 알아내는 단계입니다.

그러니까 너무 두려워마시고 진행하시면 됩니다.

다음에는 사용자와 시스템이 어떠한 흐름과 절차, 데이터를 주고 받는 지 알아 보기 위한

Analsys Sequence Diagram을 그려서 알아보도록 하죠

SRS_lectrue_board_v.1.0_2010_07_06_10_14.doc