系統(tǒng)邊界，即系統(tǒng)包含的功能與系統(tǒng)不包含的功能之間的界限。一般在系統(tǒng)分析階段定義，只有明確了系統(tǒng)邊界，才能繼續(xù)進行下面的分析、設計等工作。

　　不論這個系統(tǒng)是產(chǎn)品還是項目。所謂邊界，也就是將這個系統(tǒng)看成一個黑盒子，和外界的交互。"這，是一個黑色的立方體，長45厘米，寬23厘米，高3厘米，盒子的每個角都不尖銳，上方平坦，并有柔軟質(zhì)感；下方在四角之處都有凹進去的螺絲口，可以接桿子，以作凳子用。"

　　這就是僅僅對其功用的描述，其目標是作凳子用。這可以看作是功能性需求，當然如果還有一些約束，例如"此立方體可以承受300斤胖人之重"，這就可以看作是非功能性需求。但同樣還是在描述邊界。而對于其內(nèi)部構造如何，在需求中不要描述，例如盒子是空心的還是實心的，材質(zhì)用鋼板還是木頭，這都不是需求，而是已經(jīng)在設計了。

　　因此，在描述需求的時候，重要的就是界定系統(tǒng)的內(nèi)外。看過很多的需求，自己也寫過很多的需求，界定內(nèi)外不是容易的事情。有幾個原因，一是沒有內(nèi)外的概念，不知道需求描述的是什么；二是知道內(nèi)外，然而對于邊界的定義，沒有足夠的詞語描述清楚，只能用對系統(tǒng)內(nèi)部設計來代替。這樣的結果是，一份需求書，你搞不清楚它是需求還是設計。　　

　　譬如有的需求書，它描述了系統(tǒng)內(nèi)部模塊劃分，三層結構，數(shù)據(jù)存儲、中間邏輯等等。比如專題分析的需求中，包含了對挖掘變量的描述，嗬，將上百個變量列在文檔中確實能夠讓頁數(shù)增加。然而這恐怕不是閱讀對象關心的，也不符合分離變化與不變的原則。需求書的閱讀對象關心的是系統(tǒng)是什么，而非如何實現(xiàn)。系統(tǒng)是什么是相對不變的，而實現(xiàn)方式卻是相對變化的。例如上面盒子的例子，用它作凳子是不變的，而至于用木頭或是鋼材，是后面考慮，可能會反復變化的。對于專題分析也是如此，這個分析針對的業(yè)務問題，諸如哪些客戶最有可能離網(wǎng)，這個目標是相對固定的。而你是考慮使用呼轉次數(shù)或是話費突降的角度來考慮，這是變化的。因此，在需求中，絕對不要將設計的東西加入進去（除非你是想便于說明問題），因為那種東西不能夠作為一種"規(guī)格"，用于驗收、測試的標準。

　　當然，有時候根據(jù)客戶在作要求的時候，并非完全從系統(tǒng)邊界上考慮，而真的會從系統(tǒng)內(nèi)部提要求。譬如說，這個凳子，你就得用鋼板，不能用木板，至于為什么，可能這僅僅是他的喜好。軟件系統(tǒng)也是如此，有時候他會提出要求，你就得用某種產(chǎn)品，你就得用分類模型或者是神經(jīng)元算法來實現(xiàn)。面對這樣的要求，我也不知道該如何在需求書中表述，難道寫上一堆系統(tǒng)約束——必須用叉叉產(chǎn)品，不得在系統(tǒng)中出現(xiàn)任何英文字母…？

轉自：http://blog.163.com/ysd-spring/blog/static/13430106720102263928311/

轉載于:https://www.cnblogs.com/Edifier/archive/2011/01/04/1925474.html

總結

以上是生活随笔為你收集整理的系统边界的定义的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。