因此，面向对象软件需求分析的结果能够更好地刻画现实世界，处理复杂问题。对象比过程更稳定，易于维护和重用。
软件需求分析的需求类型有哪些呢？1.businessrequirement反映了组织或客户对系统和产品的高层目标需求，这在项目视图和范围文档中有所解释。
软件需求分析一个。确定系统的综合要求
1.功能需求
该要求规定了系统必须提供的服务。通过需求分析，对系统必须完成的所有功能进行划分。
2.性能要求
性能要求规定了系统必须满足的时序约束或容量约束，通常包括速度(响应时间)、信息速率、主存容量、磁盘容量、安全性等要求。
3.可靠性和可用性要求
可靠性要求定量地规定了系统的可靠性。
可用性与可靠性密切相关，可靠性量化了用户可以使用系统的程度。
4.错误处理要求
这种需求解释了系统应该如何响应环境错误。例如，如果它从另一个系统接收到违反协议格式的消息，该怎么办？注意，以上错误不是应用系统本身造成的。
5.接口要求
该接口描述了应用系统与其环境之间的通信格式。常见的界面需求有:用户界面需求；硬件接口要求；软件接口要求；通信接口要求。
6.限制
设计约束或实现约束描述了在设计或实现应用系统时应该遵守的约束。在需求分析阶段提出这样的需求，并不是要取代设计(或实现)过程，只是为了说明用户或环境对项目的约束。常见的约束有:精度；和工具语言约束；设计限制；应该使用的标准；应该使用的硬件平台。
7.反向需求
逆向需求解释了软件系统不应该做什么。从理论上讲，反向需求是无限的，我们应该只选择那些能够明确真实需求，消除可能误解的需求。
8.未来可能的要求
它应该清楚地列出不属于当前系统开发类别，但根据分析很可能在未来提出的需求。
注:举例让学生理解:这样做的目的是在设计过程中为系统未来可能的扩展和修改做好准备，以便一旦真正需要时可以轻松进行。
两个。分析系统的数据需求
任何软件系统本质上都是一个信息处理系统。系统必须处理的信息和系统应该产生的信息在很大程度上决定了系统的外观，对软件设计有着深远的影响。因此，必须对系统的数据需求进行分析，这是软件需求分析的一项重要任务。
分析系统的数据需求，通常采用建立数据模型(例如)的方法。
三个。导出系统的逻辑模型。
系统的详细逻辑模型可以从上述两个分析的结果中导出。这种逻辑模型通常用数据流图、实体关系图、状态转移图、数据字典和主要处理算法来描述。
四个。修订的系统开发计划
根据分析过程中获得的对系统更深入、更具体的了解，可以准确地估算系统的成本和进度，修正之前的开发计划。优秀的软件产品基于优秀的需求。通常情况下，开发商与客户或客户代理人如营销人员的关系反而会变成对立关系。双方管理者只想要自己的利益，搁置用户提供的需求，从而产生摩擦。在这种情况下，不会给双方带来任何好处。只有当双方都知道他们需要什么才能成功，也知道合作伙伴需要什么才能成功时，合作关系才能建立。由于项目的压力越来越大，很容易忘记所有的利益相关者都有一个共同的目标。其实每个人都想开发一个优秀的软件产品，既能实现商业价值，又能满足用户需求，让开发者满意。软件客户需求权列出了客户在项目需求工程实施中与分析师和开发人员沟通的十项法律要求。每一项权利都对应着软件开发人员和分析人员的义务。《软件客户需求义务书》还列出了客户在需求过程中应承担的十项义务。如果你愿意，你可以把它作为开发者的权利。客户有以下权利:1。请分析师根据客户的语言习惯表达他们的需求。讨论应集中在业务需求和任务上。所以，要用业务术语，你要教给分析师，但不一定要懂计算机行业术语。2.请分析师了解客户的业务和目标，通过与用户的交流，获取用户的需求。只有这样，分析师才能更好地理解你的业务任务，以及如何让产品更好地满足你的需求。这将有助于开发者设计出真正满足你需求、符合你期望的优秀软件。为了帮助开发人员和分析师，可以考虑邀请他们观察你或你的同事是什么样的。如果使用新开发的系统来替换现有系统，那么开发人员应该使用当前系统，这将有助于他们了解当前系统的工作原理、工作流程以及可以改进的地方。3.请分析师撰写软件需求的规格说明。分析师要整理从你和其他客户那里获得的所有信息，区分业务需求和规格、功能需求、质量目标、解决方案等信息。通过这些分析，我们可以得到软件需求的规格说明。这个软件需求规格说明书是开发者和客户就要开发的产品内容达成的协议。软件规范可以用你认为容易阅读和理解的方式来组织和编写。查看书面规范，确保它们准确、完整地表达了您的需求。高质量的软件需求规格说明可以帮助开发人员开发他们真正需要的产品。4.需要对要求的工作结果进行解释。分析师可能已经使用了各种图表作为书面软件需求规范的补充。因为诸如工作流图之类的图表可以清楚地描述系统行为的某些方面。因此，需求描述中的各种图表是很有价值的。虽然它们并不太难理解，但你可能并不熟悉它们。因此，可以要求分析师解释每个图表的作用或者其他需求开发结果和符号的重要性，以及如何检查图表中的错误和不一致。5.请开发者尊重你的意见。如果用户和开发人员不能互相理解，需求的讨论就会有障碍。齐心协力可以让大家“什么都听”。参与需求开发过程的客户有权要求开发人员尊重他们，为项目的成功珍惜他们的时间。同样，客户应该对开发人员为实现项目成功的共同目标所做的努力表示尊重和感谢。6.请开发人员提供需求和产品实现方面的建议，并提出想法。通常，客户所说的“需求”是一个实际可行的实现方案。分析师会尽力从这些解决方案中了解真实的业务及其需求，同时要找出现有的系统有哪些不适合当前业务，从而保证产品不会无效或低效。在彻底了解业务领域的事情后，分析师有时可以提出相当好的改进方法。有经验和创造力的分析师也可以建议增加一些用户没有发现的有价值的系统特性。7:描述产品的易用特性。你可以要求分析师在实现功能需求的同时，关注软件的易用性。因为这些易于使用的特性或质量属性可以使你更准确、更高效地完成任务。例如，客户有时要求产品“用户友好”或“健壮”或“高效”，但这对开发人员来说太主观了，没有实用价值。正确的做法是:分析师通过询问和调查了解客户希望友好、健壮和高效的具体特征。8.调整需求并允许重用现有的软件组件通常需要一定的灵活性。分析师可能会发现现有的软件组件与您描述的需求非常一致。在这种情况下，分析师应该提供一些选项来修改需求，以便开发人员可以在新系统的开发中重用一些现有的软件。如果有可重用的机会，并且可以调整自己的需求，就会降低成本，节省时间，而不是严格按照原来的需求去做。因此，如果你想在你的产品中使用一些现有的商业组件，但它们并不完全适合你所需要的特性，那么一定程度的需求灵活性是极其重要的。9:获得满足客户功能和质量要求的系统。每个人都希望这个项目成功。但这不仅需要你把系统“做什么”的所有信息清楚地告诉开发者，还需要开发者通过沟通清楚地知道其中的取舍和局限。一定要清楚地陈述你的假设和潜在的期望。否则开发者开发出来的产品不一定能让你满意。
软件需求分析的内容需求分析——对软件用户的需求进行分析，进行详细的调查，最终将用户“做什么”的需求转化为完整详细的软件逻辑模型，指出软件需求的规格说明，准确表达用户的需求。
需求分析的任务
解决“做什么”的问题，充分理解用户的需求，准确表达已接受的用户需求。1.客户的需求是什么，根据需求做出来的软件客户能接受吗？
2.开发者能满足这些要求吗？
3.钱的成本合适吗？
4.能否在合适的时间为客户开发？
5.是否对软件进行后续维护。如果是，1。考虑维护的难度。2.有什么好处吗？
