第三讲需求资料.pptVIP

* 软件需求各组成部分之间的关系 对一个复杂产品来说，软件功能需求也许只是系统需求的一个子集，另外一些可能属于软件部件。 管理人员或市场分析人员确定软件的业务需求，使公司运作更加高效（对信息系统而言）或具有很强的市场竞争力（对商业软件产品而言）。 所有的用户需求必须与业务需求一致。用户需求使需求分析者能从中总结出功能需求以满足用户对产品的要求从而完成其任务，而开发人员则根据功能需求来设计软件以实现必须的功能。 客户管理需求 业务需求:方便公司相关人员详细了解客户信息，实现准确定位，快速反应，更好地服务客户，双方能长期愉快地合作。 用户需求：添加、修改、查看、删除客户信息。 功能需求：采用分页将所有客户信息以列表形式显示出来，即管理主界面，用户可以设置一页显示的信息数，可以直接定位到某一页，或通过翻页转到其他页。 具体功能描述如下： 默认列表显示所有数据，且数据前具有复选框。 新增：添加新的用户信息，具有必填项和可选项。 修改：选择一条要修改的数据，显示客户原来的信息，修改需要的信息。 删除：勾选需要删除的客户（可以选择一条数据或多条数据），点击删除即可。 查看：通过客户代码查看一个客户的详细信息，只能查看。 查询：输入客户编号、客户名称、客户别名、客户类型等，查询指定客户，将数据显示在列表中。 * 非功能性需求 作为功能需求的补充，软件需求规格说明还应包括非功能需求，它描述了系统展现给用户的行为和执行的操作等。 它包括产品必须遵从的标准、规范和合约；外部界面的具体细节；性能要求；设计或实现的约束条件及质量属性。 所谓约束是指对开发人员在软件产品设计和构造上的限制。质量属性是通过多种角度对产品的特点进行描述，从而反映产品功能。多角度描述产品对用户和开发人员都极为重要。 客户管理的非功能性需求： 界面简洁美观，操作应方便、明显。添加、修改、删除、查看、条件查询都能通过列表页面进入。 反应速度在1s左右，删除信息应该提醒。 添加、修改信息时，必填项目应该标记，如果不填不允许保存。 固定信息以列表形式显示，防止不统一影响查询。如部门等。 客户信息是公司的重要数据，对客户信息管理需要设置权限，不同类型用户具有不同的操作权限。 除删除信息允许操作多条数据，修改、查看操作多条数据时都应该提醒，只能操作一条数据。 按条件查询时，信息显示列表应该和管理主界面功能一样，是所有操作的入口。 需求获取方法 需求获取是调查研究的结果，获取方法以采访、观察、座谈、对先前的系统版本的测试等。必要时采用快速原型法。 先集中在使用者对系统的观点上，以收集用户原始资料，数据、工作方式、工作流程、使用要求等为工作起点，深入到部门、车间、班组，做好原始纪录； 然后根据对问题及其环境的理解与软件开发经验，改正用户需求的模糊性、歧义性和不一致性，排除由于用户的片面性和短期行为所导致的不合理要求、挖掘用户尚未提出但具有价值的潜在需求，并在用户的帮助下对相互冲突的要求进行折衷，使用户需求逐步精确化、一致化和完全化； 需求获取不是一次完成，不仅仅在分析阶段，在问题定义、可行性研究阶段都需要，是往复进行、逐步深化的结果。 需求获取的内容经过整理形成“用户需求”最终要写进“需求规格说明书”， 结果由客户确认。 　 注意 某公司为了能够让客户更贴近公司产品成立了一个叫“用户实验室”的部门，这是一个常设部门，专门有一个人在进行管理，主要的工作就是不定期的邀请一些公司的用户来体验公司的最新产品，并让他们提出自己的意见和建议，以方便产品部门进行进一步的改进，目的是在上市的时候，尽量能够达到用户期望的指标。 有一次，公司另一个产品的产品经理组织了一次新产品用户体验，当时来了大概不到30个用户参与新产品的试用，大家想了，能够耽误个人时间来参加这次试用的用户肯定是公司或者产品的铁杆支持者了，因此，这些用户都显得非常认真，每一个细节都不放过，并且在试用完成后，都非常精心的完成了公司准备好的问卷，至少从一个旁观者的角度来说，这次用户试用还是非常有成效的。 过了几天，和那个产品经理闲暇聊天，问他看了那天的用户问卷，对产品有什么新的想法吗，他说“不瞒你说，你是没看那些问卷，那些人（指用户）的想法真幼稚呀，我就不信了，用户会提那样的问题出来”， “那你考虑去改进一下目前的产品吗？”，他说“改什么改，我设计的产品我还不知道，要是按照那些人的想法做，这产品成什么了，我和你说啊，那些人来就是一个过场，咱们该怎么做还是怎么做”。 客户管理业务流程 查询客户 用户在客户管理主页面，根据自己的需求，输入编号，客户名称，客户别名，客户类型对数据中的客户信息进行筛选查询。 查询结果显示在页面下方的客户列表中，点击客户代码，弹出客户信息查看页