需求&原型改進：
給目标使用者展現原型，與目标使用者進一步溝通了解需求。
- 思考：他們的痛是什麼？場景是什麼？（用産品之前/之後，有照片或視訊顯示使用者調查的過程，使用了各種調查手段的，加分）
産品使用前：對題型安排以及分數的配置設定需要思考，而且不能和各地考題以及多年的考題出現大規模一緻，但是重要的知識點一定要涉及到
産品使用後：試卷難度整體系數需要在稽核，另外對想要考的重點盡量覆寫
a. 上周的《需求規格說明書》初稿有哪些不足？特别是：功能考慮不全或需求文檔描述缺少的地方。
目前還沒有想到
b. 将具體改進内容釋出在随筆上。
c. 建議：用一個場景，像講故事 （User Story）那樣，描述使用者怎麼使用幾個相聯系的功能，解決了使用者的問題。
春嬌老師作為一個英語老師，在平常教學後，對學生的考核工作中，感覺出卷有點麻煩，既要考慮試卷整體難度，又要考慮知識點覆寫率等等；另外，對考試後學生錯題的統計很麻煩，有了該系統可以輕松解決這些問題
志明同學作為一個愛好上進的同學，在老師考試過之後，非常想自主學習并糾正錯題，有了該系統之後可以輕松達到這些要求
任務分解WBS：
a. 請給出團隊項目的WBS；
| 教師出卷系統 | |||
| 試題庫子產品 | 自動出卷子產品 | 答題子產品 | 評分子產品 |
| 題目類型（選擇題、填空題、判斷題、綜合能力題） | 完全随機出卷 | 學生：檢視答題分數；檢視錯題答案分析 | 按照小題統計 |
| 知識點類型 | 按照比例出卷（題目類型比例、知識點類型比例） | 教師：檢視錯題統計 | 按照知識點統計 |
b. 團隊成員估計各自任務所需時間
| 子產品類型 | 具體子產品分析 | 耗費時間（h） |
| 題目類型 | 5 | |
| 10 | ||
| 1 | ||
| 按照比例出卷 | 3 | |
| 學生 | ||
| 教師 | ||
| 6 | ||
功能分析四象限：
| 外圍功能 | 殺手功能 | |
| 必要需求 | 使用者可根據所要求試題科目，題目類型，要求分數生成一套試卷 | 學生可以看到以往做的錯題 |
| 輔助需求 | 可以對試題進行列印 | 老師可以看到錯題統計 |
系統設計：
在設計階段，我們要清楚：軟體是怎麼解決這些需求的？
一個好的分層式結構，可以使得開發人員的分工更加明确。一旦定義好各層次之間的接口，負責不同邏輯設計的開發人員就可以分散關注，齊頭并進。
1.如何才能最大限度地實作這些需求，這就是架構設計要解決的問題。請給出系統的架構設計
從架構設計上我們分為前端設計和後端設計兩部分
前端設計：直接與使用者打交道，與使用者進行互動
後端設計：負責處理使用者的請求，為使用者提供其想要的資料
Alpha任務配置設定計劃
召開疊代計劃會議，為下周進入Sprint作準備。
第一部分：以需求分析為主，選擇和排序本次疊代需要實作的訂單條目
一、通過采訪使用者,了解使用者需求并進行彙總.并且上網搜尋類似的系統的實作情況，學習他們的優點。
二、決定目前的沖刺需要解決的事情。對上述進行細劃分，團隊成員認領自己的任務去完成，實作了效率的最大收益
三、程式進行測試,記錄問題以及需要優化的地方，大家提出問題，協商解決。
測試計劃
| 人員 | 測試内容 | 時間(day) |
| 蘇上鑫 | 2 | |
| 吳偉君 | ||
| 周峰 | ||
| 周迪 | ||
| 周志強 |
1.項目背景
老師對于出卷感覺有點麻煩，需要認真的分析試卷結構和知識點，考試過後還需要分析學生答題情況，有一套本系統豈不是美滋滋~
2.任務概述
按照上面我們表格中所寫的完成各項任務之
3.測試政策
3.1測試人員需求、分工
測試人員需求、分工
測試方面各個成員配置設定安排協同合作，共同測試。
具體測試時間還是看功能實作的進度。
3.2測試方法
手動測試；