软件需求与分析认识

经验人 1 &＃xff1a;没有技术背景很难真正成为一个优秀的软件需求分析师&＃xff0c;最多也就是一个业务需求分析师。

经验人2 &＃xff1a;软件需求在整个软件生命周期中的定位来看&＃xff0c;其上接业务&＃xff0c;下接设计和技术。从这个概念上来讲软件需求人员必须具备业务和技术两个方面的能力。

菜鸟的软件需求分析知识体系架构

个人认识&＃xff1a;

我以为对于软件需求来说&＃xff0c;我感觉并不需要什么具体的知识体系&＃xff0c;会局限我们的想法&＃xff08;我的意思是不要让思想拘束起来&＃xff0c;解决了本质问题的就是好方法&＃xff09;&＃xff0c;私以为&＃xff1a;需求的目的是做出“符合”的软件&＃xff0c;用户想要的 和软件功能的符合。

而问题 是如何将用户的想法准确的传达给程序员&＃xff08;或者说下一层人员&＃xff09;。我们只要将用户想要的表达清楚即可&＃xff0c;当然这也需要一定的知识和技术&＃xff0c;吸取前人的经验。

总结&＃xff1a;业务理解 &＃43; 需求分析技术

基本技术知识体系&＃xff1a;

图&＃xff1a;

 

 

体系的个人理解&＃xff1a;

需求捕获/调研&＃xff1a;

是一个与所有利益相关方积极沟通&＃xff0c;收集他们的需要&＃xff0c;清楚表达他们的问题&＃xff0c;明确并协商潜在的冲突&＃xff0c;并建立一个项目的清晰界限。也可以说给用户一个机会去解释他们的问题和需求以及他们想要新系统干什么的过程。

经验

1要在他们心目中树立自己的职业威信

2我们在进行需求调研的时候&＃xff0c;什么部门的需求就应当跟什么部门谈。同时&＃xff0c;纵向又可以划分为多个层次&＃xff0c;如高层领导、中层领导与基层人员.

3召开一个项目启动会议&＃xff0c;与各种角色、各个类型的客户建立了联系

4需求调研不是一蹴而就的事情&＃xff0c;是一件持续数月甚至数年的工作

5集中式的业务研讨划分业务组&＃xff0c;可以让业务人员分别在自己最熟悉的业务范围内参与讨论&＃xff0c;可以有效提高业务讨论的质量

6需求分析不是一蹴而就的&＃xff0c;是一个反复迭代的过程。它将从第一次需求分析开始&＃xff0c;一直持续到整个项目生命周期

7。。。。

 

需求分析&＃xff1a;

1每次参加完需求调研回到公司&＃xff0c;我们就应当对需求调研的成果进行一次需求分析

2将上次需求分析的结果与客户进行确认&＃xff0c;同时对需求分析中提出的疑问交给客户予以解答

3需求分析不是一项一蹴而就就可以完成的工作&＃xff0c;它需要一个长期的过程&＃xff0c;而这个过程是一个由粗到细的过程

4对一个系统进行功能和角色方面的梳理和分析&＃xff0c;可以采用的比较主流的方法之一就是绘制用例图

5细化需求也需要一定的方法与思路。一般来说&＃xff0c;我们可以有两个方向细化需求&＃xff1a;业务流程分析与业务领域分析

6编写用例说明

7.。。。

 

需求验证&＃xff1a;

1一次简单的口头复述不足以满足需求分析的需要。因此&＃xff0c;需求确认是一系列的确认过程&＃xff0c;每次确认都可能需要与不同的人&＃xff0c;在不同层次的确认。最终应当形成到纸面&＃xff0c;形成文档性的东西&＃xff0c;双方签字确认。这个过程中可以采用的一个好的方法就是原型法&＃xff0c;最终产物应当是需求列表与需求规格说明书&＃xff0c;最后结束于一场需求评审会&＃xff0c;或者签字确认会。

2我们都要如实记录原始的需求&＃xff0c;并以此来验证我们最终的软件。这个如实记录原始需求的文档&＃xff0c;就是需求列表。

3一个需求列表的实例

4快速原型法

5需求规格说明书

6评审与签字确认会

7.。。。

 

需求规范&＃xff1a;

就是写的正规点