1.写需求文档应该和写代码一样,既要写明正常处理流程也务必写明异常处理流程。
1)写过程序的童鞋应该很熟悉这个代码片段:
try{
代码块1
}catch(Exception e){
代码块2
}finally{
代码块3
}
catch是抓取代码块1中的异常
代码块2是出异常后的处理
代码块3是不管出不出异常都会执行,如果代1或代2中有return,代3会在return后执行。
2)写需求文档时也应该如此描述,才能软件设计对最终用户更友好。
举个例子:
A、原需求描述:
“用户输入集装箱号后直接按回车键,
系统调用接口,用箱号作为接口参数,
如果该集装箱为在场箱则接口返回该箱的详细信息,系统自动这些信息填充到后面相应的字段文本输入框内。”
分析:该描述只涉及到集装箱在场的场景处理流程,而遗漏了箱不在场的处理流程。所以开发人员按需求描述开发时就有可能遗漏异常处理。
B、修正后的描述:
“用户输入集装箱号后直接按回车键,
系统调用接口,用箱号作为接口参数,
如果该集装箱为在场箱则接口返回该箱的详细信息,系统自动这些信息填充到后面相应的字段文本输入框内。
如果该集装箱非在场箱,接口返回空值,系统提示“该箱非在场箱,无法自动填充信息!””
修改后的描述稍微更完善些,开发和测试时不容易遗漏功能点,用户体验稍佳。