需求分析所需掌握的知识

1、需求分析的最后阶段步骤最后阶段：需求管理步骤：需求变更管理、基线管理、需求跟踪2、软件需求的任务（解决问题）和层次任务：系统必须做什么层次：概要目标层次（业务需求）、用户目标层次（用户需求）、功能层次（功能需求、非功能需求3、需求工程的活动分类需求开发、需求管理4、需求管理需求变更管理、基线管理、需求跟踪5、用例图的作用获取需求、指导测试、在其它环节中起指导作用6、用例是什么用例是参与者与系统的一次交互。7、用例之间的关系包含关系扩展关系泛化关系二、选择（10个）1、软件需求的概念（挑不对的）（1）用户解决问题或达到目标所需的条件或能力。（2）系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力。（3）一种反映上面（1）或（2）所描述的条件或能力的文档说明。2、功能性需求和非功能性需求都包括什么？非功能性需求：定义产品必须遵从的标准、规范和合约；外部界面的具体细节；性能要求;设计或实现的约束条件及质量属性。（过程需求产品需求外部需求）功能性需求：定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。3、需求变更：需求变更原因--客户方：对信息系统的了解不够对业务需求表达不清对自身业务抽象程度不够对需求重视程度不够与开发人员配合不够业务范围不断拓展业务流程不断变更管理模式不断创新需求变更原因一软件人员：沟通技巧不高需求工程技术不精需求人员知识储备不够不了解客户方的业务流程调研范围不确定需求不够细致、明确项目管理不规范需求描述存在歧义合同对客户方约束不够5、需求开发的范围？需求获取需求分析编写规范需求验证6、功能分析工具：用例图界面定义原型开发7、参与者的辨别？在系统之外，透过系统边界与系统进行有意义交互的任何事物都是参与者.对于一般规模的软件系统，参与者不会太多，一般有这样几种类型的参与者:与系统交互的用户与系统交互的外部系统与系统交互的外部硬件特别注意：有时候时间触发器也可以看成是参与者三、1、需求工程活动（需求开发需求管理）用图形描述2、编写用例图时要注意哪些因素？业务语言而非技术语言用户观点而非系统观点用例命名：动词+名词，尽量少用弱动词弱名词把步骤当用例避免使用CRUD一个用例背后可能隐藏很多数据操作3、需求确认从哪几个方面进行一致性完整性可行性有效性一致性：所有需求需求必须是一致的，任何一条需求不能和其它需求相互矛盾。完整性：需求必须是完整的，规格说明书应该包括用户需要的每一个功能和性能。首先要保证系统的每一个目标都实现了。可行性：需求中要求的硬件和软件技术必须是可实现的。有效性：必须证明需求是正确有效的，确实能解决用户面对的问题4、需求确认的主要方法审查需求文档根据需求编写测试用例编写用户手册确定合格的标准对一些需求模型采用形式化描述和验证

5、用例之间包含关系和扩展关系的区别？包含关系」.当在两个或多个独立用例重复自己并希望避免重复时在基本用例上插入附加行为并具有明确的描述包含用例作为基本用例自身行为的一部分包含关系是无条件的扩展关系：1.当表述关于正常行为的一个变化情况时在基本用例上插入基本用例不能说明的扩展部分扩展用例作为基本用例的增量扩展扩展用例不是共用的用例把可选行为从必须行为中分离出来有条件地扩展巳有用例的行为基本用例可•独立扩展用例单独存在适合于功能需求的增加、设计原则）扩展用例是按条件要求执行的包含用例是共用的用例一个基本用例可以有多个包含用例。扩展用例不是共用的用例把可选行为从必须行为中分离出来有条件地扩展巳有用例的行为基本用例可•独立扩展用例单独存在适合于功能需求的增加、设计原则）一个包含用例可以包含在若干基本用例中。很难在包含关系上对系统进行维护修改。6：用户界面定义应考虑的因素：（用户界面定义因素：界面元素、用户角色、需求变化、界面原型设计原则:简易性用户的语言记忆负担最小化一致性利用用户的熟悉程度从用户的观点考虑排列分组安全性人性化7、对用