답변:
지금까지 아무도 추적 요구 사항에 위키 사용을 권장하지 않았다는 것에 놀랐습니다 .
나는 그것이 거의 완벽한 시스템이라는 것을 알았습니다.
선택의 여지가 있지만 요즘에는 거의 항상 위키 방법을 선택합니다. 구식 Word 문서와 비교하거나 버그 추적기에 모두 넣는 것은 정말 고통스럽지 않습니다.
저는 항상 SRS 문서의 템플릿으로 IEEE Std 830-1998 (소프트웨어 요구 사항 사양에 대한 IEEE 권장 사례)를 사용합니다. http://standards.ieee.org/reading/ieee/std_public/description/se/830-1998_desc.html을 참조 하십시오
최종 SRS 문서 자체는 일반적으로 단일 OpenOffice.org 문서이지만 스프레드 시트 및 다이어그램을 포함하여 많은 부분이 구성되어 있습니다.
나는 보통이 모든 문서들을 SVN이나 CVS와 같은 개정 관리 시스템에 넣은 저장소에 넣었다 . 다른 모든 비즈니스 분석가, 디자이너, 개발자, 테스터, 프로젝트 관리자 및 클라이언트 는이 저장소에 액세스 할 수 있으므로이를 읽고 편집 할 수 있습니다.
SRS는 생생하고 진화하는 문서입니다. 한동안 계속 변화하고 성장할 것입니다. 모든 이해 당사자가 SRS에 액세스하는 것이 중요 할뿐만 아니라 변경 사항에 대한 전체 기록을 보유하고 필요한 경우 이러한 변경 사항을 롤백하는 기능도 중요합니다. 따라서 개정 제어 시스템은이 목적에 적합합니다. 행운을 빕니다!
요구 사항 관리에 버그 추적기를 사용하면 회사 내에서 협업 및 의사 소통 의 부족을 숨기는 경향이 있습니다.
특정 방법에 대한 판단을하지 않고 :
요구 사항에 버그 추적기를 사용한 과거의 고용주 중 한 사람의 경험은 많은 사람들이 의사 소통을 완전히 중단 할 수있는 매우 쉬운 방법이라고 생각했습니다. 사람들은 단순히 소원을 작성하여 버그 추적기에 버리고 결국 실현 될 것이라고 가정합니다.
물론 그들은 다음과 관계없이 그렇게했습니다.
다음과 같은 이유로 "Word"문서가 요구 사항을 따르기에는 잘못된 방법이라고 생각합니다.
나는 경험 한 대체 제안이 없지만 파이썬의 재구성 된 텍스트 또는 마크 다운을 대안으로 생각했습니다.
우리는 일반적으로 Word를 사용하지만 실제로 소프트웨어를 사용하여 데이터를 작성하는 방법은 데이터를 작성하기 위해 데이터를 수집하는 방법과 정보를 수집하는 사람이 요구 사항이 지나치게 복잡하고 비용이 훨씬 더 비싼시기를 알 수 있는지 여부를 충분히 알고 있는지 여부보다 덜 중요합니다. 요구 사항이 더 단순하지만 누구에게도 실질적인 가치가없는 경우 (예 : ID 번호를 건너 뛰지 않은 순서로 항상 할당하려는 경우) 또는 기존 요구 사항 또는 기타 계획된 기능과 충돌 할 때 실제 사용자와 대화를 나누지 않고 관리자가 반드시해야 할 일을 알지 못하고 새로운 버전의 소프트웨어에는없는 경우가 종종 있습니다.
다양한 pdf, Excel 또는 Visio 파일도 사용할 수 있습니다. 프로젝트의 모든 프로젝트는 SharePoint에서 수집 및 편집되므로 필요한 경우 이전 버전을 볼 수 있습니다.
User Stories 가 포함 된 제품 백 로그 (프로젝트 또는 제품 당 하나)를 유지합니다 . 그것들은 당신이 사용하는 것과 같은 버그 추적 소프트웨어에 저장 될 수 있습니다. 나는 백 로그에 Excel 을 사용 하고 스프린트 백 로그에 Trac 을 사용합니다 (아마도 해당 도구와 같은 도구를 사용합니다).
필요할 때만 더 자세한 내용으로 사용자 스토리를 설명 하는 Word 문서 를 작성 하여 사용자 스토리에 첨부합니다. 그러나 나는 사용자 이야기를 더 작은 것으로 나누면서 이것을 피하려고 노력합니다.
소규모 사용자 스토리 관리가 용이함 (추정 포함)
링크, 텍스트 서식, 테이블, 스크린 샷 등을 넣을 수 있고 누구나 읽을 수 있기 때문에 Word 문서가 마음에 듭니다.
물론 각 사용자 스토리는 평가 세션 및 스프린트 계획에 자세히 설명되어 있으며 개발자가 작업하기로 결정할 때 더 많은 질문에 항상 사용할 수 있습니다. 스프린트 검토를 사용하는 빈번한 피드백은 개발자가 제품 소유자가 요청한 것과 다르게 행동하지 못하게합니다.
개인적으로 과거에는 Word Documents를 사용했지만 앞으로 나를 위해 이것을 관리 할 도구를 찾기로 결심했습니다 ... 특히 버그를 요구 사항에 설정할 수있는 기능이 있습니다. 사양과 구현 사이의 편차가 아니라 요구 사항에서.
버그 추적 도구를 사용하는 것은 결코 일어나지 않았지만 완전히 이해됩니다.
호기심에서 당신이 싫어하는 것은 무엇입니까?
편집 : 하나의 경고; 관리자에게 버그 추적 소프트웨어의 브랜드를 변경하도록 요청하십시오. 그렇지 않으면 그 안에있는 모든 것이 버그로 간주됩니다. 나는 마지막 클라이언트에서이 정치적인 문제를 겪었고, 여기서 버그 추적기에 작업을 넣었습니다. 안좋다.
이를 처리하기 위해 6 ~ 7 년 전에 요구 사항 데이터베이스를 작성했습니다. 각 요구 사항 레코드에는 간단한 설명, "정의"메모 및 "메모"메모 (리치 텍스트 포함, 스크린 샷 포함 기능 등)가 있습니다. 프로젝트, 인도 물, 시퀀스 번호 (논리적으로 주문 가능), 관련 사례 / 기능, 시간 견적, 처리하는 사람을위한 필드, 구현을 위해 선택한 다른 필드, 기타
기능을 디자인하는 동안 "상태"- "입력"도 있습니다. "승인 됨"-요구 사항 그룹을 검토하고 구현할 준비가되면 결정됩니다. 요구 사항이 완료되었다고 생각되면 프로그래머가 설정 한 "구현 됨", QA 기술이 프로그래머와 동의하면 "검증 됨". (QA 기술이 동의하지 않으면 프로그래머가 다시 승인하도록 "승인 됨"으로 다시 설정할 수 있습니다.) 요구 사항은 "지연됨", "거부 됨"또는 "질문"일 수도 있습니다 (변경 제어 보드가이를 확인해야 함을 의미 함). .)
이것을 잘하는 비결은 합리적인 세분성입니다. 하나의 문장 요구 사항 (예 : "문제 12345에서 설명 된 문제가 수정되었습니다")을 갖는 것이 합리적 일 수 있지만 일반적으로 요구 사항은 전체 기능 (또는 큰 부분)의 모든 중요한 측면을 설명해야합니다. 예를 들어 일반적인 "새 보고서"기능에는 보고서 형식 (출력 모양)에 대한 요구 사항과 옵션 대화 상자 (필드 설명, 유효성 검사 등)에 대한 요구 사항이 있습니다. 쉬운 쿼리 또는 무언가가 아니라 데이터를 처리하는 복잡한 생성기가 있습니다. 또한 해당 도움말 주제에 대한 "도움말"요구 사항을 작성합니다.
이 문서를 큰 문서가 아닌 데이터베이스 레코드에 보관하면 큰 이점이 있습니다. 여러 프로그래머가 동시에 요구 사항에 대해 작업 할 수 있습니다. 한 번에 한 사람 만 편집 할 수 있도록 개별 레코드가 잠겨 있지만 다른 사람이 편집하는 동안 열어서 읽을 수 있습니다. 그러나 가장 큰 장점은 요구 사항과 구현 방식에 대한 메모를 쉽게 검색 할 수 있다는 것입니다. 현재 25,000 개가 넘는 요구 사항이 있으며 10 초 이내에 모든 필드 또는 정의, 메모 또는 기타 항목에서 특정 단어가 포함 된 모든 요구 사항을 쉽게 찾을 수 있습니다. (6 년 이상의 Word 문서를 사용해보십시오.)
사람들이 "버그 추적기"에서 요구 사항을 수행하는 것이 좋지 않은 이유를 알 수있는 이유를 알 수 있지만 검색 가능한 데이터베이스에 요구 사항을 유지하는 것이 좋지 않은 것이 아니라 도구가 빠지기 때문입니다.
한 번 http://www.pivotaltracker.com/을 사용 했지만 현재 회사에서는 .doc을 핵심 사양 소스로, Lighthouse를 결합 된 기능 위시리스트 및 문제 추적으로 사용하고 있습니다. 나를 위해 팀의 다른 사람들이 Word에 너무 익숙 할 때 다른 도구를 사용하게 만드는 것은 어렵습니다.
애자일 방법론을 따를 수 있다면 다음 링크를 통해 적절한 애자일 프로젝트 관리 도구를 선택할 수 있습니다.
그리고 진지하게, 민첩한 방법론을 시도하십시오-그것은 모든 팀원이 다른 모든 회원의 역할과 노력을 이해하고 감사 할 수 있도록 당신이 무엇을하든 단순하고 우아하고 말도 안되며 재즈가없고 일반적인 감각적 접근법을 전파합니다.
행운을 빕니다!