'요구사항'에 해당되는 글 2건

  1. 2011.04.11 요구사항 정리(분석)
  2. 2011.04.11 설계 이전에 기능별 제안을 해라


예시) 요구사항정의예

보통 프로세스상에서 분석단계에 요구사항정리가 있다. 요즘은 이때 시작한다는 뜻으로 받아드리는것이 좋을듯 싶다.
요구사항은 프로젝트 끝날때까지 변동과 추가가 있기때문이다.
요구사항의 시작은 이해당사자들의 스케줄에 끌려가기 쉽다 분명한것은 우리는 당신을 도와 주는사람이라는 의식을 이들에게 심어줘야 한다는것이다.
믿음이 깨졌을때는 마지막까지 힘들어진다.
...싸워도 이사람과 하면 뭐라도 만들어지겠다는 믿음을 줘야 한다.
그뒤에 스케쥴을 나의것으로 만들어라 그리고 앞에서 리드해라 질문에대한답을 가지고 가라. 이답이 나올때까지 질문을 하라.
 
이해 당사자 마다 다른 질문과 정확한답을 준비해라 그리고 꼼꼼한 회의록을 배포하라.
정해진것은 주간업무보고와 추적표를 공포하라. 그리고 설계단계에 반영하고 요구사항의 ID 를 맞춰 이 기획이 어떤 요구사항의 결과 인것인지를 표시하라.

예시) 요구사항추적표

히스토리 관리도 꼭 필요한 부분이다.
모든 요구사항을 일별, 주별 관리하여 요구사항에대한 보고를 따로 진행해도 좋다.

감리가 있다면 무엇보다도 요구사항추적표를 정리해야 한다.
물론 감리때문이 아니고 검수를 위해서도 요구사항추적표는 필요한부분이다.

검수 시 검수 담당자는 요구사항추적표를 보고 검수를 진행 할테니....


Posted by 김상환

Posted by 기획에 대한 짧은 생각 웹디맨
Facebook 댓글

댓글을 달아 주세요




기획자들이 설계단계에서 가장 많이 실수 하는것이 화면설계서 하나로 커뮤니케이션을 하는데 있다. 
분명한것은 설계 이전에 제안이 있어야 한다. 
제안으로 각 담당자들의 의중과 담당자들이 원하는 건설팅을 해야 한다. 
모든 클라이언트는 이전과 다른, 경쟁업체와 다른 사이트 시스템을 원한다. 이런 충족이 없을때 그들은 설계서를 이해하지도 못할 뿐 아니라 믿음도 줄어들게 된다. 
적어도 중요한 시스템 기능에 대해서는 설계이전에 기획안을 PT 하고 그리고 화면흐름도와 같은 UML을 이용한 추가적인 설 계안으로 기본적인 초기설계를 완료해야 한다. 뒤에 화면설계서를 통해 클라이언트와 작업자들간의 커뮤니 케이션을 진행 하는것이다. 

기획자들이여 설계는 제안 이후에 진행하라.


Posted by 김상환

Posted by 기획에 대한 짧은 생각 웹디맨
Facebook 댓글

댓글을 달아 주세요

이전버튼 1 이전버튼