敏捷開發框架/資源下的軟體工程
本節不會保持這種狀態。它是本書其餘部分的暫存區。
最終，一個名為“資源”的章節將包含本書中所有活動的空白模板。
環境報告
該專案最終使用所在的環境將從只有幾個人觀看時的非常安靜，到學校旅行觀看展覽時的非常吵鬧。目標專案受眾在人數眾多時最有可能非常吵鬧。由於蝴蝶需要空調，總體溫度會相當恆定。照明也會保持恆定，因為專案將在室內進行，並且易於控制。在棲息地，將有大約 28 攝氏度的恆定溫度和 90% 的溼度，溫度在夜間僅略微下降。由於任何硬體都將完全包含在棲息地內部或外部，因此氣候不會造成任何明顯的問題。
| Tithlyon 解決方案 - 決策矩陣 | |||||||||
|
專案 Digifly |
彈出式圖書/教科書 | 互動式展品 | 互動式 DVD/CD 光碟 | 影片紀錄片 | 虛擬現實 | ||||
| 功能需求 | 優先順序 | 權重 1-10 | ' ' | ||||||
| 允許博物館擁有一個基於蝴蝶的互動軟體活動 | 至關重要 | 10 | 40% | 100% | 90% | 40% | 100% | ||
| 允許人們建立他們自己的虛擬蝴蝶 | 至關重要 | 10 | 10% | 100% | 100% | 10% | 100% | ||
| 允許將輸入資料庫的蝴蝶由其建立者檢索 | 至關重要 | 9 | 0% | 100% | 100% | 0% | 95% | ||
| 蝴蝶將飛行、移動並與環境互動 | 至關重要 | 6 | 50% | 95% | 65% | 80% | 100% | ||
| 蝴蝶將在設定的時間後從資料庫中刪除 | 至關重要 | 7 | 0% | 100% | 80% | 0% | 100% | ||
| 必須迎合 10 歲及以上的人群 | 至關重要 | 9 | 50% | 95% | 95% | 75% | 80% | ||
| 足夠靈活以處理不同的主題 | 有用 | 3 | 0% | 100% | 80% | 0% | 100% | ||
| 為使用者提供一個機會，讓他們帶回家與展品相關的物品 | 有用 | 3 | 50% | 100% | 100% | 50% | 70% | ||
| 必須有斷電時的關機程式 | 至關重要 | 10 | 0% | 100% | 100% | 100% | 100% |
| 具有某種螢幕保護程式 | 至關重要 | 10 | 0% | 100% | 100% | 100% | 100% | ||
| 展示自然生命週期 | 至關重要 | 10 | 100% | 100% | 100% | 100% | 100% |
| 易於使用（針對公眾） | 至關重要 | 10 | 100% | 100% | 80% | 100% | 50% | ||||||||||
| 總數 | 107 | 31.78% | 99.30% | 92.94% | 63.60% | 92.38% | |||||||||||
| 約束條件 | |||||||||||||||||
| 對使用者來說不應該像一臺電腦 | |x||x | ||||||||||||||||
| 為使用者提供一個返回的理由 | | | ||||||||||||||||
| 能夠每天處理 300 到 1000 人 | |x | ||||||||||||||||
| 完全健壯 | |x | ||||||||||||||||
| 在 28 攝氏度和 90% 溼度的環境中正常執行 | | | ||||||||||||||||
| 無人值守執行並儘可能少地維護 | |x| |
在啟動時顯示版本號等 | |
顯示區域之間的視覺關係 | |
|滿足約束條件 | |||||||||||
| 'x' | 違反約束條件 | ||||||||||||||||
故事板對我們的開發至關重要。由於我們都討厭文件，因此我們儘可能多地使用故事板，這節省了大量的時間和誤解，因為我們都可以看到其他人的想法。
介面故事板有多個階段，其中更改了許多細節，並且發現了許多潛在的問題。大部分故事板製作是在前三個月完成的，幾乎沒有在主要白板上的後期故事板，這些故事板是對原始故事板的微小修改。
以下故事板用於演示，向客戶展示整體設計理念，並說明我們目前對介面需求的理解。最終產品與以下故事板有兩個主要變化：沒有 VR 部分，取而代之的是第三人稱飛行部分，並且投影顯示已成為最終部分。這兩個變化都不需要任何故事板來實現，因此從未製作過。
功能需求
| 需求系統應 | 說明 | |
| FR 1 | 允許博物館擁有一個基於蝴蝶的互動軟體活動。 | 博物館為博物館的訪客提供學習體驗。 |
| FR 2 | 允許人們建立他們自己的虛擬蝴蝶。 | 將提供功能以允許人們設計自己的蝴蝶。 |
| FR 3 | 允許將輸入資料庫的蝴蝶由其建立者檢索。 | 資料庫將儲存蝴蝶，以便人們可以回來再次檢視它們。 |
| FR 4 | 限制使用者使用系統的時間量。 | 為了保持佇列移動，以便更多人可以使用系統。 |
| FR 5 | 吸引成年人和兒童。 | 吸引儘可能多的人群的需求是一個重要的因素。 |
| FR 6 | 蝴蝶將飛行、移動並與環境互動。 | 為了讓顯示內容更有趣，並提供更好的整體體驗。 |
| FR 7 | 蝴蝶將在設定的時間後被刪除。 | 為了為更多蝴蝶騰出資源，並完成生命週期。資料庫檔案將保留，但會停用，因為刪除任何資料庫內容都是不好的做法。 |
| FR 8 | 展示自然生命週期。 | 蝴蝶的完整生命週期，展示四個主要階段。 |
| FR 9 | 迎合 8 歲及以上的人群。 | 8 歲以上的大多數人無需幫助即可使用。 |
| FR10 | 足夠靈活以處理不同的主題。 | 整體設計應該能夠處理更改以顯示另一個概念。 |
| FR11 | 為使用者提供一個機會，讓他們帶回家與展品相關的物品。 | 博物館希望他們的訪客帶走一些實物以供參考，同時宣傳博物館和熱帶植物園，以吸引新訪客和回頭客。 |
| FR12 | 必須有斷電時的關機程式。 | 博物館中有許多帶電顯示裝置。關機順序比開關更復雜，因此是可取的。 |
| FR13 | 必須有開機時的啟動程式。 | 與關機相同。開機與關機一樣複雜的任務，應在啟動顯示器時要求博物館工作人員執行。 |
| FR14 | 具有某種螢幕保護程式。 | 需要螢幕保護程式，因為顯示器將執行很長時間。此外，還需要一個“螢幕保護程式”迴圈來吸引使用者並告知使用者產品。 |
| C1 | 對使用者來說不應該像一臺電腦。 | 大多數人發現電腦可能令人生畏、無聊或普通。所有這些都不是可能吸引使用者與之互動的方面。 |
| C2 | 無人值守執行並免維護。 | 由於長時間內幾乎無法進行維護，因此係統無需定期維護才能執行的需求非常大。 |
| C3 | 完全健壯。 | 能夠承受博物館互動式展品的磨損。 |
| C 5 | 在啟動時顯示版本號等。 | 需要版本號，以便不會混淆當前正在執行的軟體/硬體版本。在維護或升級軟體時很重要。 |
| C6 | 在潮溼和變化的環境中正常執行。 | 蝴蝶屋內的條件為 28 攝氏度和 90% 的溼度。該系統還可能在一段時間內安裝在博物館門廳或其他可能具有不同條件的區域。 |
| C7 | 能夠每天處理 1000 個使用者。 | 博物館遊客數量波動較大，受假期和天氣等因素影響。同時，也經常會有旅遊團或學校團等大型團體參觀。這意味著系統可能在一天中持續使用，也可能完全不使用。 |
| C8 | 提供不同級別的資訊 | 能夠滿足那些想要了解更多的人。 |
| C9 | 為使用者提供一個返回的理由 | 使用者會反覆回到展覽的一些原因。 |
鎖定在昂貴的軟體系統中 歷史資料遠端儲存，難以訪問或調整 即將到來的立法要求保留所有預訂和排程資料的歷史記錄
預訂表 預訂表用於儲存特定預訂資訊，這些資訊在成功成為工作後會記錄在工作表中。與地址表之間有兩種關係，一種用於引用接送地址，另一種用於引用目的地地址。與班次表之間也有兩種關係，一種用於記錄操作員，另一種用於記錄排程員。 關係 地址 1..N 預訂（用於接送地址） 地址 1..N 預訂（用於目的地地址） 班次 1 .. N 預訂（用於操作員） 班次 1 .. N 預訂（用於排程員） 班次 1..N 預訂（用於計程車）
Booking.BookingID 通用資訊 此欄位是表的主鍵。它主要用於將自身引用到工作表上的記錄。 值 此欄位包含整數 來源 建立記錄時，該值由 Access 自動分配 技術規格 資料型別：自動編號 必須唯一：是 預設值：由 Access 分配 主鍵
Booking.PickupID（Address.AddressID） 通用資訊 引用地址表中的一個地址作為預訂的接送地址 來源 操作員建立記錄時輸入此資料。它可以稍後編輯。 技術規格 外部索引鍵 檢視地址表瞭解更多資訊 Booking.DestinationID（Address.AddressID） 通用資訊 引用地址表中的一個地址作為預訂的目的地地址 來源 操作員建立記錄時輸入此資料。它可以稍後編輯。 技術規格 外部索引鍵 檢視地址表瞭解更多資訊
Booking.BookingCustomerName 通用資訊 儲存預訂客戶的姓名 值 此欄位可以包含任何文字，最多 255 個字元 來源 操作員建立記錄時輸入此資料。它可以稍後編輯。 技術規格 資料型別：文字 必須唯一：否 預設值：NULL
Address.AddressShortcut 通用資訊 儲存操作員在前端使用的快捷方式，以便快速引用熱門公共場所。 值 此欄位可以包含任何文字，最多 10 個字元 來源 控制室主管在特殊介面管理此資料 技術規格 資料型別：文字 必須唯一：是 預設值：NULL
Address.AddressCustomerName 通用資訊 儲存與地址關聯的客戶姓名。 值 此欄位可以包含任何文字，最多 255 個字元 來源 操作員建立記錄時輸入此資料。它可以稍後編輯。 技術規格 資料型別：文字 必須唯一：否 預設值：NULL
Booking.BookingTaxiShiftNumber（Shift.ShiftID） 通用資訊 此欄位引用執行結果工作的計程車的班次 來源 排程員將預訂分配給出租車作為工作時輸入此資料 技術規格 外部索引鍵
檢視班次表瞭解更多資訊
Booking.PostDispatchNote 通用資訊 此欄位包含排程員輸入的有關排程工作的任何備註 值 此欄位包含任何形式的文字，最多 255 個字元 來源 排程員將預訂分配給出租車作為工作時輸入此資料 技術規格 資料型別：文字 必須唯一：否 預設值：NULL
團隊管理合同
innovate.It 的成員將按以下方式進行會議
• 星期一 3:30 開始（大約 5 小時） • 每週至少一個其他晚上，事先安排（大約 2.5 小時）
此外，團隊成員將在自己的時間內完成至少 2.5 小時的工作。
如果情況導致上述情況無法實現，則將做出安排以彌補時間。
溝通 • 任何成員都可以與講師/客戶溝通 • 演示將作為小組進行 • 與利益相關者/使用者進行的任何會議都需要專案代表詳細記錄，帶回小組，並儲存在中央文件持有者中 • 團隊成員之間的溝通將透過電子郵件和簡訊進行，使用 Blackboard 作為公共資訊系統 • 團隊成員必須每週至少相互溝通一次 • 團隊成員必須在遇到任何不清楚的地方尋求澄清 - 作為一個團隊前進，而不是作為個人 • 團隊成員應該樂於分享想法，並讓團隊成員傾聽和討論這些想法 • 每月將根據設定的模板（位於 Blackboard 中）向客戶提供進度報告，在此時間之外，將根據需要進行聯絡 • 客戶在進度報告後至少每月提供一次反饋
程式 • 文件標準 - 標準格式、清晰簡潔、適當使用空白、資訊邏輯流動、標題與文字區分、目錄、頁面格式/編號、一種字型（12pt Times Roman） • 主文件放在 Blackboard 上供小組訪問 • Hamish 每週（週一下午）備份 Blackboard 上的文件 • 所有文件上使用標準小組徽標 • 圖片/圖形使用得當，而不是為了美觀 • 最終文件的標準將由一個尚未確定的獨立人員檢查，並基於相關經驗 • 截止日期：使用指導表，列出每個步驟並儲存在 Blackboard 上供小組訪問 • 演示：所有演示的工作儘可能簡單，並將包含所有關鍵要點
管理 • 小組應遵守 NZCS 概述的相同道德準則，例如保證能力、責任、問責制、良好實踐、道德標準、風險理解和管理、他人看法、誠信和忠誠、可靠性、保密性。 • 我們向客戶提出的提案大綱應包括目標和可交付成果。我們將確定所需資源，並按照向客戶概述的專案計劃進行。任何修訂都應儘快解釋。文件將在最終演示之前進行審查。
通用策略 • 與所有利益相關者的溝通將是透明和定期的 • 任何小組無法解決的問題將由講師進行調解。 • 任何需要的資源將透過與奧塔哥理工學院或客戶的協商獲得。
放棄 • 如果團隊成員在三週內未與專案主管或其他團隊成員聯絡，則應視為放棄專案，除非事先通知。 • 一旦放棄，違反規定的成員將把所有專案材料和狀態移交給剩餘成員。 • 任何指定的替換成員可以根據專案主管的決定繼承到目前為止的專案材料和狀態。 • 如果客戶放棄專案，則專案主管將自行決定專案是否繼續與其他客戶合作，或者團隊是否加入或開始其他專案。
審查 • 進度將進行審查；在客戶聯絡後，在每次 scrum 會議期間，以及在每次迭代的評估階段（即原型審查）期間。 • 在客戶聯絡後，將填寫“客戶聯絡”表格。
成績分配 • 所有成員將獲得相同的成績，除非成員不符合本檔案的規定。任何成績調整將由專案主管決定。
專案執行摘要
該專案的目的是為 City Taxis 提供一個排程系統。排程系統應儘快投入使用。
我們使用了一種將迭代思維和敏捷思維相結合的方法。我們相信理解在整個專案中不斷增長，因此透過使用原型和定期與利益相關者會面，將創造建設性的反饋，以確保成功實施系統。該系統應方便排程並提供歷史記錄。
目前已識別出的主要風險包括：缺乏立法合規性、隱私洩露、資料不準確、資料不安全。
專案名稱：計程車排程系統
團隊名稱：innovate.It 團隊成員：Hamish Smith、Shane van Dyk
客戶：Allan Ward，City Taxis 專案贊助人：奧塔哥理工學院 專案主管：Sam Mann
專案描述
目標：提供一個能夠輕鬆成功地進行計程車排程，同時準確記錄所有必要資料的系統。 1. 準確記錄所有排程的記錄 2. 方便地提供當前的排程狀態 3. 跟蹤所有計程車的狀態 4. 及時完成所有排程
第二部分：業務概述 業務宣告 City Taxis 提供“大但尼丁地區”的交通服務，無論是觀光、商務還是休閒。
City Taxis 為但尼丁提供優質交通服務 55 年。
他們是但尼丁所有領先酒店和汽車旅館的首選出租車公司。也是該市許多領先企業的首選承運人。
無論是您的計程車費用是個人支出，還是記入您的公司或僱主賬目，在當今審慎的會計時代，選擇能夠以經濟的價格提供優質服務的承運人才是明智之舉。 City Taxis 將為您做到這一點。
客戶使命宣言：我們提供優質服務，擁有現代車隊和高素質的司機。
我們努力成為最好，決不低於此。
City Taxis 為但尼丁人民提供 55 年的優質服務，我們致力於為客戶提供最優質的服務和物超所值的服務。
第三部分：方法 專案方法
敏捷方法鼓勵現實的進度和資源分配，允許專案需求和技術複雜性的變化。它還考慮了團隊成員的技術短板以及對適當技術的訪問。分階段的生命週期方法幫助團隊瞭解要執行的活動、每個階段的交付成果、活動和不同階段之間的不同型別的通訊，以及在進行到下一階段之前確定每個階段的交付成果是否令人滿意。每個迴圈的相對速度意味著團隊和客戶會多次重新審視專案的各個階段，因此完成滿足客戶需求的專案的可能性更高。這也允許靈活地適應不斷變化的客戶/專案需求。定期使用“Scrum”會議（團隊成員和客戶之間每 15 分鐘的定期會議）促進了團隊成員和客戶之間的高標準溝通，並將重點放在下一步要做什麼以及誰在做什麼。原型使用允許客戶定期以動覺方式體驗專案的開發。這促進了客戶的建設性反饋，並增加了專案朝著滿足利益相關者需求的方向發展的可能性。由於在整個專案中都在進行構建和評估，因此最終產品滿足利益相關者需求的可能性更大。不期望所有各方在專案早期就達成共識。預計隨著所有各方參與構建和評估過程，理解將不斷加深。
專案概述
專案描述
City Taxis 需要一個改進的排程系統，該系統可以輕鬆高效地促進出租車排程，同時準確記錄所有必要的資料。City Taxis 的主要樞紐包括電話接線員和一名排程員。電話接線員處理客戶預訂。排程員分配工作並與司機溝通。目前的系統似乎在辦公室環境中很好地促進了排程工作，但成本很高。計程車司機與總部之間的當前通訊系統似乎存在時間延遲，並且對司機的干擾比認為必要的更多。輕鬆訪問儲存的資料至關重要，因為未來的立法要求規定警方可以訪問某些資料。客戶的直接願望是建立一個能夠準確記錄排程資料以供將來參考的系統，同時提供一個易於使用的前端介面。
專案風險 軟體開發本質上存在風險和不確定性，這就是為什麼我們需要在專案開始時設定明確且可衡量的目標。主要的專案風險包括軟體無法滿足使用者期望以及軟體開發人員無法為使用者生成可執行或可工作的系統。此外，
• 無法獲得使用者承諾 • 使用者參與不足 • 誤解使用者需求 • 無法管理終端使用者期望 • 不同使用者之間的衝突 • 使用者培訓不足 • 時間不足
綠卡，紅卡 在流程的早期，我們為 City Taxis 的員工留下了卡片系統，讓他們用來評論他們當前的系統。他們喜歡的事情可以寫在綠卡上，需要改進的事情可以寫在紅卡上。
7 月 23 日討論
• 預訂始終需要電話號碼和姓名 • 會出現沒有街道地址的情況。在這種情況下，接送需要有一個位置，需要提供一個郊區和一個區域 • 從理論上講，地址表中是否存在重複的位置條目並不重要 • 快捷方式不會動態更新，並且將有自己的介面用於編輯 • 說明是可選欄位 • 地址號碼不是強制性的 • 適用於接送的規則也適用於目的地 • 車輛型別是可選欄位，預設情況下為空 • 所需時間是強制性的，預設值為當前時間 • 乘客人數是可選的 • 大型行李箱將從表單中刪除 • 腳踏車架的真值將生成“，腳踏車架”以連線到排程螢幕的車輛型別欄位。這種情況發生在生成排程資料時 • 預訂需要接送地點和目的地
預訂表單的當前狀態 • 如果沒有街道名稱，資料將無法正確記錄 • 目前沒有預訂驗證流程，無論資料量有多少，任何內容都可以輸入，儘管如果缺少某些資料，則不會建立任何資料 • 如果進行空白預訂，則不會進行任何資料傳遞，但仍會顯示“預訂已儲存”對話方塊 • 預訂需要接送地址和目的地地址，否則不會記錄任何新資料
TaxiDispatch 功能釋出
2007 年 8 月 13 日
在去 City Taxis 之前，我對預訂表單上的程式碼做了最後一次修改，使電話號碼可選。這更適合他們目前的需要。
到達後，我將資料庫拆分，將後端放在計算機上的資料夾中，用作排程員工作站，對映為 City Taxis 區域網上的“T: 驅動器”。我將前端打包成安裝檔案，並將安裝檔案建立到我們理工大學計算機上的共享資料夾中。該程式安裝在 City Taxis 網路上的所有機器上，並開始測試。
測試中出現的問題和建議包括：• 排程作業螢幕無法正常工作。如果螢幕上有多個作業，作業將不會清除。這可能只是一個程式設計錯誤。• 儲存預訂或清除預訂表單後，會出現大約三秒鐘的延遲。大多數情況下這沒問題，但在繁忙時間可能會成為問題。即便如此，在任何時候，三秒鐘的延遲都足以讓人感到厭煩。• 無法取消預訂。• 我們沒有為不同的車輛型別提供便利。沒有施加任何限制，這意味著可以為一輛車預訂 6 位乘客，即使這在物理上是不可能的。• 用於幫助提供地址詳細資訊的下拉框不適用於向下箭頭鍵。• 特殊說明似乎沒有進入資料庫。• 對街道資料庫進行了各種更正，並對位置快捷方式列表進行了補充，但仍需要進行一些更改。• 有人建議在下一個版本中，排程員需要能夠隨時重新定位板上的一輛車。
我花了一個多小時向值班人員展示預訂表單，並監督他們的使用。之後，我坐在排程員的辦公桌前觀察排程員，並隨時準備記下建議、意見和問題。我能夠使用理工大學計算機直接訪問後端並編輯表中的資料，從而立即解決現場的一些資料問題。
開發順序
• 檢視排程板並討論線框介面 • 設計線框介面 • 紙質原型 • 設計選項 • 平臺討論 • 建立基本原型 • 做出平臺決策 • 任務分析 • 詳細介面 • 後端開發/遷移 • 建立邏輯過程層 • 構建/修改預訂前端 • 構建/修改排程前端 • 構建/修改歷史記錄和配置前端 • 資料字典 • 技術文件 • 軟體手冊 • 幫助結構 • 測試 • 現場測試 • 即時穩健釋出
排除 • 物理板：不實用，不符合客戶的需求
組合選項：1. 訪問表 + 訪問查詢 + 訪問表單 2. SQL Server + 訪問查詢 + 訪問表單 3. SQL Server + 儲存過程 (SQL Server) + Windows 應用程式 4. SQL Server + ColdFusion + HTML 5. 訪問表 + ColdFusion 或 PHP + HTML 6. SQL Server + ColdFusion 或 PHP + Google Maps
排除 • 選項 6：Google Maps 與線框介面的要求不匹配 • 選項 1 和 2：這些選項使用訪問表單，這些表單實際上不支援線框介面的功能 • 選項 4 和 5：這些選項使用 HTML 作為前端。它沒有適當的編碼環境，這將使支援我們的線框介面變得複雜且困難
留下 • 選項 3：SQL Server + 儲存過程 (SQL Server) + Windows 應用程式
SQL Server 是最適合的後端，因為與 Access 不同，它專為多使用者環境設計，並且具有更好的穩定性和備份功能。它對我們使用資料的限制也更少。
SQL Server 上的儲存過程將構成一個良好的邏輯層，因為它們與實際資料保持緊密聯絡，一旦建立，它將使前端開發變得更加容易。為適應前端的需求，有更大的範圍來定製過程。
獨立的 Windows 應用程式也是構建前端的最佳平臺，因為我們將自行設計和構建它，我們可以使其滿足我們的要求。Microsoft Visual Studio 可能是最好的編碼環境，因為它將擁有連線到 SQL Server 資料來源的功能。
你的時尚
[edit | edit source]
1. 系統應儲存使用者資料（使用者需註冊為會員，擁有使用者名稱和密碼才能使用網站並建立資料） 2. 系統應提供個性化反饋 3. 系統應儲存使用者購買歷史記錄 4. 系統應成為一個“專家”系統 5. 系統應包含基於網路的元件 6. 系統應整合虛擬社群/論壇 7. 系統應提供二手服裝線上拍賣功能 8. 系統應儲存搜尋引數 9. 系統應“智慧”地提供針對性的促銷優惠 10. 系統應訪問零售商的商品資料庫 11. 系統應展示商店的相關產品 12. 使用者應能夠就服裝選擇對其他使用者的資料進行評分 13. 使用者可以編輯自己的資料 14. 使用者可以刪除自己的資料 15. 系統應為使用者提供建立多個資料的選項 16. 零售商可以隨時上傳新的服裝系列 17. 系統應允許使用者在使用者同意的情況下檢視其他使用者的資料 18. 系統應整合高質量的圖形，並提供充足的空白區域，以提升易用性 19. 系統應允許在線上使用時進行更新 20. 系統應在出現任何停機時通知開發人員，例如輸出訊息“零售商XY，喬治街111號的螢幕B無響應” 21. 系統應使用移動平臺（如手機、PDA、MP3播放器）實現便攜性（因此，資料檔案大小很重要） 22. 系統應能夠使用56K連線線上建立資料 23. 系統應能夠使用藍牙技術傳送針對性的簡訊 24. 使用者應能夠搜尋過去的購買者（例如，在過去3個月、6個月、12個月內購買過的使用者等） 25. 使用者應能夠將自己的衣櫥物品新增到資料中，以完善資料（可能需要設定上限，例如使用低解析度影像的50件服裝） 26. 系統應根據使用者資料將建議限制在所有可能組合中評分最高的五項 27. 使用者應能夠透過新增資訊（例如，向虛擬衣櫥新增物品）持續完善資料 28. 零售商應能夠使用系統向目標使用者資料傳送購買建議（例如，年齡在30-35歲之間、年收入超過35,000美元、梨形身材、皮膚白皙的女性） 29. 使用者應能夠透過高階搜尋（例如，特定風格、零售商、價格等）線上搜尋衣櫥建議 30. 使用者應能夠檢視生成的時尚物品，並與其他建議物品進行互換 31. 使用者應能夠將建議的服裝搭配發簡訊給其他人，以便徵求反饋（使用3G技術，例如，請幫我評價一下這套服裝=1,2,3,4,5） 32. 系統應能夠剔除虛假資料（例如，使用者提供的比例失衡的生物特徵，用於建立不切實際的資料）
上面的圖表還展示了衣架的概念，其中衣架用於對每件物品進行評分。一件物品的綠色衣架越多，就越適合該使用者；一件物品的紅色衣架越多，就越不適合該使用者。衣架也可以是半綠半紅，因為衣架評分來自適合度指數，因此一件物品的評分可以是5分中的3.5分。我們考慮過使用顏色滑塊條來對物品進行排名，但最終決定使用星級評分（使用衣架，因為它獨一無二）。
