需求分析階段完了以后，就是需求設(shè)計(jì)，然后就是需求實(shí)現(xiàn)了，過程看起來很簡單，但是實(shí)際工作不簡單，上面談到的需求管理的幾點(diǎn)嚴(yán)格要求一直貫穿著整個(gè)過程的始末。
接下來我會(huì)結(jié)合我們公司實(shí)際的流程來介紹一下需求管理的實(shí)際實(shí)現(xiàn)。
如果看過我之前的文章，應(yīng)該知道我們公司的背景，我們公司也是做軟件開發(fā)的，所以對于需求管理這塊也是相當(dāng)重視的。我們是用敏捷的模式來管理整個(gè)軟件開發(fā)的，所以需求管理的階段也是符合敏捷的模式的，但是對于需求管理的幾點(diǎn)嚴(yán)格要求還是基本上也是遵守的。
我們公司是用 TechExcel 的需求管理工具 DevSpec 來管理整個(gè)需求過程的，其實(shí)我們是買了他們的整套軟件生命周期管理的解決方案，名稱叫做DevSuite，而DevSpec 是其中一個(gè)工具，能與DevSuite 解決方案的其他工具無縫集成，幫助共同管理開發(fā)、測試、計(jì)劃等階段。
在DevSpec中，對于需求的管理是通過條目化的方式來管理的，所謂的條目化就是說一個(gè)需求就是一個(gè)條目，這個(gè)條目既包括了對這個(gè)需求的描述，還包括了對這個(gè)需求的處理過程的跟蹤：
對于需求的描述而言，DevSpec是通過屬性字段的方式實(shí)現(xiàn)的，你可以用字段來盡可能真實(shí)描述需求，其中包括標(biāo)題，狀態(tài)，負(fù)責(zé)人，描述，時(shí)間，附件等基本字段，當(dāng)然你還可以大量自定義屬性字段和頁面來幫助更好地描述這個(gè)需求。
對于需求的處理過程而言，
我們知道需求的處理是要有流程的，簡單的就是從需求分析-->需求設(shè)計(jì)-->需求實(shí)現(xiàn)，復(fù)雜點(diǎn)的還需要加上審核，就像我上面給大家看過的那個(gè)流程圖一樣， 我這里再貼一下
不過光有流程其實(shí)沒用，我相信任何公司的需求處理都會(huì)有流程，只是嚴(yán)格不嚴(yán)格，認(rèn)真不認(rèn)真的區(qū)別罷了，不遵照流程處理的需求有非常高的可能性不成功，所以為了解決這個(gè)問題，DevSpec 中專門設(shè)計(jì)可自定義的工作流程，你可以自己定義需求需要經(jīng)過哪些流程才能進(jìn)入開發(fā)，而一旦流程定義完成以后，需求的處理就會(huì)被強(qiáng)制按照流程的進(jìn)行，你自己想馬虎馬虎，松懈松懈都沒辦法做到。
在流程中，DevSpec可以給每個(gè)過程設(shè)置不同負(fù)責(zé)人和權(quán)限，比如分析這個(gè)過程是小王處理，所以只有小王才能看到這個(gè)需求并且處理這個(gè)需求，其他人如果沒有權(quán)限就看不到這個(gè)需求；而小王處理完他的工作后，他不一定有權(quán)力把這個(gè)需求轉(zhuǎn)到下一個(gè)過程，因?yàn)樾枰硗庖粋€(gè)人審核以后才能繼續(xù)下去。
這樣子的話，
第一，你的處理流程會(huì)很清晰，這一步處理完了，下一步是什么，一目了然；
第二，你的管理流程也很透明，現(xiàn)在誰處理，接下來該誰處理，清清楚楚。
第三，你的權(quán)力流程也很明了，什么級(jí)別的人能做什么事情都可以設(shè)置，哪些該做的不該做的，哪些該看不該看的，都很簡單就可以設(shè)置，避免了一些人看到不該看的內(nèi)容，做了不該做的事情。
有了這些屬性和流程，我們就可以正式開始 DevSpec 的需求管理了.
（未完待續(xù)）