软件工程-需求分析文档详细范例
软件工程-需求分析文档示例
软件工程-需求分析文档示例软件工程-需求分析文档示例1. 引言2. 项目背景软件工程项目旨在开发一款用于学校图书馆的书籍管理系统。
该系统将允许学生和教师以及图书馆管理员进行图书借阅和归还操作，并提供图书检索和相关统计功能。
3. 项目目标项目的目标是提供一个简化和自动化的图书管理系统，以提高图书馆的效率并改善用户体验。
具体目标包括：允许学生和教师通过系统进行图书借阅和归还操作。
提供图书检索功能，以帮助用户快速找到所需图书。
支持图书馆管理员进行图书的入库和出库操作，并提供相关统计报表。
4. 相关方的需求4.1 学生需求学生应能够通过系统查找并借阅所需的图书。
学生应能够在借阅期满后归还图书。
学生应能够查看自己的借阅记录和借阅历史。
4.2 教师需求教师应能够借阅图书，并借阅期满后归还。
教师应能够查找并预约所需图书。
教师应能够查看自己的借阅记录和预约记录。
4.3 图书馆管理员需求管理员应能够管理图书的入库和出库操作。
管理员应能够查看图书的借阅情况和统计报表。
管理员应能够管理学生和教师的借阅和预约记录。
5. 系统功能需求5.1 用户登录和权限管理系统应提供用户登录功能，并根据用户类型分配相应的权限。
学生和教师应能够查看自己的个人信息。
管理员应能够管理用户账号和权限。
5.2 图书管理系统应提供图书的入库和出库功能。
系统应提供图书的检索功能。
系统应提供图书的借阅和归还功能。
5.3 记录和报表系统应能够记录用户的借阅和归还记录。
系统应能够借阅和归还的统计报表。
系统应能够图书的流通记录和统计报表。
6. 非功能需求6.1 安全性系统应具有一定的安全性，防止未授权访问和恶意操作。
用户密码应加密存储，以保障用户数据的安全。
6.2 可靠性系统应具有一定的可靠性，保证正常运行并减少故障发生的可能性。
6.3 用户友好性系统界面应简洁明了，易于使用。
系统应提供详尽的帮助文档，以帮助用户解决常见问题。
7.。
软件工程需求分析简洁范本
软件工程需求分析软件工程需求分析引言一、需求分析的概念需求分析是指通过收集、分析和明确软件系统的需求，以确定软件系统的功能和特性。
需求分析需要深入了解用户的需求和期望，将用户需求转化为明确、可实现的软件系统规格说明。
二、需求分析的过程需求分析过程可以分为以下几个阶段：1. 需求获取需求获取是指通过与用户和利益相关者交流，了解他们的期望和需求。
可以采用访谈、问卷调查、观察等方法获取用户需求，并将其记录下来。
2. 需求分析需求分析是对收集到的需求进行分析和整理的过程。
可以将需求分类、归纳，并识别不同需求之间的关联性。
需求分析还需要对需求进行优先级排序，确定哪些需求是最重要的。
3. 需求确认需求确认是指与用户和利益相关者共同验证和确认需求的准确性和完整性。
通过与用户进行沟通和反馈，确保需求与用户期望一致，并对需求进行修改和修正。
4. 需求规格说明需求规格说明是将需求转化为明确、可实现的软件系统规格的过程。
可以使用形式化的方法，如用例图、活动图、状态转换图等，详细描述软件系统的功能和特性。
5. 需求验证需求验证是指通过测试和评估，验证需求规格是否准确、可行和满足用户需求。
可以进行功能测试、性能测试、用户验收测试等，确保软件系统能够满足用户的需求。
三、需求分析的方法需求分析可以采用多种方法和技术，常用的方法包括：1. 原型法原型法是通过建立原型来展示软件系统的功能和特性。
通过与用户进行交互，收集用户的反馈和意见，进一步完善和调整软件系统的需求。
2. 面向对象分析法面向对象分析法是根据软件系统的对象和类的概念，对需求进行建模和分析。
通过识别系统的对象、类和关系，描述软件系统的结构和行为。
3. 需求建模方法需求建模方法是利用图形化的表达方式，如用例图、活动图、状态转换图等，对需求进行建模和描述。
通过图形化的表达，可以更清晰地展示软件系统的功能和流程。
软件工程需求分析是软件开发过程中至关重要的一步。
通过需求分析，可以明确软件系统的功能和特性，帮助开发团队理解用户需求，设计和开发出符合用户期望的软件系统。
软件工程需求分析文档(一)
软件工程需求分析文档（一）引言概述:本文档旨在对软件工程需求分析进行全面解析。
在软件开发过程中，需求分析是一个至关重要的阶段，其中包括了需求获取、需求分析、需求验证等多个环节。
通过本文档的详细阐述，读者将能够全面了解和掌握软件工程需求分析的相关内容，以便在实际项目中能够做到需求准确、明确，并且满足项目的目标和用户需求。
正文:I. 需求获取A. 用户需求的收集1. 与用户进行面对面的交流，获取用户的真实需求2. 收集用户的需求文档和经验总结3. 进行可行性分析，评估用户需求的可行性和优先级B. 系统需求的定义1. 根据用户需求，定义系统的功能和性能等需求2. 确定系统的输入输出流程3. 确定系统的非功能性需求，如安全性、可靠性等II. 需求分析A. 需求分解与分类1. 将系统的总体需求分解为较小的子需求2. 对子需求进行分类，如功能需求、性能需求、界面需求等B. 需求建模1. 使用统一建模语言(UML)等工具对需求进行建模2. 利用用例图、活动图、状态图等进行需求的形式化表示C. 需求规约1. 利用自然语言或规约语言对需求进行明确的描述2. 使用表格、图表等形式记录需求的详细信息III. 需求验证A. 需求审查1. 将需求文档交给相关人员进行审查2. 检查需求的正确性、合理性和可行性B. 需求验证测试1. 设计和执行测试用例，验证需求是否满足2. 检查系统的功能、性能和可靠性是否符合需求IV. 需求变更管理A. 需求变更的评估1. 对需求变更进行评估，包括影响范围和优先级等2. 利用变更控制工具进行需求变更的管理和跟踪B. 需求变更的实施1. 根据变更评估结果，对需求文档进行相应的修改2. 更新系统设计和测试计划等相关文档V. 需求跟踪与管理A. 需求跟踪1. 对需求文档中的每个需求进行编号和跟踪2. 记录需求的状态、变更历史等信息B. 需求管理工具的使用1. 使用需求管理工具对需求进行管理和跟踪2. 利用工具生成需求报告、状态报告等总结：通过本文档的阐述，我们详细介绍了软件工程需求分析的内容和过程。
软件工程需求分析报告模版
软件工程需求分析报告模版A.引言本章节介绍软件工程需求分析报告的目的、范围、参考文件、定义和缩略语。
1.1 目的本章节旨在提供软件工程需求分析报告的详细概述，以便为软件开发团队、项目经理和利益相关者提供清晰的指导。
1.2 范围本文档主要涵盖了软件需求分析的过程和结果，包括需求获取、需求分析和需求规格化等方面。
1.3 参考文件列出所有需要参考的文件，如需求规格文档、系统规范等。
1.4 定义本章列出文档中使用的所有专业词汇和术语的定义。
B.业务和系统概述本章节描述业务背景和系统概述。
2.1 业务背景介绍该软件项目所应用的业务领域和行业需求。
2.2 系统概述概述软件系统的功能、目标和范围。
C.需求获取本章节介绍需求获取的方法和过程。
3.1 需求获取技术介绍需求获取的各种技术和方法，如面谈、问卷调查、观察等。
3.2 需求获取过程详细描述需求获取的步骤和流程，包括需求识别、需求确认和需求记录等。
D.需求分析本章节描述对需求进行分析的过程。
4.1 需求分类将需求进行分类，如功能需求、非功能需求等。
4.2 需求分析技术介绍各种需求分析技术，如数据流图、数据字典、状态转换图等。
4.3 需求验证验证需求的准确性和完整性。
E.需求规格化本章节描述对需求进行规格化的过程。
5.1 需求规格化方法介绍需求规格化的方法和技术，如用例图、用例描述等。
5.2 需求规格化文档结构详细描述需求规格化文档的结构和内容，包括用例描述和系统接口规范等。
F.本文档涉及附件本报告附有相关文档和数据，以便读者进行进一步的了解和参考。
附件包括但不限于：________●需求规格文档●系统设计文档●测试计划和报告●用户手册G.本文所涉及的法律名词及注释本文所使用的法律名词及其注释如下：________1.法律名词1：________注释12.法律名词2：________注释23.法律名词3：________注释3。
软件工程需求分析报告模版
软件工程需求分析报告模版软件工程需求分析报告模板1. 引言在软件工程开发过程中，需求分析是至关重要的一步。
本文档旨在对需求进行详细分析，为软件开发团队提供准确的指导和方向。
2. 项目背景介绍该软件项目的背景和目标，包括项目的发起人、目的、预期效益等。
3. 业务需求描述软件所要满足的业务需求，包括功能需求和非功能需求。
将业务需求以详细的列表形式列出，每个需求都要有独立的ID，并明确需求的优先级。
4. 用户需求根据对相关用户的采访和讨论，明确用户对软件的需求，包括用户界面、系统性能、可用性等。
将用户需求以详细的列表形式列出，每个需求都要有独立的ID，并明确需求的优先级。
5. 系统需求根据业务需求和用户需求，将系统需求拆分成功能模块，并描述每个模块的详细功能和输入输出要求。
6. 非功能需求描述系统的非功能需求，如安全性、可靠性、可维护性、可扩展性等。
明确每个非功能需求的具体要求和实现方式。
7. 约束和限制描述软件开发过程中的约束和限制，例如时间、成本、技术平台等。
明确这些约束和限制对需求分析和系统设计的影响。
8. 技术需求根据系统需求和非功能需求，列出所需的技术要求和技术限制。
明确软件开发所需的技术平台、编程语言、开发工具等。
9. 可行性分析对软件项目的可行性进行评估，包括技术可行性、经济可行性和操作可行性。
对每个方面进行具体分析，给出评估结果和建议。
10. 附录附录包括本文档中提到的相关附件，如可行性分析报告、用户需求调研报告、系统设计文档等。
在附录中给出这些附件的详细说明和路径。
11. 法律名词及注释在本文中涉及的法律名词和术语，给出相应的注释和解释，以确保文档的准确性和清晰度。
请根据实际情况和项目需要对上述模板进行相应的修改和调整。
这个模板可以作为你的参考，帮助你完成软件工程需求分析报告。
软件工程需求分析文档
引言概述：正文内容：一、需求获取1. 介绍用户需求调研的重要性及流程。
用户需求调研是收集和理解用户需求的关键过程，可以通过面对面的访谈、问卷调查等方法来获取用户需求。
2. 分析用户需求的优先级。
区分用户的主要需求和次要需求，并确定其对软件系统的重要性，以便开发团队能够合理地分配资源。
3. 需求验证和确认。
在需求获取的过程中，将用户需求与实际可行性进行比较，确保需求的准确性和可行性。
二、需求分析1. 分析用户需求的功能性需求。
功能性需求是指软件系统实现的基本功能，开发团队需要仔细分析每个功能需求，并明确其具体实现方式。
2. 分析用户需求的非功能性需求。
非功能性需求包括性能要求、可用性要求、安全要求等，开发团队需要根据具体需求设定标准和指标。
3. 确定用户需求的边界和限制条件。
确定软件系统的界面范围、数据输入输出要求、运行环境等限制条件，以确保软件开发的可行性。
4. 使用案例建模分析用户需求。
使用案例建模是一种将用户需求转化为可执行操作的分析方法，开发团队可以通过绘制用例图和时序图来分析用户需求。
5. 分析用户需求的变更和迭代。
在需求分析过程中，需求的变更是正常的现象，开发团队应该及时跟进变更，并进行相应的调整。
三、需求确认1. 确认用户需求的正确性和完整性。
开发团队通过与用户进行沟通和确认，确保所分析的用户需求正确无误，且没有遗漏。
2. 确定用户需求的优先级和可行性。
在用户需求的确认过程中，开发团队和用户需求方共同讨论需求的优先级和可行性，以合理安排软件开发任务。
四、需求追踪1. 需求追踪的目的和意义。
需求追踪是跟踪需求的变更和开发情况的过程，可以帮助开发团队更好地管理需求和追踪项目进度。
2. 使用需求跟踪矩阵。
需求跟踪矩阵是一种工具，可以将不同的需求与软件开发的迭代过程进行对应，帮助开发团队更好地管理和追踪需求。
3. 管理需求的变更。
在软件开发过程中，需求的变更是正常的现象，开发团队应该及时记录和管理需求的变更，以确保软件开发的顺利进行。
软件工程系统需求分析说明书模板
需求分析阐明书团体名称:组员1学号:组员1姓名:组员2学号:组员2姓名:组员3学号:组员3姓名:组员4学号:组员4姓名:日期:1 引言1.1 编写目旳本文详细描述任务管理系统旳需求,表述旳需求信息规定明确、无二义性。
开发方与软件使用者充足沟通需求,最终形成此文档。
此文档是后续软件开发旳根据。
1.2 背景任务管理系统是一种南京工程学院与康尼电气新技术有限企业产学研合作项目,项目由康尼机电新技术有限企业提出,由南京工程学院承担开发任务。
1.3 定义和缩略语本文使用了表 1.1所显示旳面向顾客旳术语、定义,包括通用词语在本文档中旳专用解释。
表 1.2所列为本文用到旳缩略语。
1.4 参照资料(列出所查阅旳图书及网站1.5 顾客任务信息管理系统旳目前顾客为康尼企业电气事业部,电气事业部使用成功后也许会在康尼企业推广。
某餐厅餐饮管理系统旳目前旳顾客为某餐厅。
2 任务概述2.1目旳康尼企业电气事业部目前旳任务重要有2类:常规工作任务和临时性工作任务。
针对临时任务布置信息诸多时候是处在一种开放状态,缺乏任务信息旳修正、回馈、和记录分析。
而平常职责规定旳常规工作,虽然可以通过原则化旳文献固化下来并形成《常规工作计划表》作为一种制度来执行,也需要主管在百忙之中花诸多时间去检查完毕状况。
TIMS系统规定工作管理信息可以规范录入,任务信息流向可以选择,任务信息根据轻重排序,可以设定信息提醒,任务完毕状况可以评估、任务完毕状况根据选择项进行记录输出、工作量进行评估。
2.2 系统旳特点TIMS项目旳需求重要由康尼企业电气事业部提出,因此本文档是与康尼企业电气事业部交互后形成旳需求定义,系统旳功能和使用特点优先满足康尼企业电气事业部旳需求,若系统后续由于在康尼企业全面推广而引入旳新需求,则不在本文档考虑范围之内。
2.3 假定和约束本文档经双方确认后,开发方根据本文档进行下阶段工作。
若中途需求发生变更则康尼企业需及时告知开发方,若因康尼企业原因引入旳需求变更导致开发方工作量旳大幅增长,详细处理方案双方另行协商。
软件工程需求分析文档
软件工程需求分析文档需求分析文档项目名称：人事工资治理系统概述〔背景简介〕：随着我国市场经济的快速进展，人事工资治理系统在企业的日常治理中发挥着越来越重要的作用。
人事工资治理系统能够进行档案治理、奖罚治理和工资治理等，方便处理企业内部职员的相关工资信息。
另外，为了更方便地查看职职员资信息，还能够通过水晶报表对工资信息进行打印。
系统分析〔需求分析〕：通过调查，要求本系统具有以下功能。
良好的人机界面。
●方便的添加和修改数据功能。
●方便的数据查询。
●方便的数据打印功能。
●在相应的窗体中，可方便地删除数据。
●数据运算自动完成，尽量减少人工干预。
总体设计：项目规划人事工资治理系统要紧由人事治理、工资治理、用户治理和退出系统等模块组成，具体规划如下。
●人事治理模块。
该模块要紧用于实现档案治理、奖罚治理、调动治理和考评治理的功能。
●工资治理。
该模块要紧用于实现考勤津贴和工资总结的功能。
●系统治理。
该模块要紧用于实现部门治理和数据备份的功能。
●用户治理。
该模块要紧用于实现操作员治理，修改口令和更换操作员的功能。
●退出系统。
该模块要紧用于实现系统推出的功能。
系统业务流程分析：人事工资治理系统的业务流程图如下。
系统功能结构：人事工资治理系统功能结构图如下。
系统设计:设计目标本系统属于中小型的数据库治理系统，能够对中小型企业人事工资进行有效治理。
通过本系统能够实现一下目标：灵活地录入数据，使信息传递更快捷；●系统采纳人机交互方式，界面美观友好，信息查询灵活，数据储备安全可靠；●实现职员奖罚信息治理；●实现职职员资自动运算；●实现职员考评调动治理；●对用户输入的数据，进行严格的数据检验，尽可能幸免人为错误；●系统最大限度地实现了易爱护性和易操作性。
开发及运行环境●系统开发平台：Microsoft Visual Studio2005。
●系统开发语言：C#。
●数据库治理系统软件：SQL Server 2000。
●运行平台：Windows XP〔SP2〕/ Windows 2000〔SP4〕。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
需求规格说明书更改记录*修改类型分为A - ADDED M - MODIFIED D– DELETED文档编号：目的：定义软件需求，为后期的设计打下基础背景、备注：定义：参考：1概述客户是公司最宝贵的资源，为了更好的发掘老客户的价值，并开发更多新客户，XX公司决定实施客户关系管理系统。
希望通过这个系统完成对客户基本信息、联系人信息、交往信息、客户服务信息的充分共享和规范化管理；希望通过对销售机会、客户开发过程的追踪和记录，提高新客户的开发能力；希望在客户将要流失时系统及时预警，以便销售人员及时采取措施，降低损失。
并希望系统提供相关报表，以便公司高层随时了解公司客户情况。
客户服务是一个涉及多个部门，存在一定流程的工作。
客户服务水平的高低决定着公司的核心竞争力。
该客户关系管理系统应提供一个客户服务在线平台，使客户服务处理过程中相关人员可以在线完成服务的处理和记录工作。
1.1目的本文档是武汉信息技术有限公司在与XX公司的客户关系管理系统实施合同基础上编制的。
本文档的编写为下阶段的设计、开发提供依据，为项目组成员对需求的详尽理解，以及在开发开发过程中的协同工作提供强有力的保证。
同时本文档也作为项目评审验收的依据之一。
1.2范围主要是XX公司的销售主管、客户经理及其管理员用来管理语客户相关的信息与活动。
1.3背景客户关系管理系统用于管理与客户相关的信息与活动，但不包括产品信息、库存数据与销售活动。
这三类数据将由XX公司X销售系统进行管理。
1.4用户与角色系统管理员：管理系统用户、角色与权限，保证系统正常运行。
销售主管：对客户服务进行分配。
创建销售机会。
对销售机会进行指派。
对特定销售机会制定客户开发计划。
分析客户贡献、客户构成、客户服务构成和客户流失数据，定期提交客户管理报告。
客户经理：维护负责的客户信息。
接受客户服务请求，在系统中创建客户服务。
处理分派给自己的客户服务。
对处理的服务进行反馈。
创建销售机会。
对特定销售机会制定客户开发计划。
执行客户开发计划。
对负责的流失客户采取“暂缓流失”或“确定流失”的措施。
高管：审查客户贡献数据、客户构成数据、客户服务构成数据和客户流失数据。
1.5产品理念1.6文档约定1.7需求优先级说明[A1]: 优先级1，优先，必须做；[A2]: 优先级2，中等，争取做；[A3]: 优先级3，下等，可不做；备注：需求项没有特别说明优先级的，表示为[A1]。
1.8预期的读者和阅读建议使用文档结构图1.9参考文献无2需求描述2.1整体结构描述客户关系管理系统用于管理与客户相关的信息与活动，但不包括产品信息、库存数据与销售活动，也不提供产品信息查询功能、库存数据查询功能、历史订单查询功能。
这几类数据将由XX公司X销售系统进行管理。
2.2综合描述本系统采用Microsoft SQL Server数据库，使用Microsoft Visual Studio2008进行开发，采用三层架构，保证了系统的可维护性和可扩展性。
数据库设计原则上符合第三范式，且规范，易于维护。
2.2.1 功能模块2.2.1.1 概述本系统包括：营销管理、客户管理、服务管理、统计报表和系统管理五个功能模块。
2.2.1.2 销售管理营销管理模块包含销售机会的管理和对客户开发过程的管理，用例图如下：创建新的客户信息开发计划成功营销的过程是开发新客户的过程。
对老客户的销售行为不属于营销管理的范畴。
营销机会管理包括创建销售机会、修改销售机会、删除销售机会、指派销售机会几个子功能点。
前三个功能点销售主管和客户经理都可以进行操作，指派销售机会只能由销售主管操作。
2.2.1.2.1查看销售机会2.2.1.2.1.1 业务概述客户经理可以查看自己创建且尚未分配的销售机会，并按照客户名称、概要、联系人对于未分配的销售机会进行快速查询以及修改和删除。
客户经理可以查询自己所负责的销售机会，按照客户名、概要和状态进行查询和修改。
销售主管可以查看所有尚未分配的销售机会，或者按照客户名称、概要、联系人进行查询。
可以修改和删除自己创建的尚未分配的销售机会。
销售主管可以查看所有已分配的销售机会。
2.2.1.2.1.2 使用者客户经理、销售主管2.2.1.2.1.3 输入要素登录并浏览销售机会页面2.2.1.2.1.4 处理流程从数据库取出销售机会记录2.2.1.2.1.5 输出要素将从数据库中取出的销售机会记录显示在销售机会页面上2.2.1.2.2 创建销售机会2.2.1.2.2.1 业务概述需要记录的数据包括：概要、机会描述、客户名称、联系人、联系电话、成功几率以及机会来源等。
销售主管也可以在系统中创建销售机会。
2.2.1.2.2.2 使用者销售主管、客户经理2.2.1.2.2.3 输入要素在销售机会管理界面点击创建销售机会进入销售机会的系统界面输入销售机会中的信息将界面上的信息加入到数据库中2.2.1.2.2.5 输出要素提示创建成功2.2.1.2.3指派客户经理2.2.1.2.3.1 业务概述所有的销售机会由销售主管进行分配，每个销售机会分配给一个客户经理。
销售主管根据各客户经理的负责分区、行业特长等对销售机会进行指派。
每个销售机会指派给一个客户经理，专事专人。
指派成功后，销售机会状态改为“已指派”。
2.2.1.2.3.2 使用者销售主管2.2.1.2.3.3 输入要素进行指派时需要选择输入客户经理，系统自动输入指派时间。
两项皆为必填项。
2.2.1.2.3.4 处理流程选择要指派的销售机会，察看销售机会的详细信息并选择客户经理进行指派。
2.2.1.2.3.5 输出要素指派成功后提示“指派成功”，该销售机会状态改为“已指派”（即“开发中”）。
2.2.1.2.4编辑销售机会2.2.1.2.4.1 业务概述在编辑页面，可以对机会来源、客户名称、成功机率、概要、联系人、联系人电话、机会描述进行编辑。
其他信息不可编辑。
对未分配的销售机会记录可以编辑。
2.2.1.2.4.2 使用者销售主管、客户经理2.2.1.2.4.3 输入要素要编辑的项：机会来源、客户名称、成功机率、概要、联系人、联系人电话、机会描述在列表页面选择“未分配”的销售机会进行编辑，跳转到编辑页面；在编辑页面填入更新的信息，提交表单，保存新的信息到数据库。
2.2.1.2.4.5 输出要素提示“保存成功”，或报告相应错误。
页面必填项未填时不允许提交表单。
2.2.1.2.5删除销售机会2.2.1.2.5.1 业务概述状态为“未分配”的销售机会可以删除。
删除时需要判断当前登录用户为该销售机会的创建人，否则不可删除。
2.2.1.2.5.2 使用者销售主管、客户经理2.2.1.2.5.3 输入要素在“未指派”的销售机会列表中选择一项删除2.2.1.2.5.4 处理流程点选删除操作后应提示“确认删除？”，用户选“确定”则执行删除操作，否则不执行。
2.2.1.2.5.5 输出要素删除成功后提示“删除成功”。
2.2.1.2.6制定开发计划2.2.1.2.6.1 业务概述客户经理可以给自己负责的销售机会制定开发计划。
每个销售机会可以有多个开发计划，每个开发计划需要录入时间和计划内容。
填写计划项的时候可以修改计划项及删除计划项。
2.2.1.2.6.2 使用者客户经理2.2.1.2.6.3 输入要素在制定开发计划时，应显示出销售机会的详细信息。
客户经理可以通过新建计划项，编辑已经有的计划项，即删除计划项来针对一个销售机会来制定客户开发计划。
每个计划项包括两个输入要素：日期和计划内容，都是必输项。
日期的输入格式为“2007-12-13”。
编辑计划项时，日期不可以编辑。
2.2.1.2.6.4 处理流程首先选择一“已指派”的销售机会进行指定计划的操作，然后制定计划。
2.2.1.2.6.5 输出要素提交并更新当前页面时在计划项列表中显示新建的计划项。
2.2.1.2.7执行开发计划2.2.1.2.7.1 业务概述制定完客户开发计划后，客户经理针对某个销售机会执行已经制定的开发计划，记录每个开发计划的执行效果。
在所有的开发计划执行完成后，客户经理可以设置该销售机会为“开发失败”或“开发成功”。
2.2.1.2.7.2 使用者客户经理2.2.1.2.7.3 输入要素对每个计划项填写执行效果，并保存。
2.2.1.2.7.4 处理流程填写执行效果并保存2.2.1.2.7.5 输出要素提示保存成功2.2.1.2.8终止开发计划2.2.1.2.8.1 业务概述为销售机会制定的开发计划执行失败后，终止开发。
2.2.1.2.8.2 使用者客户经理2.2.1.2.8.3 输入要素从列表中选择一个状态为“已指派”的销售机会，点选“终止开发”操作。
2.2.1.2.8.4 处理流程点选终止开发按钮2.2.1.2.8.5 输出要素更改数据库的销售机会开发状态。
2.2.1.2.9开发计划成功2.2.1.2.9.1 业务概述销售机会开发成功后自动录入客户信息，创建新的用户。
某个客户开发计划执行过程中或执行结束后如果客户同意购买公司产品，已经下订单或者签订销售合同，则标志客户开发成功。
客户开发成功时，需修改销售机会的状态为“开发成功”。
并根据销售机会中相应信息自动创建客户记录。
2.2.1.2.9.2 使用者客户经理2.2.1.2.9.3 输入要素从列表中选择一个状态为“已指派”的销售机会，点选“开发成功”操作。
或者在执行计划页面点选“开发成功”操作。
2.2.1.2.9.4 处理流程修改销售机会的状态为“开发成功”。
根据销售机会中相应信息（包括客户名称、联系人和联系人电话）自动创建客户记录。
2.2.1.2.9.5 输出要素操作成功后提示“操作成功”。
2.2.1.3客户管理客户信息是公司资产的构成部分之一，应对其进行妥善保管、充分利用。
每个客户经理有责任维护自己负责的客户信息，随时更新。
在本系统中，客户信息将得到充分的共享，从而发挥最大的价值。
有调查表明，公司的大部分利润来自老客户，开发新的客户成本相对较高而且风险相对较大。
因此我们有必要对超过6个月没有购买公司产品的客户应予以特殊关注，防止现有客户流失。
客户管理的子用例图如图所示。
销售主管(from Use Case ...)2.2.1.3.1修改客户信息2.2.1.3.1.1 业务概述客户经理可以编辑状态为“正常”的客户信息。
销售主管可以修改客户信息中的“客户经理”。
客户经理，销售主管2.2.1.3.1.3 输入要素有“*”标记的为必输项。
地区、客户等级的候选项由数据字典维护；客户经理候选项为所有状态为“正常”的系统用户。
客户满意度和客户信用度候选项的值都是1~5。
2.2.1.3.1.4 处理流程从列表中选择要编辑的用户点选“编辑”按钮，编辑特定客户的信息，输入新信息后点“保存”按钮，返回列表页面。