프로젝트/요구사항분석 썸네일형 리스트형 개발문서를 만들기는 했는데 업데이트가 안되는 이유 필자는 여러 소프트웨어 회사들의 컨설팅을 진행하면서 먼저 회사의 분석을 위해서 그 동안 소프트웨어를 개발하면서 만들어 놓은 문서를 요구합니다. 사실 문서만 봐도 회사의 개발현황을 대부분 알 수 있습니다. 그런데, 제대로 작성된 문서를 제시하는 회사는 거의 없다시피 합니다. 물론 Wiki나 Google Docs등의 온라인 문서를 포함해서 제대로 작성된 문서는 거의 없습니다. 가끔 문서를 제시하는 회사들이 있기는 하나 수년간 전혀 업데이트를 하지 않아서 쓸모가 없어진 것들 뿐입니다. 정리를 해보면 다음과 같습니다. 문서가 아예 없거나 없다시피 한 회사 몇 년동안 업데이트 안된 문서들만 있는 회사 (오늘의 주제) 쓸모없는 문서들을 너무 많이 만든 회사 야심차게 문서 한번 잘 만들어보겠다고 결심하고 개발 시에 .. 더보기 SRS에 대한 인식의 변화 그 동안 본 블로그를 통해서 소프트웨어 개발에서 SRS(Software Requirements Specification)가 얼마나 중요한 역할을 하는지에 대해서 수 차례 역설한 적이 있습니다. 2009/08/03 - [프로젝트/요구사항분석] - 이건 기능이 아닌데 2009/07/30 - [프로젝트/요구사항분석] - 고객이 요구사항을 너무 자주 바꿔요. 2009/05/04 - [프로젝트/요구사항분석] - Track me, if you can 2009/04/22 - [프로젝트/요구사항분석] - 개발자들이 바글바글한 외딴섬에 떨어진다면 2009/02/12 - [프로젝트/요구사항분석] - 요구사항 분석의 출발점 2009/02/04 - [개발프로세스] - 소프트웨어 개발 단계에서 가장 중요하다고 생각하는 것은? .. 더보기 이건 기능이 아닌데 의례 스펙, 기능요구사항 등을 정리한 문서를 보면 기능만 잔뜩 나열되어 있는 것은 매우 흔한 일입니다. 소프트웨어를 만든다고 하면 구현해야 할 기능만 알면 제대로 잘 만들 수 있을 것으로 생각하기 십상입니다. 상식적으로 생각해도 기능면 제대로 구현하면 되겠지요. 여기에 UI는 살짝 추가하고요. 하지만, 분석을 할 때 기능보다 더 중요한 것이 비기능 요구사항입니다. 즉, 기능은 아닌데, 요구사항 즉, 스펙인 겁니다. 기능이 중요하기는 하지만, 기능 하나가 잘못되면 이를 고치는 것은 그렇게 어렵지 않습니다. 그런데 비기능에서 잘못되면 소프트웨어를 완전히 뒤엎어야 하는 일이 발생할 수도 있습니다. 이렇듯 비기능이 기능보다도 더 중요한 측면이 있는데, 눈에 바로 보이지 않는 다는 이유로 간과되기 쉽습니다. 그럼.. 더보기 고객이 요구사항을 너무 자주 바꿔요. 우리나라 소프트웨어 시장을 너무 비관적으로 과대평가하는 경우를 종종 봅니다. 예를 들면 전세계 유래가 없는 까다로운 고객 요구 수준, 시도 때도 없이 바뀌는 요구사항, 엄청나게 낮은 금액, 제품의 Output과는 상관없이 작업 시간을 통제하는 관행 일부는 공감을 하기도 하지만, 어느 나라를 가던지 각 나라만의 특징이 있다는 측면으로 바라보고 싶습니다. 우리나라 고객은 요구사항을 정말로 외국에 비해서 더 자주 바꾸는 것인지는 생각해 볼 필요가 있습니다. 어딜 가던지 고객은 요구사항을 항상 바꾸기 마련이고, 그것이 고객의 습성이라고 볼 수 있습니다. 그런데, 외국에서는 관행적으로 문화적으로 스펙을 근거로 계약을 하고, 분석 능력이 뛰어난 엔지니어들도 많이 있습니다. 하지만 그런 저변이 상대적으로 부족한 우리.. 더보기 Track me, if you can "요구사항 추적"이라는 말을 들어 보셨을 겁니다. 요구사항, 기능, 컴포넌트(클래스), 파일, 함수들의 연관관계를 추적하여 특정 요구사항에 관련된 컴포넌트나 소스코드들을 추적하고, 거꾸로 함수가 바뀔 때 이 변경에 영향을 받는 요구사항을 알아낼 수 있습니다. 왠지 근사해 보입니다. 실제로 요구사항을 추적하려고 노력하는 회사를 종종 보게 됩니다. 하지만 요구사항을 추적할 필요도 없는 작은 소프트웨어이거나 엉터리로 하고 있는 경우가 대부분입니다. 아니 100%입니다. 요구사항 추적이라는 것이 말만 근사해 보이지, 대부분의 역량으로는 거의 불가능합니다. 또 요구사항 추적툴 없이 엑셀파일에 끄적거려서는 할 수 없는 일입니다. 요구사항 추적은 사람의 생명을 다루는 소프트웨어이거나 엄청난 비용과 테스트가 불가능한 .. 더보기 개발자들이 바글바글한 외딴섬에 떨어진다면 개발자들이 바글바글한 외딴섬에 떨어졌는데 서로 뒤죽박죽으로 개발을 하고 있고,이들을 3개월 안에 훈련시켜서 정예 개발자로 만들어 한다는 미션이 떨어졌다면 무엇을 하시겠습니까? Language 기초를 다시 가르칠까요? UML을 가르칠까요? 문서 작성법을 훈련 시킬까요? 개발방법론을 가르칠까요? 팀워크를 키워줄까요? OOP를 가르칠까요? 어떻게 하시겠습니까? 나는 스펙을 작성하는 방법을 가르치고 3개월간 훈련을 시킬 겁니다. 즉 Requirement engineering을 익히게 하겠다는 뜻입니다. 그만큼 스펙은 현재 소프트웨어 개발현장에서 가장 많은 실패의 원인이 되고 있고, 배우기도 가장 어려운 분야입니다. 나는 수많은 개발자들이 작성한 스펙문서(다양한 이름의 문서)를 봐 왔지만, Requirement .. 더보기 요구사항 분석의 출발점 소프트웨어 개발에 있어서 요구사항 분석이 가장 중요하다는 것은 앞에서도 이미 주지한 사실입니다. 2008/11/19 SRS(Software Requirements Specification)의 중요성 2009/02/04 소프트웨어 개발 단계에서 가장 중요하다고 생각하는 것은? 요구사항 분석의 산출물은 SRS, 요구사항분석서 또는 다양한 방법론에 의해서 다른 문서들이 나올 수 있겠죠. 그럼 요구사항분석의 출발은 무엇일까요? 어떤 기능을 제공하기를 원하나 조사하는 것일까요? "왜 이 프로젝트를 하려고 하는가?"입니다. 프로젝트를 하는 목적과 목표를 알아야 모든 요구사항이 일관성을 갖게 됩니다. 이걸 누구나 다 알고 있다고요? 제 경험에 의하면 그렇지 않습니다. 프로젝트 구성원에게 각각 물어보면 프로젝트의 목적.. 더보기 샘플만 보여주세요. 소프트웨어 개발에서 가장 어려운 것이 "요구사항분석"이라고 여러 차례 언급한 바가 있습니다. 요구사항을 분석하여 "스펙"으로 만들어서 적어 놓은 문서를 "SRS"라고 합니다. 그런데 SRS는 샘플이나 Template을 보고 잘 적는 것은 거의 불가능합니다. 개발자들은 원래 샘플 소스코드를 보고 많은 것들을 배워왔기 때문에 스펙도 샘플을 보면 잘 적을 수 있을 것 같은 착각을 하는 경우가 흔합니다. 샘플 소스코드가 도움이 되는 이유는 개발자들인 소스코드에 대해서는 이미 상당한 지식과 경험이 있기 때문입니다. 샘플만 보고 잘하려고 하는 것은 피아노를 잘 치고 싶다고 유명 피아니스트가 친 것을 몇 번 보고 피아노를 잘 치려 하는 것과 비슷합니다. 심지어는 지금 듣고 있는 피아노 연주가 잘 하는 것인지 못하는 .. 더보기 그냥 쓸 수 있겠네요. 소프트웨어를 개발하면서 가장 어려운 일은 고객의 요구사항을 파악하는 일이라고 알려져입니다. 고전적인 Waterfall 방식부터 Agile까지 요구사항에 대해서 다양한 방법으로 상당히 신경을 쓰고 있습니다. 특히나 우리나라에서는 고객이 요구사항을 잘 가르쳐 주지 않습니다. 물론 자신의 요구사항을 완벽하게 자세히 알고 말해주는 고객은 전세계 어디서도 찾아보기 어려운 것이 사실입니다. 정도의 차이가 있을 뿐이죠. 그만큼 요구사항 파악은 어려운 일입니다. 우리나라에서 요구사항 파악 시 고객이 이렇게 얘기하는 경우가 흔합니다. "자세한 요구사항은 나중에 알려줄 테니 일단 구현을 시작해주세요." 그래서 일단 제품을 다 만들어 놓고 고객에게 시연을 하면 그 때서야 고객이 "여기는 이렇게 고쳐달라", "이 기능을 넣어.. 더보기 SRS(Software Requirements Specification)의 중요성 본 블로그에서 소프트웨어 개발, 소프트웨어 공학에 대한 여러 주제에 대해서 다루겠지만, 특히 나는 요구사항 특히 SRS에 대해서 많이 다루려고 합니다. "소프트웨어개발의모든것"이라는 책에서도 요구사항에 대해서 가장 중요하게 다루고 있지만 지면의 한계와 다양한 독자층의 눈높이를 맞추기 위해서 욕심보다는 많이 설명하지 못하는 측면이 있습니다. 그래서 소프트웨어 개발단계에서 가장 중요한 "요구사항"에 대해서 천천히 여러분들과 의견을 주고 받으면서 심도있게 다뤄볼까 합니다. 제가 세상의 모든 경우의 요구사항 분석 기술 및 경험이 있는 것이 아니니 여러분들과 토론을 하면서 또 많이 배울 것을 기대하고 있습니다. 먼저 제가 책에서 요구사항에 대해서 설명한 내용을 앞부분을 약간 소개할까 합니다. 요구사항 분석 소프트.. 더보기 이전 1 2 다음
