요구 사항 문서를 작성하는 올바른 방법은 무엇입니까?


23

현재 관리자가 버그 추적 소프트웨어를 사용하여 요구 사항 설명서 / 사양을 작성하고 있습니다. 이것은 나에게 끔찍한 생각처럼 보입니다. 모든 요구 사항은이 작은 티켓에 있으며 요구 사항을 얻으려면이 바보 같은 웹 양식을 클릭해야합니다. 요구 사항 / 소프트웨어 사양을위한 올바른 소프트웨어 솔루션은 무엇입니까?

분명히하기 위해, 나는 몇 가지 기능을 가진이 큰 소프트웨어 구성 요소를 구축하고 있으며이 기능은이 버그 추적 소프트웨어에 설명되어 있습니다.

답변:


17

지금까지 아무도 추적 요구 사항에 위키 사용을 권장하지 않았다는 것에 놀랐습니다 .

나는 그것이 거의 완벽한 시스템이라는 것을 알았습니다.

  • 이를 통해 사람들은 요구 사항에 대해 협업 할 수 있으며 이러한 측면을 눈에 잘 띄게 할 수 있습니다.
  • 프로젝트가 진행됨에 따라 요구 사항을 쉽게 최신 상태로 유지할 수 있습니다.
  • "우리가 동의 한 것이 아닌"분쟁의 경우 언제든지 방문하여 역사를 볼 수 있습니다.
  • 대부분의 최신 위키에는 적절한 형식 지정 기능이 있으므로 Word 문서와 거의 비슷합니다.
  • 요구 사항에서 실제 문서로 직접 하이퍼 링크 할 수 있습니다.
  • 다른 사본 또는 더 이상 사용되지 않는 사본으로 작업하는 사람들에 대해 걱정할 필요가 없습니다.
  • 요구 사항은 설계 / 구현과 마찬가지로 반복 프로세스로 취급되기 시작할 수 있습니다.
  • 요구 사항이 실제로 커지거나 복잡해지기 시작하면 페이지 / 주제로 쉽게 분리 할 수 ​​있습니다.
  • 대부분의 위키는 HTML을 허용하므로 실제로 고급 서식이 필요한 경우 Windows Live Writer 와 같은 도구를 사용할 수 있습니다 .

선택의 여지가 있지만 요즘에는 거의 항상 위키 방법을 선택합니다. 구식 Word 문서와 비교하거나 버그 추적기에 모두 넣는 것은 정말 고통스럽지 않습니다.


추적 시스템의 데이터를 위키에 비교적 쉽게 포함시킬 수 있으며 계층 적 버그를 설정하면 요구 사항으로 그룹화 할 수 있으며 프로젝트 마일스톤에는 프로젝트 및 고객과 마찬가지로 위키 페이지가 있습니다. 모든 것이 머리를 돌리기 쉽습니다. Wiki는 접착제를 다시 사용하지만 여전히 버그 추적기를 사용합니다. 위키의 웹 페이지를 가리키는 버그 추적기의 기능을 조사하십시오!
Tim Williscroft

물론, 위키는 버그 추적 시스템을 대체하지 않으며, 보완 적입니다. 프로젝트 계획 및 협업은 위키에서 가장 잘 수행됩니다. 여전히 IMS 또는 우선 순위 대기열에서 문제를 추적해야합니다.
Aaronaught

6

저는 항상 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에 액세스하는 것이 중요 할뿐만 아니라 변경 사항에 대한 전체 기록을 보유하고 필요한 경우 이러한 변경 사항을 롤백하는 기능도 중요합니다. 따라서 개정 제어 시스템은이 목적에 적합합니다. 행운을 빕니다!


5

요구 사항 관리에 버그 추적기를 사용하면 회사 내에서 협업 및 의사 소통 의 부족을 숨기는 경향이 있습니다.

특정 방법에 대한 판단을하지 않고 :

  • 워터 폴을 사용하려면 잘 구조화되고 정확한 다중 페이지 문서가 필요합니다 (많은 사람들이 일반적으로 버그 설명으로 입력하는 한 단락이 아님). 마케팅 / 영업 사원 (요구 사항을 작성한 사람)이 엔지니어링 직원과 잘 작동하지 않으면 이러한 문서는 적절한 수준의 품질로 작성하고 유지할 수 없습니다.
  • 민첩한 방법 중 하나를 사용하려는 경우 요구 사항 단위 중 하나는 스토리 카드로 표시되는 사용자 스토리입니다. 카드 자체는 요구 사항이 아니며 대화의 시작점 일뿐입니다.

요구 사항에 버그 추적기를 사용한 과거의 고용주 중 한 사람의 경험은 많은 사람들이 의사 소통을 완전히 중단 할 수있는 매우 쉬운 방법이라고 생각했습니다. 사람들은 단순히 소원을 작성하여 버그 추적기에 버리고 결국 실현 될 것이라고 가정합니다.

물론 그들은 다음과 관계없이 그렇게했습니다.

  • 자신의 자격
  • 프로젝트에 대한 그들의 지분
  • 다른 요구 사항과 충돌
  • 요구 사항의 격차
  • 소송 비용
  • 기술적 고려 사항
  • 기타

그러나 ... 불완전한 요구 사항이 입력되면 할당되고 불완전한 정보를 해결해야 할 사람은 그렇지 않습니까? 사람들이 물건을 떨어 뜨리지 않는다고 가정하면 시스템에 일단 들어가면 해결되지 않아야합니까? 완전한 소프트웨어 평신도가 항목을 입력해야한다고 제안하는 것은 아니지만, 비록 그들이하더라도 .. 시스템에 있고 처리되어야합니다. 예 : 비즈니스는 버그 추적기에 요구 사항 "인쇄 영수증"을 추가하고이를 버스 분석가에게 할당하고, 버스 분석가는 필요에 따라 더 많은 통신을 통해 구멍을 채워 처리하여 처리합니다.
John MacIntyre

통신 고장이 프로세스 문제의 증상이 아닙니까? (진심의 의도)
John MacIntyre

@JohnMacIntyre (1) : 결과는 협업 대신 탁구입니다. 양수인이 항상 올바른 사람은 아니며 드문 문제는 한 사람 만 해결할 수 있습니다. 더 많은 사람들이 필요한 경우, 양수인은 그들에게 무엇을 지시 할 권한이 거의 없으며, 모든 의존성을 거의 볼 수 없습니다 (요구 사항이 거의 독립적이지 않음). 자체 구성, ROI 우선 순위 지정 또는 지연 비용 등의 이점이 손실됩니다.
azheglov

@JohnMacIntyre (2) : 커뮤니케이션 중단은 물론 프로세스가 작동하지 않거나 프로세스가 없거나 회사에 건전한 커뮤니케이션 및 협업 문화가 없음을 나타냅니다. 내 입장은 그들이 그 근본 원인을 해결해야한다는 것입니다.
azheglov

@asheglov-양수인이 구현 자이며 다른 사람과 재 할당하거나 대화 할 수없는 경우 이것이 문제가 될 수 있다고 생각합니다. 그러나 내 입장은 그것이 도구가 아니며, 이것이 최선의 도구가 아니라면 일어날 것입니까?
John MacIntyre

2

다음과 같은 이유로 "Word"문서가 요구 사항을 따르기에는 잘못된 방법이라고 생각합니다.

  1. 변경된 내용을 확인하기 위해 두 문서를 "차이 로울"방법이 없습니다.
  2. 사용자 인터페이스는 전체적으로 일관된 스타일을 사용하지 않는 것이 좋습니다. 그렇습니다. 스타일을 사용할 수는 있지만 대부분의 사람들은 어려움 때문에 방해 할 수 없습니다.
  3. 문서 형식은 본질적으로 숨겨져 있습니다. 물론 "Word"문서라고 생각되는 OLE 파일에 대한 사양이 있지만 Microsoft는 수많은 자료에 유용한 모든 것을 묻었으므로 아무도 모릅니다. 조만간, 당신의 반짝이는 새로운 "단어"는 문서를 열지 않을 것입니다.
  4. 다른 형식에서는 잘 재생되지 않습니다. 즉, Windows 및 IE를 사용하지 않는 한 누군가가 "Word"형식 파일에 대한 링크가있는 HTML 파일로 프로젝트 문서를 구성한 경우 운이 나빠집니다. 잘못된 링크를 클릭하면 생각의 흐름을 방해하는 긴 다운로드 및 시작 단어 기간을 거쳐야합니다. "워드"문서에서 다른 문서로의 하이퍼 링크는 작동하거나 작동하지 않을 수 있습니다.
  5. "단어"는 기본적으로 종이에 표시되는 문서를 작성하는 데 사용됩니다. 훌륭한 목표이지만 온라인 시청에 유용하지 않은 목표입니다.

나는 경험 한 대체 제안이 없지만 파이썬의 재구성 된 텍스트 또는 마크 다운을 대안으로 생각했습니다.


1
나는 이러한 주장들 대부분이 FUD처럼 들린다 고 생각합니다. 단어가 최선의 선택은 아니지만 그렇게 나쁘지는 않습니다. 1. 변경 내용을 추적 및 수락 / 거부하기위한 수정 / 협업 기능이 뛰어나므로 vcs + diff 도구보다 사용자에게 친숙합니다. 2. 2007 년 리본 UI 이후 스타일이 더욱 두드러졌습니다. 스타일을 사용해야하는 이유를 설명하는 것이 완전히 새로운 소프트웨어를 설명하는 것보다 쉽습니다. 3. 최신 Word는 16 년 전에 만들어진 Word 97 파일을 읽고 저장할 수 있습니다. Word 2003은 호환 기능 팩을 사용하여 2010 파일을 읽고 저장할 수 있습니다. pdf는 온라인보기를위한 옵션 일 수 있지만 4. 및 5에 동의합니다.
kapex

@kapep-내 주장은 고전적인 "Fear, Uncertainty and Doubt"의미에서 FUD가 아니며, 아마도 다른 방식으로 "FUD"를 사용할 것입니다. 나의 각각의 주장은 대답 될 수있다. 예를 들어 "삽입"메뉴에서 "control-shift- @를 실행하여 다른 문서에 대해 현재 문서를 한 줄씩 비교할 수 있습니다"라고 말할 수 있습니다. 당신이 제안한 모든 것이 반대 의견 이었기 때문에 그것은 할 수 없습니다. 마이크로 소프트는 문서 형식을 포기한 적이 있거나 적어도 오래된 형식을 사용하는 데 비용이 많이 들거나 어려워 업그레이드 판매량을 늘리는 역사를 가지고있다.
Bruce Ediger

좋아, 나는 단지 3을 수정해야한다. 독점적 인 단어 / 문서를 강타 할 때 종종 사용되는 FUD 인수 인 것 같다. 물론 Microsoft는 포기한 형식이지만 문서 파일은 매우 오랜 시간 사용되어 왔기 때문에 ' 2016 이상 또는 다음 단어가 출시 될 때마다 지원을 중단하기로 결정한 경우 '수줍음 이상 '은 지난 세기의 고풍 버전에만 적용됩니다 . 또한 문서를 "차이"로 만드는 쉬운 방법이 있음을 지적하고 싶었습니다. 물론 라인 단위로 비교하지는 않지만 비 라인 기반 형식에서는별로 의미가 없습니다. SE의 인라인 차이와 비슷합니다.
kapex

2

우리는 일반적으로 Word를 사용하지만 실제로 소프트웨어를 사용하여 데이터를 작성하는 방법은 데이터를 작성하기 위해 데이터를 수집하는 방법과 정보를 수집하는 사람이 요구 사항이 지나치게 복잡하고 비용이 훨씬 더 비싼시기를 알 수 있는지 여부를 충분히 알고 있는지 여부보다 덜 중요합니다. 요구 사항이 더 단순하지만 누구에게도 실질적인 가치가없는 경우 (예 : ID 번호를 건너 뛰지 않은 순서로 항상 할당하려는 경우) 또는 기존 요구 사항 또는 기타 계획된 기능과 충돌 할 때 실제 사용자와 대화를 나누지 않고 관리자가 반드시해야 할 일을 알지 못하고 새로운 버전의 소프트웨어에는없는 경우가 종종 있습니다.

다양한 pdf, Excel 또는 Visio 파일도 사용할 수 있습니다. 프로젝트의 모든 프로젝트는 SharePoint에서 수집 및 편집되므로 필요한 경우 이전 버전을 볼 수 있습니다.


1

User Stories 가 포함 된 제품 백 로그 (프로젝트 또는 제품 당 하나)를 유지합니다 . 그것들은 당신이 사용하는 것과 같은 버그 추적 소프트웨어에 저장 될 수 있습니다. 나는 백 로그에 Excel 을 사용 하고 스프린트 백 로그에 Trac 을 사용합니다 (아마도 해당 도구와 같은 도구를 사용합니다).

필요할 때만 더 자세한 내용으로 사용자 스토리를 설명 하는 Word 문서 를 작성 하여 사용자 스토리에 첨부합니다. 그러나 나는 사용자 이야기를 더 작은 것으로 나누면서 이것을 피하려고 노력합니다.

소규모 사용자 스토리 관리가 용이함 (추정 포함)

링크, 텍스트 서식, 테이블, 스크린 샷 등을 넣을 수 있고 누구나 읽을 수 있기 때문에 Word 문서가 마음에 듭니다.

물론 각 사용자 스토리는 평가 세션 및 스프린트 계획에 자세히 설명되어 있으며 개발자가 작업하기로 결정할 때 더 많은 질문에 항상 사용할 수 있습니다. 스프린트 검토를 사용하는 빈번한 피드백은 개발자가 제품 소유자가 요청한 것과 다르게 행동하지 못하게합니다.


1

개인적으로 과거에는 Word Documents를 사용했지만 앞으로 나를 위해 이것을 관리 할 도구를 찾기로 결심했습니다 ... 특히 버그를 요구 사항에 설정할 수있는 기능이 있습니다. 사양과 구현 사이의 편차가 아니라 요구 사항에서.

버그 추적 도구를 사용하는 것은 결코 일어나지 않았지만 완전히 이해됩니다.

호기심에서 당신이 싫어하는 것은 무엇입니까?

편집 : 하나의 경고; 관리자에게 버그 추적 소프트웨어의 브랜드를 변경하도록 요청하십시오. 그렇지 않으면 그 안에있는 모든 것이 버그로 간주됩니다. 나는 마지막 클라이언트에서이 정치적인 문제를 겪었고, 여기서 버그 추적기에 작업을 넣었습니다. 안좋다.


1

이를 처리하기 위해 6 ~ 7 년 전에 요구 사항 데이터베이스를 작성했습니다. 각 요구 사항 레코드에는 간단한 설명, "정의"메모 및 "메모"메모 (리치 텍스트 포함, 스크린 샷 포함 기능 등)가 있습니다. 프로젝트, 인도 물, 시퀀스 번호 (논리적으로 주문 가능), 관련 사례 / 기능, 시간 견적, 처리하는 사람을위한 필드, 구현을 위해 선택한 다른 필드, 기타

기능을 디자인하는 동안 "상태"- "입력"도 있습니다. "승인 됨"-요구 사항 그룹을 검토하고 구현할 준비가되면 결정됩니다. 요구 사항이 완료되었다고 생각되면 프로그래머가 설정 한 "구현 됨", QA 기술이 프로그래머와 동의하면 "검증 됨". (QA 기술이 동의하지 않으면 프로그래머가 다시 승인하도록 "승인 됨"으로 다시 설정할 수 있습니다.) 요구 사항은 "지연됨", "거부 됨"또는 "질문"일 수도 있습니다 (변경 제어 보드가이를 확인해야 함을 의미 함). .)

이것을 잘하는 비결은 합리적인 세분성입니다. 하나의 문장 요구 사항 (예 : "문제 12345에서 설명 된 문제가 수정되었습니다")을 갖는 것이 합리적 일 수 있지만 일반적으로 요구 사항은 전체 기능 (또는 큰 부분)의 모든 중요한 측면을 설명해야합니다. 예를 들어 일반적인 "새 보고서"기능에는 보고서 형식 (출력 모양)에 대한 요구 사항과 옵션 대화 상자 (필드 설명, 유효성 검사 등)에 대한 요구 사항이 있습니다. 쉬운 쿼리 또는 무언가가 아니라 데이터를 처리하는 복잡한 생성기가 있습니다. 또한 해당 도움말 주제에 대한 "도움말"요구 사항을 작성합니다.

이 문서를 큰 문서가 아닌 데이터베이스 레코드에 보관하면 큰 이점이 있습니다. 여러 프로그래머가 동시에 요구 사항에 대해 작업 할 수 있습니다. 한 번에 한 사람 만 편집 할 수 있도록 개별 레코드가 잠겨 있지만 다른 사람이 편집하는 동안 열어서 읽을 수 있습니다. 그러나 가장 큰 장점은 요구 사항과 구현 방식에 대한 메모를 쉽게 검색 할 수 있다는 것입니다. 현재 25,000 개가 넘는 요구 사항이 있으며 10 초 이내에 모든 필드 또는 정의, 메모 또는 기타 항목에서 특정 단어가 포함 된 모든 요구 사항을 쉽게 찾을 수 있습니다. (6 년 이상의 Word 문서를 사용해보십시오.)

사람들이 "버그 추적기"에서 요구 사항을 수행하는 것이 좋지 않은 이유를 알 수있는 이유를 알 수 있지만 검색 가능한 데이터베이스에 요구 사항을 유지하는 것이 좋지 않은 것이 아니라 도구가 빠지기 때문입니다.


1
DOORS와 같은 상용 요구 사항 추적 소프트웨어가 있습니다.
M. Dudley

1

한 번 http://www.pivotaltracker.com/을 사용 했지만 현재 회사에서는 .doc을 핵심 사양 소스로, Lighthouse를 결합 된 기능 위시리스트 및 문제 추적으로 사용하고 있습니다. 나를 위해 팀의 다른 사람들이 Word에 너무 익숙 할 때 다른 도구를 사용하게 만드는 것은 어렵습니다.


0

애자일 방법론을 따를 수 있다면 다음 링크를 통해 적절한 애자일 프로젝트 관리 도구를 선택할 수 있습니다.

그리고 진지하게, 민첩한 방법론을 시도하십시오-그것은 모든 팀원이 다른 모든 회원의 역할과 노력을 이해하고 감사 할 수 있도록 당신이 무엇을하든 단순하고 우아하고 말도 안되며 재즈가없고 일반적인 감각적 접근법을 전파합니다.

행운을 빕니다!

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.