1.4软件工程

IEEE对软件工程的定义是:将系统的,规范的,可度量的工程化方法应用于软件开发,运行和维护的全过程及上述方法的研究.
软件工程由方法,工具和过程三个部分组成.软件工程方法是完成软件工程项目的技术手段,它支持整个软件生命周期;软件工程使用的工具是人们在开发软件的活动中智力和体力的扩展与延伸,它自动或半自动的支持软件的开发和管理,支持各种软件文档的生成;软件工程中的过程贯穿于软件开发的各个环节,管理人员在软件工程过程中,要对软件开发的质量,进度,成本进行评估,管理和控制,包括人员组织,计划跟踪与控制,成本估算,质量保证和配置管理等.

1.4.1 需求分析

软件需求是指用户对新系统在功能,行为,性能,设计约束等方面的期望.

1. 需求的层次
   软件需求就是系统必须完成的事以及必须具备的品质.需求是多层次的包括业务需求,用户需求和系统需求.这三个不同层次从目标到具体,从整体到局部,从概念到细节.
   1.)业务需求 业务需求是指反映企业或客户对系统高层次的目标要求,通常来自项目投资人,购买产品的客户,客户单位的管理人员,市场营销部门或产品策划部门等.通过业务需求可以确定简单的文档,为开发奠定基础.
   2)用户需求 用户需求描述的是用户的具体目标.通常才去用户访谈和问卷调查等方式,对用户使用的场景进行整理,从而建立用户需求.
   3)系统需求 是从系统的角度来说明软件的需求,包括功能需求,非功能需求和设计约束等.功能需求规定了开发人员必须在系统中实现的软件功能,用户利用这些功能来满足业务需要.功能需求通常是通过系统特性的描述表现出来的,所谓特性,是指一组逻辑上相关的功能需求,表示系统为用户提供某项功能,使用户的业务目标得以满足;非功能需求是指系统必须具备的属性或品质,又可细分为软件质量属性(例如,易用性,可维护性,效率等)和其他非功能需求,设计约束也成为限制条件或补充规约,通常是对系统的一些约束说明,例如,必须采用国有自主知识产权的数据库系统,必须运行在UNIX操作系统之下等.

2. 质量功能部署
   是一种将用户要求转化成软件需求的技术,其目的是最大限度的提升软件工程过程中用户的满意度.为了打到这个目标,QFD将软件需求分为三类,分别是常规需求,期望需求和意外需求.
   1).常规需求: 用户认为系统应该做到的功能或性能,实现越多用户会越满意
   2).期望需求: 用户想当然认为系统应具备的功能或性能,但是,并不能正确描述自己想要得到的这些功能或性能需求.如果没实现,会让用户不满意.
   3).意外需求: 用户要求范围外的功能或性能,实现这些需求用户会更高兴.

3. 需求获取
   需求获取是一个确定和理解不同的项目干系人的需求和约束的过程.需求获取是否科学,准备充分,对获取出来的结果影响很大,这是因为大部分用户无法完整的描述需求,因此需求获取只有与用户有效合作才能成功.

4. 需求分析
   一个好的需求应该具有无二义性,完整性,一致性,可测试性,确定性,可跟踪性,正确性,必要性等特性,因此,需要分析人员吧杂乱无章的用户要求和期望转化为用户需求,这就是需求分析的工作.

5. 软件需求规格说明书(SRS)
   是需求开发活动的产物,贬值该文档的目的是使项目干系人与开发团队对系统的初始规定有一个共同的理解,使之成为整个开发工作的基础.SRS是软件开发过程中最重要的文档之一,对于任何规模和性质的软件项目都不应该缺少.GB/T 8567-2006中规定SRS应该包括一下内容:
   1). 范围: 包括SRS使用的系统和软件的完整标识,包括标识号,标题,缩略词与,版本号和发型好;简述SRS适合的系统和软件的用途,描述系统和软件的一般特性;概述系统开发,运行和维护的历史;标识项目的投资方,需方,用户,承建方和支持机构;标识当前和计划的运行现场;列出其他有关的文档;概述SRS的用途和内容,并描述预期使用有关的保密性和私密性要求;说明编写SRS所依据的基线.
   2).引用文件: 列出SRS中引用的所有文档的标号,标题,修订版本和日期,还应标识不能通过正常的供货渠道获得的所有文档的来源.
   3).需求: 这一部分是SRS的主体部分,详细描述软件需求,可以分为以下项目:所需的状态和方式,需求概述,需求规格,软件配置项能力需求,软件配置项外部接口需求,软件配置项内部接口需求,适应性需求,保密性和隐私性需求,软件配置想项环境需求,计算机资源需求,软件质量因素,设计和实现约束,数据,操作,故障处理,算法说明,有关人员需求,有关培训需求,有关后勤需求,包装需求和其他需求,以及需求的优先次序和关键成都.
   4).合格性规定: 对于第3)部分的每个需求,指定所使用的方法,以确保需求得到满足.
   5).需求可追踪性: 包括从SRS中每个软件配置项的需求到其设计的系统需求的双向可追踪性.
   6).尚未解决的问题: 如果有必要,可以再这一部分说明软件需求中的尚未解决的遗留问题.
   7).注解:
   8).附录:

6. 需求验证
   如果在项目进行到开发后期才发现需求错误,这样会造成大量的工作进行修补,因此,有必要对于SRS的