需求文檔評審實例

1、附加：需求文檔評審實例,軟件的開發(fā)文檔質量一般只能通過評審來進行保證，如何有效發(fā)現(xiàn)文檔中的問題，是一個令許多人頭疼的問題。先看一段關于日志文件的需求描述：“軟件要將所有的訪問者都記錄下來，對每次訪問要記錄訪問開始時間、訪問結束時間、訪問者的IP地址這三個信息作為一條日志記錄。要求以天為單位每天生成一個訪問記錄日志文件?！?在這段需求描述中，要發(fā)現(xiàn)問題的話，首先要想象自己是日志模塊的開發(fā)者，根據(jù)這段需求描述，是否能夠開發(fā)出日志模塊來呢？

2、日志文件要記錄的信息內容上面都提到了：訪問開始時間、結束時間、IP地址。初一看好像可以根據(jù)這個需求描述進行開發(fā)。,附加：需求文檔評審實例,如果用元素分析法來分析一下這段需求的話，就會發(fā)現(xiàn)并不是想象的那樣樂觀。先找出需求中涉及的三個顯性元素：◆訪問者◆訪問記錄◆日志文件,首先對訪問者和訪問記錄這兩個元素進行分析，先看訪問者有那些屬性，除了描述中提及的訪問時間和IP地址外，訪問者還有那些屬性呢？顯然訪問者的訪問內容是最重要的屬性，僅記

3、錄訪問時間和訪問者的IP地址是否足夠呢，從日志能分析出什么有用的信息呢？從時間信息上最多只能看出哪段時間訪問的人數(shù)較多，得到用戶的時間分布規(guī)律，很難對用戶的行為有深入的分析，只有知道訪問者在訪問哪些內容才能得到更有價值的信息。象Web服務器軟件要記錄下訪問的URL（統(tǒng)一資源定位符）信息以便知道訪問者訪問的內容，所以訪問記錄中遺漏了關于訪問內容的信息。,附加：需求文檔評審實例,從訪問記錄這個元素來分析，訪問記錄主要屬性是記錄格式，每條記錄

4、是以什么格式來記錄呢？沒有描述出來。有經(jīng)驗的開發(fā)者就知道日志記錄格式是一個很重要的問題，因為日志記錄的分析一般是需要使用專門的分析軟件或者寫專門的分析程序來分析的。如何設計合理的記錄格式以便利用已有的日志分析軟件來進行分析是首要考慮的問題。,再對日志文件這個元素進行分析，先看看日志文件有哪些屬性，首先日志文件具有文件名，還有存放位置，文件格式，文件內容、文件創(chuàng)建時間、文件大小、文件權限等屬性。,需求描述中提到了每天要生成一個日志文件，從

5、文件創(chuàng)建時間屬性來看，每天有24小時，到底從什么時候開始創(chuàng)建文件，從0點開始還是從幾點開始，沒有描述出來。,附加：需求文檔評審實例,從文件名屬性來看，如何命名日志文件，需求中也沒有提及。從存放位置屬性來看，日志文件存放在什么地方也沒有說明。是不是所有的日志文件都存放在應用程序同一子目錄下？,從文件格式屬性來看，首先日志文件是以文本方式存儲還是以二進制格式存儲？再者，文件的內容是以何種格式記錄，每條訪問記錄間如何分隔，是以回車換行作為分隔

6、還是以其他字符作為分隔？都沒有描述。,從文件內容屬性來分析，除了存放上述描述的內容外，是否還可以保存其他內容，如果不能保存其他內容的話，需求描述中應該加上一句“日志文件中只能存儲訪問記錄信息，不得儲存其他記錄信息”。,附加：需求文檔評審實例,從文件大小屬性來分析，日志文件的大小有沒有限制？如果某天處于訪問高峰期，訪問特別多，是否需要將日志文件分拆成多個，是一個需要考慮的問題。,從文件權限屬性來分析，日志文件是否機器上的所有用戶都可以訪問

7、還是只有特定的用戶可以訪問？文件是否需要設置權限，也是一個需要考慮的問題。,所以通過元素分析法對上述需求描述進行分析后，你會發(fā)現(xiàn)需求描述中有很多的問題沒有描述清楚。也許有人會有疑問，如果將所有上面說到的問題都描述出來的話，會不會工作量太大了？僅從需求分析的角度來講，需求規(guī)格描述得較細，確實會增大很多工作量，但從整個開發(fā)過程來看，需求描述完整，后續(xù)階段的開發(fā)產(chǎn)生歧義和遺漏的可能性就很小，實際上后續(xù)階段節(jié)約的時間會大大超過需求所多花的時間。