軟件的開發文檔質量一般只能通過評審來進行保證，如何有效發現文檔中的問題，是一個令許多人頭疼的問題。先看一段關于日志文件的需求描述如下：
“軟件要將所有的訪問者都要記錄下來，對每次訪問要記錄訪問開始時間、訪問結束時間、訪問者的IP地址這三個信息作為一條日志記錄。要求以天為單位每天生成一個訪問記錄日志文件�！�
在這段需求描述中，要發現問題的話，首先要想象自己是日志模塊的開發者，根據這段需求描述，是否能夠開發出日志模塊來呢？日志文件要記錄的信息內容上面都提到了：訪問開始時間、結束時間、IP地址。初一看好像可以根據這個需求描述進行開發。
如果用用元素分析法來分析一下這段需求的話，就會發現并不是想象的那樣樂觀。先找出需求中涉及的三個顯性元素：
- 訪問者
- 訪問記錄
- 日志文件
首先對訪問者和訪問記錄這兩個元素進行分析，先看訪問者有那些屬性，除了描述中提及的訪問時間和IP地址外，訪問者還有那些屬性呢？顯然訪問者的訪問內容是最重要的屬性，僅記錄訪問時間和訪問者的IP地址是否足夠呢，從日志能分析出什么有用的信息呢？從時間信息上最多只能看出那段時間訪問的人數較多，得到用戶的時間分布規律，很難對用戶的行為有深入的分析，只有知道訪問者在訪問那些內容才能得到更有價值的信息。象Web服務器軟件要記錄下訪問的URL信息以便知道訪問者訪問的內容，所以訪問記錄中遺漏了關于訪問內容的信息。
從訪問記錄這個元素來分析，訪問記錄主要屬性是記錄格式，每條記錄是以什么格式來記錄呢？沒有描述出來。有經驗的開發者就知道日志記錄格式是一個很重要的問題，因為日志記錄的分析一般是需要使用專門的分析軟件或者寫專門的分析程序來分析的。如何設計合理的記錄格式來利用已有的日志分析軟件來進行分析是首要考慮的問題。
再對日志文件這個元素進行分析，先看看日志文件有那些屬性，首先日志文件具有文件名，還有存放位置，文件格式，文件內容、文件創建時間、文件大小、文件權限等屬性。
需求描述中提到了每天要生成一個日志文件，從文件創建時間屬性來看，每天有24小時，到底從什么時候開始創建文件，從0點開始還是從幾點開始，沒有描述出來。
從文件名屬性來看，如何命名日志文件，需求中也沒有提及。從存放位置屬性來看，日志文件存放在什么地方也沒有說明。是不是所有的日志文件都存放在應用程序同一子目錄下？
從文件格式屬性來看，首先日志文件是以文本方式存儲還是以二進制格式存儲？再者，文件的內容是以何種格式記錄，每條訪問記錄間如何分隔，是以回車換行作為分隔還是以其他字符作為分隔？都沒有描述。
從文件內容屬性來分析，除了存放上述描述的內容外，是否還可以保存其他內容，如果不能保存其他內容的話，需求描述中應該加上一句“日志文件中只能存儲訪問記錄信息，不得儲存其他記錄信息”。
從文件大小屬性來分析，日志文件的大小有沒有限制？如果某天處于訪問高峰期，訪問特別多，是否需要將日志文件分拆成多個是一個需要考慮的問題。
從文件權限屬性來分析，日志文件是否機器上的所有用戶都可以訪問還是只有特定的用戶可以訪問？文件是否需要設置權限是一個需要考慮的問題。
所以通過元素分析法對上述需求描述進行分析后，你會發現需求描述中有很多的問題沒有描述清楚。也許有人會有疑問，如果將所有上面說到的問題都描述出來的話會不會工作量太大了？僅從需求分析的角度來講，需求規格描述得較細的話確實會增大很多工作量，但從整個開發過程來看，需求描述完整的話，后續階段的開發產生歧義和遺漏的可能性就很小，實際上后續階段節約的時間會大大超過需求所多花的時間。
實際上不僅檢視需求時需要使用測試用例設計方法，還應該采取測試用例設計來驅動需求分析，即在需求設計的過程中就設計測試用例，通過測試用例設計來驅動需求分析，完善需求分析的內容。
文章來源于領測軟件測試網 http://www.k11sc111.com/
