大都知道，越早發(fā)現(xiàn)BUG，修復(fù)BUG的成本也越低。40-60%的bug是由錯(cuò)誤的需求引起的，而在測(cè)試階段修正需求錯(cuò)誤，無疑將花費(fèi)高昂的金錢成本與時(shí)間成本，業(yè)界普遍希望能夠在需求定義階段發(fā)現(xiàn)問題而不是之后發(fā)現(xiàn)問題。

　　Debug Requirement是一個(gè)新穎的概念，也是業(yè)界一直期望具備的一個(gè)能力。一般來說，需求文檔都是用自然語言書寫的，通過人工方式進(jìn)行檢查會(huì)存在諸多缺陷。Stimulus是法國(guó)Argosim公司推出的一款需求建模和仿真分析工具，可以幫助用戶檢測(cè)模棱兩可的、不正確的、丟失的、或相互沖突的需求。

　　如何通過Stimulus這款工具來Debug需求?下面的例子是一條關(guān)于車燈的簡(jiǎn)化需求：當(dāng)車燈處于“自動(dòng)”模式時(shí)，頂燈的開與關(guān)取決于環(huán)境光強(qiáng)度，并通過系統(tǒng)預(yù)設(shè)條件來避免頂燈出現(xiàn)頻繁閃爍的狀況。

　　REQ_003Aa 車燈開關(guān)撥到AUTO位置，且環(huán)境光強(qiáng)度≤70%，頂燈應(yīng)保持ON狀態(tài)或立即進(jìn)入ON狀態(tài)。光強(qiáng)度不超過70%，頂燈保持ON狀態(tài)，車燈開關(guān)保持AUTO狀態(tài)。

　　REQ_003Ab 車燈開關(guān)撥到AUTO位置，且環(huán)境光強(qiáng)度>70%，頂燈應(yīng)保持OFF狀態(tài)或立即進(jìn)入OFF狀態(tài)。光強(qiáng)度不低于70%，頂燈保持OFF狀態(tài)，車燈開關(guān)保持AUTO狀態(tài)。

　　REQ_003B 車燈開關(guān)已在AUTO位置，而頂燈在OFF狀態(tài)，且光強(qiáng)度低于60%，那么頂燈需在此條件下進(jìn)入ON狀態(tài)至少2秒。

　　REQ_003C 車燈開關(guān)已在AUTO位置，而頭頂燈在ON狀態(tài)，且光強(qiáng)度高于70%，那么頂燈需在此條件下進(jìn)入OFF狀態(tài)至少3秒。

　　這幾條需求涉及到比較復(fù)雜的邏輯關(guān)系，人工檢查可能要花費(fèi)很長(zhǎng)時(shí)間才能確定需求是否存在BUG。使用Stimulus這款工具對(duì)需求進(jìn)行Debug后，可以清晰的看到，頂燈次進(jìn)入OFF狀態(tài)后，頂燈的開與關(guān)幾乎變成了一個(gè)隨機(jī)事件，需求中必然存在嚴(yán)重的邏輯缺陷。

　　Stimulus創(chuàng)造性的自然語言需求建模及仿真驗(yàn)證技術(shù)，使得在需求定義階段即可對(duì)需求進(jìn)行Debug，像Debug代碼一樣Debug需求，在時(shí)間發(fā)現(xiàn)需求文檔中的錯(cuò)誤。

　　Stimulus提供支持行業(yè)慣例的文本寫作模型/模板，用戶可以很容易的設(shè)計(jì)標(biāo)準(zhǔn)化的需求，同時(shí)支持共享清晰、易理解的需求。

　　用戶可以使用生成的測(cè)試場(chǎng)景對(duì)需求進(jìn)行仿真和調(diào)試，生成系統(tǒng)有可能出現(xiàn)的行為，通過觀察發(fā)現(xiàn)不正確及不完整的需求。

　　一旦系統(tǒng)已經(jīng)開發(fā)，需求仿真和調(diào)試時(shí)系統(tǒng)生成的一般測(cè)試場(chǎng)景即可被重用，用戶可以將其導(dǎo)出生成測(cè)試用例，并在SIL環(huán)境中重新運(yùn)行。

　　北京經(jīng)緯恒潤(rùn)科技有限公司成功代理Argosim公司的Stimulus產(chǎn)品，成為Argosim公司的業(yè)務(wù)合作伙伴，并負(fù)責(zé)中國(guó)地區(qū)的推廣工作，有任何的產(chǎn)品/方案咨詢可聯(lián)系010-64840808。