基本細節(jié) 相關(guān)模式： 系統(tǒng)間接口
預(yù)期頻率： 每個系統(tǒng)間接口有零到五個需求
模式分類： 無
適用性
使用系統(tǒng)間交互需求模式定義穿越系統(tǒng)間接口的特定類型的交互。
討論
一個通常的接口涉及很多不同類型的交互。一個信用卡支付服務(wù)可能主要用來讓零售商借錢給持卡人，但是這個接口需要做很多其他的事，比如取消交易以及檢查卡的信用額度。這些是業(yè)務(wù)相關(guān)的功能，但是接口可能也擁有大量的更偏向技術(shù)的和支持性的交互：發(fā)起一個連接（以及關(guān)閉）；請求重發(fā)前一個消息；通知狀態(tài)；等等。一個交互類型，為了這個需求模式的目的，意味著交換特定類型的信息——可能涉及雙方向的消息。例如，一個請求和相應(yīng)的響應(yīng)算作一個交互。
是否需要需求處理特定類型的交互很大程度依賴于誰擁有這個接口。有四種不同的情況需要我們處理，這四種情況對于為什么想要定義某一個類型的交互有直接的影響，反過來又影響描述需求的程度：
情況1： 我們擁有接口。使接口完善是我們的責(zé)任，所以定義需求時要避免遺漏任何東西。必須絞盡腦汁思考接口需要的所有的次要的交互；某些能力可以以概括的詞匯描述。
情況2： 我們不擁有接口，但是能影響接口的設(shè)計。在需求中確定和描述系統(tǒng)接口提供的特性。把接口的所有者當(dāng)作這些需求的主要讀者，所以盡量收集有力的證據(jù)使這些特性可以被實現(xiàn)。
記得這些需求不在我們的控制范圍內(nèi)，所以在接口的所有者接受之前，我們不知道接口是否能滿足需求。
情況3： 我們不擁有接口，也不能影響接口的設(shè)計，但是知道它是什么樣的。不要強迫所有需求規(guī)格的讀者都查閱接口規(guī)格，了解接口的詳情。在需求中總結(jié)每個交互是用的。需求可以抓住接口的本質(zhì)——例如，可以更容易估算工作量。越早知道實現(xiàn)接口的難度越好。
或者，可以編寫一個非正式的接口摘要而不是正式的需求。（盡管仍然需要把它們放在需求規(guī)格里。）這樣使你有機會包含一些主觀判斷（比如接口文檔的質(zhì)量，接口的整體復(fù)雜度等等）。可以要求開發(fā)人員研究這個接口并編寫摘要。
情況4： 我們不擁有接口，也不能影響接口的設(shè)計，也不知道它是什么樣的。陷入這種情況是危險的，但是確實可能。我們有可能被迫承諾開發(fā)一個接口，而對接口不了解——接口的范圍和棘手程度。把這個標記為需要關(guān)注的地方，盡快努力得到必要的信息。直到我們了解了接口的情況我們才能編寫交互類型的需求。
內(nèi)容
系統(tǒng)間交互需求模式需要包括下列內(nèi)容：
1.交互類型名稱 這樣可以引用它。
2.接口名稱和標識符 通過接口產(chǎn)生的交互必須是清楚的；需求的上下文（例如，遵循接口的主要需求）是不夠的。當(dāng)談到一個接口時，指出接口標識符以防止誤解。
3.交互目的 描述交互是為了什么。搞清楚是誰發(fā)起的。
4.傳遞的信息 這不需要是全面的。（確實，有時候完全沒必要描述。）只關(guān)注重要的信息。如果交互涉及雙方向的信息流，可以詳細的描述每個包含的信息——但是如果需求過于龐大（可能是超過半頁紙），可以分成獨立的需求。
模板 摘要 定義
《交互摘要》 《接口名稱》接口（《接口標識符》）將《交互目的描述》【至少傳遞以下信息：《傳遞的信息》】。
實例
下面是幾個我們擁有接口的系統(tǒng)間交互類型需求實例： 摘要 定義
告警監(jiān)視系統(tǒng)發(fā)出告警 告警監(jiān)視接口（i6）允許系統(tǒng)發(fā)出一個告警（也就是說，傳遞告警信息，通知所有適當(dāng)?shù)娜藛T）。一個發(fā)出告警的請求應(yīng)該至少包括如下信息：
n 消息標識符
n 消息正文
n 發(fā)生時間
n 告警被（人員或進程名稱）發(fā)出
告警監(jiān)視系統(tǒng)將回應(yīng)確認（或者回應(yīng)錯誤指示不能發(fā)出告警）。
數(shù)據(jù)倉庫接口狀態(tài) 系統(tǒng)與數(shù)據(jù)倉庫之間的接口（i2）應(yīng)該提供能力驗證接口以及數(shù)據(jù)倉庫系統(tǒng)本身的操作狀態(tài)。
額外需求
無
開發(fā)考慮
參考本章的系統(tǒng)間接口需求模式。
測試考慮
參考系統(tǒng)間接口需求模式，可以獲得測試接口的整體的概念。
系統(tǒng)間交互需求只是定義交互必須完成什么，它的目標。實現(xiàn)它反而可能會更復(fù)雜。例如，需求可能暗示一個請求有一個響應(yīng)，但是在實際中，可能會有兩個請求兩個響應(yīng)。因此，測試交互需求必須要只關(guān)注是否完成了定義的目標，而不是實現(xiàn)的細節(jié)。應(yīng)該做一些額外的測試驗證物理交互是否工作正常。數(shù)據(jù)流圖會對設(shè)計物理交互測試有幫助，但是對測試邏輯交互幫助不大。
簡潔的描述有效的情況和無效（錯誤）的情況。第一種情況下，識別那些有效但是意外的情況。有些交互不是每天發(fā)生，但是可能在任何時候出現(xiàn)，是否接口可以正確的處理這些有效的交互？絕對不可能測試所有的可能性，但是要盡量覆蓋有代表性的情況及其擴展情況。
預(yù)期頻率： 每個系統(tǒng)間接口有零到五個需求
模式分類： 無
適用性
使用系統(tǒng)間交互需求模式定義穿越系統(tǒng)間接口的特定類型的交互。
討論
一個通常的接口涉及很多不同類型的交互。一個信用卡支付服務(wù)可能主要用來讓零售商借錢給持卡人，但是這個接口需要做很多其他的事，比如取消交易以及檢查卡的信用額度。這些是業(yè)務(wù)相關(guān)的功能，但是接口可能也擁有大量的更偏向技術(shù)的和支持性的交互：發(fā)起一個連接（以及關(guān)閉）；請求重發(fā)前一個消息；通知狀態(tài)；等等。一個交互類型，為了這個需求模式的目的，意味著交換特定類型的信息——可能涉及雙方向的消息。例如，一個請求和相應(yīng)的響應(yīng)算作一個交互。
是否需要需求處理特定類型的交互很大程度依賴于誰擁有這個接口。有四種不同的情況需要我們處理，這四種情況對于為什么想要定義某一個類型的交互有直接的影響，反過來又影響描述需求的程度：
情況1： 我們擁有接口。使接口完善是我們的責(zé)任，所以定義需求時要避免遺漏任何東西。必須絞盡腦汁思考接口需要的所有的次要的交互；某些能力可以以概括的詞匯描述。
情況2： 我們不擁有接口，但是能影響接口的設(shè)計。在需求中確定和描述系統(tǒng)接口提供的特性。把接口的所有者當(dāng)作這些需求的主要讀者，所以盡量收集有力的證據(jù)使這些特性可以被實現(xiàn)。
記得這些需求不在我們的控制范圍內(nèi)，所以在接口的所有者接受之前，我們不知道接口是否能滿足需求。
情況3： 我們不擁有接口，也不能影響接口的設(shè)計，但是知道它是什么樣的。不要強迫所有需求規(guī)格的讀者都查閱接口規(guī)格，了解接口的詳情。在需求中總結(jié)每個交互是用的。需求可以抓住接口的本質(zhì)——例如，可以更容易估算工作量。越早知道實現(xiàn)接口的難度越好。
或者，可以編寫一個非正式的接口摘要而不是正式的需求。（盡管仍然需要把它們放在需求規(guī)格里。）這樣使你有機會包含一些主觀判斷（比如接口文檔的質(zhì)量，接口的整體復(fù)雜度等等）。可以要求開發(fā)人員研究這個接口并編寫摘要。
情況4： 我們不擁有接口，也不能影響接口的設(shè)計，也不知道它是什么樣的。陷入這種情況是危險的，但是確實可能。我們有可能被迫承諾開發(fā)一個接口，而對接口不了解——接口的范圍和棘手程度。把這個標記為需要關(guān)注的地方，盡快努力得到必要的信息。直到我們了解了接口的情況我們才能編寫交互類型的需求。
內(nèi)容
系統(tǒng)間交互需求模式需要包括下列內(nèi)容：
1.交互類型名稱 這樣可以引用它。
2.接口名稱和標識符 通過接口產(chǎn)生的交互必須是清楚的；需求的上下文（例如，遵循接口的主要需求）是不夠的。當(dāng)談到一個接口時，指出接口標識符以防止誤解。
3.交互目的 描述交互是為了什么。搞清楚是誰發(fā)起的。
4.傳遞的信息 這不需要是全面的。（確實，有時候完全沒必要描述。）只關(guān)注重要的信息。如果交互涉及雙方向的信息流，可以詳細的描述每個包含的信息——但是如果需求過于龐大（可能是超過半頁紙），可以分成獨立的需求。
模板 摘要 定義
《交互摘要》 《接口名稱》接口（《接口標識符》）將《交互目的描述》【至少傳遞以下信息：《傳遞的信息》】。
實例
下面是幾個我們擁有接口的系統(tǒng)間交互類型需求實例： 摘要 定義
告警監(jiān)視系統(tǒng)發(fā)出告警 告警監(jiān)視接口（i6）允許系統(tǒng)發(fā)出一個告警（也就是說，傳遞告警信息，通知所有適當(dāng)?shù)娜藛T）。一個發(fā)出告警的請求應(yīng)該至少包括如下信息：
n 消息標識符
n 消息正文
n 發(fā)生時間
n 告警被（人員或進程名稱）發(fā)出
告警監(jiān)視系統(tǒng)將回應(yīng)確認（或者回應(yīng)錯誤指示不能發(fā)出告警）。
數(shù)據(jù)倉庫接口狀態(tài) 系統(tǒng)與數(shù)據(jù)倉庫之間的接口（i2）應(yīng)該提供能力驗證接口以及數(shù)據(jù)倉庫系統(tǒng)本身的操作狀態(tài)。
額外需求
無
開發(fā)考慮
參考本章的系統(tǒng)間接口需求模式。
測試考慮
參考系統(tǒng)間接口需求模式，可以獲得測試接口的整體的概念。
系統(tǒng)間交互需求只是定義交互必須完成什么，它的目標。實現(xiàn)它反而可能會更復(fù)雜。例如，需求可能暗示一個請求有一個響應(yīng)，但是在實際中，可能會有兩個請求兩個響應(yīng)。因此，測試交互需求必須要只關(guān)注是否完成了定義的目標，而不是實現(xiàn)的細節(jié)。應(yīng)該做一些額外的測試驗證物理交互是否工作正常。數(shù)據(jù)流圖會對設(shè)計物理交互測試有幫助，但是對測試邏輯交互幫助不大。
簡潔的描述有效的情況和無效（錯誤）的情況。第一種情況下，識別那些有效但是意外的情況。有些交互不是每天發(fā)生，但是可能在任何時候出現(xiàn)，是否接口可以正確的處理這些有效的交互？絕對不可能測試所有的可能性，但是要盡量覆蓋有代表性的情況及其擴展情況。