요구사항에 근거한 평가   소프트웨어 프로젝트 팀들은 프로젝트 수행에 요구되는 노력, 시간 비용을 산정해야 한다. 이런 평가 작업은 특별한 해법도 존재하지 않는 골치아픈 과정이다. 여기서는 몇 가지 평가 접근 방법과 요구사항에 기초한 평가를 생성하는 세가지 기법을 소개한다.     평가의 몇 가지 기본원칙 평가란 주어진 정보와 지식, 특정 시점에서의 조건들을 바탕으로 하는 미래에 대한 예측이다. 예측이기 때문에 불확실성을 항상 포함한다. 프로젝트 관계자들은 프로젝트 초기에 정확한 평가를 요구하지만 이것은 불가능하다.     [그림1 - 요구사항 평가] 그림에서 보는 것과 같이 프로젝트를 완료할 확율은 5개월 이내는 10%이고, 10개월 이내는 30%이며 15개월에서야 비로소 80%이상이된다. 프로젝트 관리자에서 10개월이면 됩니다. 이렇게 콕 찍어서 말하자 마라. 만약 정확히 언제쯤 제품을 출시할 수 있을지 평가하여야 한다면 평가의 불확실성에 대한 완충치를 포함시켜야 한다.   평가 접근 방법 상향식 (Bottom-up)  : 각각 개별 요소의 요구사항, 임무, 작업내역 상의 납품물 또는 클래스, 프로그램 모듈, 테스트 케이스와 같은 항목의 개수를 정하고 이것을 모아서 평가한다. 이때 MS Project같은 툴을 이용해서 많이 했다.   하향식 (Top-down)  : 제품이나 프로젝트에 대한 전반적인 설명으로 부터 시작한다.  평가자는 유사 프로젝트 경험에 기초하여 전체 프로젝트를 수행함에 있어서 무엇이 필요한지 판단 한다. 이 같은 전반적인 평가를  근간으로 하여 하부 컴포넌트 크기 각 개별 요소개발에 필요한 노력, 시간, 비용등을 평가하게 된다.   비용 모델  : 많은 상용 평가 도구들을 이용할 수 있다. 뭔가 복잡한 모양이다. 제품 마다 프로젝트로 부터 파생된 알고리즘을 이용한다. 팀을 두 배로 꾸린다고 해서 일정이 절반으로 ...

보다 나은 요구사항의 비즈니스 가치 잘만들어진 요구사항은 어떤 가치를 가질까?   모든 관리자들이 요구사항 개발 이 요구사항 개발이나 관리에 대한 개선의 필요성을 인정하고 있지는 않다. Standish 그룹의 "CHAOS Reports"에서 지적하고 있는 프로젝트를 망치거나 힘들게 하는 세 가지 가장 큰 요인은 다음과 같다. 사용자 제공 정보의 부족 불완전한 요구사항 및 명세서 변화하는 요구사항 및 명세서 e-비즈니스에서의 성공 위협 요소 불안정하고 계속해서 변화하는 요구사항 ( 66% ) 미숙한 요구사항 명세 (55% ) 승인 지연, 요구사항 변경, 부족한 의사소통 등과 같은 고객의 행위(42%)           [표] 요구사항 결함의 상대적인 수정 비용  오류 발견 시점  상대적인 수정 비용 (배수)  요구사항 개발  1  실계  2 - 3  구현  5- 10  시스템/수락 시험  8 - 20  운용  68 - 110 보다 나은 요구사항의 효과 - 회사에서 진행할 여러가지 프로젝트 중에서 우선적으로 수행할 수 있도록 결정하는 자료가된다. - 프로젝트를 수행함에 있어서 필요한 자원이 노력의 정도를 가늠할 수 있다. - 시간에 쫒기는 프로젝트에서 구현해야 할 기능에 대한 우선 순위를 결정할 수 있다. - 제품 설계에 기초가 된다. - 시스템 테스트의 기준이 된다.   15개의 뱅킹 및 통신 프로젝트에 관한 연구 결과 이 중 가장 성공적인 프로젝트의 경우 요구사항 공학에 28%에 달하는 프로젝트 자원을 할당한 반면 평균치는 15.7%에 머물고 있다. (Hofmann과 Lehner 2001) NASA 프로젝트에서는 요구사항 개발에 대한 예산 비율을 높임으로써 비용과 일정 모든 면에서 초과나 지연이 줄어들었다.(Hooks와 Farry 2001) 좋은 요구사항은 몇...

  소프트웨어 요구사항에 대한 일반적인 진리   컨설턴트라면 누구나 알고 있듯이 소프트웨어에 대한 거의 모든 질문에 대한 정확한 대답은 " 그때 그때 달라요 "이다. 이 말이 단순히 컨설턴트의 변명이라고만 할 수  없다. 주어진 상황에 대한 최선의 대처법에 대한 조언은 프로젝트 성격, 제한사항, 조직이나 팀 내 문화, 비즈니스 환경 등에 따라 달라진다. 그렇다고 고객의 질문에 그렇게 답할 수는 없다. 그래서 요구사항의 " 보편적 진리 "들과 이들이 실제 요구사항 분석가 훈련 시에 어떤 의미를 갖는지 설명하도록 하겠다.   [요구사항 실체]   일반적인 진리 #1 : 제대로 된 요구사항을 얻지 못한다면, 그 이후에 프로젝트를 얼마나 잘 수행하느냐는 논할 가치도 없다. 요구사항은 뒤따르는 모든 포르젝트 업무의 토대이다.   일반적인 진리 #2 : 요구사항 개발은 단순히 수집하는 과정일 뿐만 아니라 탐색하고 창조하는 과정이다. 요구사항은 주변에 가만이 떨어져있는 꽃처럼 줍기만 하면 되거나 분석가가 사용자의 머릿속에서 빨아내기만 하면 되는 것으로 보인다. 분석가는 단순히 고객이 말하는 것을 받아쓰는 사람이 아니다. 분석가는 고객이 보다 활발하게 생각하고 의견을 낼 수 있도록 유도하는 사람이다.  "고객님 시스템이 XYZ 기능을 제공한다면 어떤 도움이 될까요?"와 같이 숨은 요구사항을 탐색할 수 있어야 한다.   일반적인 진리 #3 : 변경은 발생하게 되어 있다. 요구사항은 변할 것이라는 것은 불을 보듯 뻔한 사실이다. 시장이 변하고, 정부의 규제, 업무 규칙, 운영 환경이 변하기 때문에 수시로 변화한다. 그래서 "요구사항 변경관리"가 필요하다. 그러나 요구사항이 합의된 후에도 변경사항이 예상외로 많으면 충분한 유도작업을 하지 못했거나, 고객과 합의가 불충분 하다는 것이다. 모든 개발팀은 요청된 변경에 대해 누가 평가하고 결정권을 가지며 거부권을 갖게될지 결정해야 한다. 이...

  MORE ABOUT  SOFTWARE REQUIREMENTS "실용적인 소프트웨어 요구사항" 칼 위거스 저, 김도균 역 ------------------------------------------------------------------------------   "요구사항" 정의 요구사항이란, 무엇이 구현되어야 하는가에 대한 명세이다. 요구사항은 시스템이 어떻게 동작하여야 하는지 또는 시스템 특징이나 속성들에 대한 설명이다. 요구사항은 시스템 개발 프로세스 상의 제한 사항일 수도 있다.      from 칼 위거스   나는 체계적으로 요구사항을 분석했을 때 과연 프로젝트 진행에 어떠한 효과를 볼 수 있는지 알아보고 싶다. 또한 스크럼과 XP를 이용해서 진행하려고 하는데 여기서는 "요구사항" 분석이 중요하다고 나와있었고 어떻게 하는지는 나와있지 않아서 관련책을 보고 있다.   [그림1 요구사항 다이어그램]         [비지니스 요구사항] 비지니스 요구사항(Business Requrements)은 "왜(Why)"에 해당하는 정보를 나타낸다고 보면된다. 비지니스 요구사항은 왜 해당 조직에서 프로젝트를 수행하는지를 설명하며, 개발 조직이나 조직의 고객이 제품을 개발함으로써 얻을 수 있는 이득에 대해서도 언급한다. 필자는 주로 비전과 범위(Vision and scope) 문서에 비즈니스 요구사항을 기록한다. 어떤 조직들에서는 이러한 목적으로 비지니스 강령, 게이스 또는 마케팅 요구사항 문서를 작성하기도 한다.     [사용자 요구사항] 사용자 요구사항(User Requirements)은 "무엇(What)"에 해당하는 정보를 나타내는 하나의 형태이다. 사용자 요구사항은 사용자가 제품을 이용하여 할 수 있는 "무엇"을 설명하며 사용자들이 수행하려는 업무를 예를 들 수 있다. 유즈케이스(Use cases), 시나리오(Scenarios)...