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

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

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

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

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

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

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

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

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。