소프트웨어는 하루짜리부터 몇 년짜리 대형 프로젝트도 있다. 이런 모든 프로젝트에 동일한 스펙 문서를 적용하면 비효율적이다. 스펙 문서의 형태는 매우 다양하며 상황에 맞는 문서를 적절히 사용하는 것이 좋다. 이슈관리시스템의 한 줄 또는 몇 줄의 설명 스펙이라고 하면 수십에서 수백페이지의 문서를 먼저 떠올리지만 상황에 따라서는 Jira나 Redmine과 같은 이슈관리시스템의 이슈 하나, 또는 한 줄이 스펙이 될 수도
소프트웨어는 빠르게 개발하는 것이 매우 중요하다. 소프트웨어는 빠르게 개발하는 것이 매우 중요하다. 소프트웨어 개발 기간이 오래 걸린다면 적절한 시장 진입 시기를 놓칠 수 있다. 소프트웨어 시장 변화는 매우 빨라서 너무 오래 개발을 하면 그동안 시장의 상황이 바뀐다. 경쟁자들은 새로운 제품을 출시하여 우리 회사에서 지금 개발하고 있는 제품이 뒤쳐지곤 한다. 또한 오랜 프로젝트는 개발자와 프로젝트 참여
“소프트웨어회사에서 재택근무를 할 수가 있는가?” 라는 필요조건에는 다양한 문제가 있다. 먼저 간단히 소개 정도만 할 주제는 보안이다. 보안이라고 하면 한 회사에서 습득한 지식, 설계문서, 소스코드 등 지적재산을 다른 회사에서 사용할 수 있는가에 대한 도덕적 혹은 법적인 주제이다. 구글의 전 개발자였던 Levandowski 가 구글의 비밀을 우버에 가져가 자율자동차에 기여를 한 것에 대한 구글의 소송에서 일주전인 3월4일에 최종판결이 났는데 Levandowski는 구글에게 2000억원, 우버는 구글에게 3000억원을 배상하게 되었다. Levandowski는 개인파산을
소프트웨어 요구사항을 분석해서 작성하는 스펙 문서의 형태와 종류는 셀 수 없을 만큼 다양하다. 개발방법론에 따라서 제시하는 문서도 다르고 그 개수도 천차만별이다. 이 시리즈의 글에서 소개하고 주로 다룰 문서는 SRS다. SRS는 Software Requirements Specification(s)의 약자다. Specification 혹은 Spec(스펙)이라고도 한다. SRS는 IEEE830에서 문서를 작성하는 가이드가 정의되어 있고, DoD(미국 국방부) 표준 문서이다. SRS는 스펙 작성의 원리를 이해하는데 매우