명세서 썸네일형 리스트형 요구사항 개발 소프트웨어 프로젝트 생존전략 - 스티브 맥코넬, 인사이트 160 약간 생소하게 느껴지는 '개발'이라는 용어를 쓰는 것은, 요구사항 관련 작업이 단순하게 사용자의 요구사항을 문서화하는 것으로 끝나지 않는다는 것을 강조하고 싶어서다. 철광산에 묻혀 있는 철광석을 캐듯이, 사용자 머릿속 '어디엔가' 있는 사용자의 요구사항을 수집만 하면 되는 것이 아니라는 말이다. 사용자는 요구사항을 기르는 토지나 다름없다. 여기에 씨를 뿌리고 길러서 수확하는 것은 프로젝트 팀의 몫이다. 요구사항을 수집하는 데 가장 어려운 일은 사용자가 원하는 것을 '기록'하는 활동이 아니다. 그들 자신이 원하는 것이 무엇인지 알 수 있게 도와주는 하나의 탐험적이며 '개발'차원의 활동이 필요하다. 요구사항 수집과 명세서 작업은 끝이 없는 활동.. 더보기 데드라인 - 애매모호한 명세서 244 "네, 마찰이요. 시스템을 가지고 이해관계에 있는 사람들이 협상하죠. 사용자, 이해관계자, 개발자, 운영자, 관리자 같은 사람들이요. RGS 처럼 복잡한 시스템 같은 경우, 서로 다른 이해 집단이 아마 12개쯤 됐을 거에요. 가끔 그 사람들은 서로 동의하지 않죠. 마찰이 생기는 거에요. 예를 들자면 RGS에 관해 협상했던 어떤 집단은 시스템 운영자가 직접 초기 변수를 통제했으면 했는데, 다른 어떤 집단은 중앙에서 통제하기를 바란다고 생각해 보세요." "아, 서로 충돌한 거군요. 그리고 만약에 그것이 해결될 수 있는 것이 아니라면?" "그 명세서는 애매할 수밖에요. 예를 들어 운영자가 직접 입력할 수 있는 키보드가 있는지조차 명시할 수 없는 거죠. 구성요소조차도 정확히 명시할 수 없을 거에요. 특정.. 더보기 이전 1 다음