오픈 소스 소프트웨어 프로젝트에서 요구 사항은 어떻게 결정됩니까?

사내 소프트웨어 개발에서 요구 사항은 공식적인 프로세스를 통해 결정되어 많은 요구 사항 문서가 생성되는 것이 일반적입니다. 오픈 소스 소프트웨어 개발에서 이것은 종종없는 것처럼 보입니다. 따라서 제 질문은 오픈 소스 소프트웨어 프로젝트에서 요구 사항을 어떻게 결정합니까?

"요구 사항 결정"은 단순히 "특정 소프트웨어의 일부로 어떤 기능 등을 개발해야하는지 파악"을 의미합니다.

오픈 소스 프로젝트는 때때로 사용자 피드백의 강렬한 흐름을 가지고 있으며, 때로는 기업이 특정 기능을 계획하고 구현하기 위해 비용을 지불하기도합니다 (자체 개발자 또는 원래 개발자 고용).

프로젝트에 100 명의 사용자가 있다면 코딩하기에 가장 재미있는 것을 개발할 수 있습니다.

프로젝트에 100k 명의 사용자가있는 경우, 아마도 대부분의 사용자가 다음 릴리스에서 수정하고자하는 어려움 목록과 사용자가 이슈 트래커에서 요청하고 포럼에 대해 계속 묻는 상위 N 기능의 목록이 이미있을 것입니다.

이 피드백을 통해 핵심 팀에 대한 요구 사항 문서를 작성하고 독립 기고자들이 비전을 이해하는 데 도움이되는 로드맵을 만들 수 있으며 일부 100k 사용자가 패치를 보내길 바랍니다.

1995 년경 리눅스에 대해 처음 들어 본 이후 오픈 소스를 따라 왔으며, 그 맥락에서 사용 된 '요구 사항'이라는 단어를 들어 본 적이 없습니다.

Eric Raymond는 ' The Cathedral and the Bazaar '에 대한 훌륭한 에세이를 가지고 있는데, 이 책에서 '자신의 가려움을 긁는 것'에 대해 이야기합니다. 개인적으로 직면 한 문제를 해결하려는 경우 요구 사항 문서를 참조하여 문제가 해결되었는지 확인할 필요가 없습니다.

같은 에세이도 오픈 소스 프로젝트뿐만 아니라 모든 사람에게 좋은 조언 인 사용자의 의견을 듣는 것에 대해 이야기합니다. 오픈 소스 프로젝트는 메리 토크 한 경향이 있으므로 '코드를 작성하고 규칙을 만드는 사람'은 어느 정도 있습니다.

사내 소프트웨어 개발에서 요구 사항은 공식적인 프로세스를 통해 결정되어 많은 요구 사항 문서가 생성되는 것이 일반적입니다.

내 경험상 이것은 계약 기반 개발을 수행 할 때, 특히 외부 회사가 회사를 위해 개발을 수행 할 때 훨씬 일반적 이며 계약 에 대한 법적 요구가 있습니다. 그러나 많은 다른 회사들이 다른 방식으로 자신의 직원에 의한 사내 개발을 통제합니다.

• 비공식 커뮤니케이션

• 우선 순위가 지정된 요구 사항 / 버그 / 문제 / 티켓 목록 (및 "민첩한"커뮤니티의 발명품이 아님)

공식적인 계약이 필요하지 않으며, 크고 상세하며 공식적인 요구 사항 문서, 작고 고통스럽지 않은 누락 된 기능 목록 또는 문제로 수집 된 티켓을 처리 할 필요가 없기 때문에 이는 대부분의 오픈 소스 프로젝트와 동일한 방식입니다. 추적 할 추적기.

문제가 컴파일러 또는 브라우저 작성과 같은 일반적인 문제라면 요구 사항은 언어 표준, 대상 운영 체제 및 대상 하드웨어 등의 형태로 제공됩니다.

텍스트 편집기라는 원래 목표를 완벽하게 달성하는 것 외에도 많은 것들이있는 GNU Emacs와 같은 것들의 경우, 확장해야 할 엄청난 범위 때문에 요구 사항이 합리적이라고 생각합니다. 채팅, 이메일, 뉴스 그룹, 코드 편집, 버전 관리가 떠 오릅니다. Emacspeak에 관한 연구 과학자가 있습니다. 브라우저와 확장 기능을 허용하는 다른 것들에 대해서도 비슷한 것들이 있다고 생각합니다.

소프트웨어가 오픈 소스가 아닌 소프트웨어에서만 사용할 수있는 기능을 따라 잡으면 요구 사항이 거의 다시 주어집니다.

편집하다:

오픈 소스 소프트웨어가 유지 보수를 계속하고 원래 요구 사항이 충족되지 않는 경우 대부분의 요구 사항은 버그에서 비롯 될 수 있으며, 멀티 코어 CPU 및 악용시 더 나은 성능을 제공하는 기타 하드웨어와 같은 새로운 플랫폼에 적응해야합니다.

GNU Hurd와 같은 완전한 연구 기반 프로젝트에서 요구 사항은 연구 결과 및 논문에서 나온 것으로 생각합니다.

요약하면

• 시작할 때 일반적인 문제를 해결하려는 소프트웨어 요구 사항은 표준 문서에서 얻을 수 있습니다.

• 기존의 다른 소프트웨어를 따라 잡는 소프트웨어의 경우 요구 사항은 기존 소프트웨어의 모든 기능 세트 또는 대부분의 개발자 기능과 개발자 / 사용자가 흥미롭게 느끼는 기타 기능을 생성해야합니다.

• 연구 프로젝트, 논문 및 기타 출판물에 대한 요구 사항을 설정할 수 있습니다

• 유지 보수, 버그, 새로운 환경에 적응해야 할 때 요구 사항의 주요 원인이 될 수 있습니다.

확실하지는 않지만 JIRA와 같은 것을 사용하여 요구 사항이 티켓 (또는 "카드")으로 제기되는 민첩한 방법론을 사용하는 것이 좋습니다. 각 티켓은 기능이나 요구 사항을 나타냅니다. 각 티켓은 작은 작업 단위를 나타내는 다른 티켓으로 분해 될 수 있습니다.

실제로 응용 프로그램이나 소프트웨어가 무엇을해야하는지 파악하는 데있어 간단한 대답은 "다른 개발자와 대화하는 것"입니다. :)이 경우 "말하는"이란 전자 메일 배포 목록, 포럼 또는 IRC를 의미 할 수 있으며, 다른 시간대 및 지리적 위치에있는 사람들이 채팅 할 수있는 모든 것을 의미합니다.