软件需求工程实验4--需求获取安排计划书

目录

一、引言

1.1 编写目的

1.2 项目介绍

2 需求获取概述

2.1 需求获取的目的

2.2 需求获取的子活动

2.3 需求获取的活动过程

2.4 需求获取的内容

2.5 需求获取的来源

2.6 需求获取的方法

2.7 需求获取的过程

2.8 需求获取的结果

3 需求获取阶段具体安排

3.1 硬数据采样

3.2 涉众分析

3.3 获取内容

3.4 获取环境

3.5 选择获取方法、执行获取

3.6 记录结果

参考资料

一、引言 

1.1 编写目的

项目现在处于需求展开阶段，已完成需求启动阶段，已经完成的文档包括《项目前景和范围》和《问题分析过程》、《面谈报告》文档。

需求展开阶段的主要目标是根据已完成的文档，从业务需求和高层次的解决方案出发，获取完整的用户需求。

本需求获取安排计划书旨在明确“智慧校园线上集市系统的设计与实现”项目的需求获取阶段的具体计划、方法和流程，确保全面、准确地收集到所有相关涉众的需求，为后续的系统设计、开发、测试及部署工作奠定坚实基础。

1.2 项目介绍

项目名称为“智慧校园线上集市系统的设计与实现”，面向位于河南郑州城郊地区的一所大学，旨在解决该大学在师生生活管理方面缺乏统一信息化管理平台的问题。该系统将涵盖商品浏览、搜索、购物车、下单购买、支付、订单状态查看、商品评价等功能，同时满足系统管理员、用户管理员、运营管理员等不同角色的管理需求。

2 需求获取概述

2.1 需求获取的目的

通过需求获取，全面了解并确认系统应满足的功能性、非功能性需求，以及涉众的期望和约束条件，确保系统设计与实现能够符合实际应用场景，提高系统的可用性和满意度。

2.2 需求获取的子活动

1. 涉众识别与分析
2. 需求调研与访谈
3. 需求文档编写与审核
4. 需求确认与验证

2.3 需求获取的活动过程

2.4 需求获取的内容

(1)需求获取内容概要

需求获取的主要目的在于获取用户需求，了解用户在完成任务时遇到的问题与期望。获取用户需求的前提是能够正确地理解用户的问题，所以针对每个获取的需求都要同时获取相关的问题域特性，在问题域特性充足的情况下，需求才能够正确地体现用户的意图。包括用户角色、功能需求、性能需求、安全需求、界面需求等。

(2)需求获取内容要求

1. 在项目的范围之内
2. 所有为用户创建解决系统必须的信息
3. 需求：通常体现为用户的观点、看法、目标或者问题
4. 问题域特性：需要注意的是不要忽略系统的环境和约束
5. 获取的内容不是一次得到的，而是逐步积累的
6. 具体、明确、可度量、可实现、相关性强、优先级清晰

2.5 需求获取的来源

来源类型	具体内容
涉众	用户	客户	领域专家	市场人员、销售人员等其他用户替代源
相关产品	原有系统	竞争产品	协作产品(和解系统存在接口的其他软件系统)
硬数据	登记表格、单据、报表等定量文档	备忘录、日志等定性文档
重要文档	原有系统的规格说明	竞争产品的规格说明	协作产品的规格说明	客户的需求文档(委托开发的规格说明、招标书)
相关技术标准和法规	相关法律、法规及规章制度	行业规范、行业标准

根据本项目特性，本项目的需求获取来源包括:

来源类型	具体内容
涉众用户	老师
	学生
涉众客户	现有商家、潜在商家
相关产品	校园物流服务、金融服务等网上类似校园集市系统
硬数据	用户行为数据、销售数据
重要文档	校园政策与规定、用户需求规格说明书、技术规格与标准

2.6 需求获取的方法

1. 需求获取方法

1. 传统方法

1. 问卷调查
2. 面谈
3. 硬数据分析
4. 文档检查
5. 需求剥离

1. 集体获取方法

1. 头脑风暴
2. 专题研讨会
3. JAD

1. 原型
2. 认知方法

1. 任务分析
2. 协议分析

1. 基于上下文的方法

1. 观察
2. 民族志
3. 话语分析

需求获取方法维度

本项目具体采取的获取方法在下面需求获取具体安排中会有陈述。

2.7 需求获取的过程

需求获取的注意事项

1. 在整体上指定组织方案

1. 确定系统的边界，建立上下文图或系统用例图

1. 维护项目的前景和范围
2. 引导和控制获取过程
3. 接受需求的不稳定性
4. 控制探索性工作

防止需求遗漏

1. 务必让所有的涉众都表达自己的意见
2. 不要以抽象和模糊的需求作为结束。对抽象和模糊的需求，要进行细化，让真正的需求暴露出来
3. 使用多种方法表达需求信息、利用不同的分析技术为相同的需求进行建模，通过分析不同的关注点，考察需求是否完整
4. 注意检查边界值和布尔逻辑

结束获取活动的判断条件

1. 用户想不出更多的用例
2. 用户只是在重复已经讨论过的问题
3. 新提出的特性、需求等都在项目范围之外
4. 新提出的需求优先级都很低

2.8 需求获取的结果

1. 用户角色与权限

1. 老师：期望有专属优惠、便捷的退货退款流程、支持校园卡支付。
2. 学生：偏好分期付款、学生专享优惠、积分兑换系统，希望平台包含学习资料和生活用品。
3. 商家：需要简单的上架流程、库存管理、订单处理、快速支付结算，以及数据分析工具。
4. 系统管理员：要求系统维护、更新升级、数据备份与恢复功能，以及用户权限管理。

2. 功能需求

1. 商品浏览与搜索：支持关键词、分类、价格区间搜索，商品详情页展示丰富信息。
2. 购物车与下单：购物车功能完善，下单时显示总价、优惠、运费，支持选择收货地址、配送方式、支付方式。
3. 支付与退款：集成多种支付方式，提供支付通知，设立明确的退款流程。
4. 订单管理：用户可以查看订单状态，追踪物流信息，评价商品。
5. 安全与隐私：实施数据加密，保护用户信息与交易安全，设立隐私政策。

3. 非功能需求

1. 可用性：系统易于使用，提供帮助文档与教程，及时响应用户问题。
2. 可扩展性：系统设计考虑未来功能扩展与性能提升。
3. 可维护性：提供系统日志与监控工具，便于故障排查与性能调优。
4. 兼容性：系统兼容主流浏览器与操作系统，适配移动端浏览体验。
5. 法规与标准：遵守相关法律法规，参照行业标准与最佳实践。

4. 数据分析与报告

收集用户行为数据，如浏览、搜索、购买记录，进行数据分析，生成销售报表、用户画像，以优化商品推荐、促销活动等策略。

5. 技术与架构

1. 根据专家咨询，建议采用微服务架构，以提高系统的可扩展性和可维护性。
2. 数据存储需考虑安全性与性能，采用分布式数据库和缓存机制。
3. 前端采用响应式设计，确保在不同设备上都能提供良好的用户体验。

6. 市场与竞品分析

1. 通过市场调研，识别了主要竞品的功能特点、用户体验和价格策略。
2. 分析了竞品的优势与不足，为平台差异化竞争提供了依据。

7. 用户反馈与改进

1. 通过焦点小组讨论，收集了用户对现有校园购物平台的反馈和改进建议。
2. 这些反馈将作为后续设计和开发的重要参考。

综上所述，需求获取活动为我们提供了全面、详细的需求信息，为“智慧校园线上集市系统”的设计与实现奠定了坚实的基础。

3 需求获取阶段具体安排

维度	类型	可以选择的需求获取方法
用户角色	涉众用户	涉众访谈、问卷调查、焦点小组讨论
商家需求	涉众客户	涉众访谈、电子邮件调查、电话访问
功能需求	产品特性	用例分析、原型评审、竞品分析
非功能需求	系统性能	专家咨询、数据分析、观察法
用户体验	界面设计	用户测试、问卷调查、数据分析
技术实现	开发约束	专家咨询、文档分析、原型开发
市场与竞争	市场分析	市场调研、竞品分析、用户访谈

3.1 硬数据采样

概述：针对硬数据采样，整理样本数据，记录文档资料。

这里的硬数据包括定量硬数据和定性硬数据。本项目中需要的数据如下：

定量硬数据：反应了校园线上集市系统的信息流的数据收集表格和反应餐厅过去的主要业务和主要目标的统计报表。

定性硬数据：整个组织的组织结构图

根据采样公式：

样本大小=0.25 * (确定性因子/可接受的错误)2

期望的确定性	确定性因子
95%	1.960
90%	1.645
80%	1.281

确定采样数量。

希望样本中包含所有情况具有90%的确定性。那么样本的大小计算如下：

0.25*(1.645/0.10)2=68

采取随机抽样的方式采样

将结果记录在《文档资料》中

3.2 涉众分析

根据项目前景和范围中的业务范围及涉特征，采样涉众，记录涉众特征。

涉众识别

基本过程：从一些比较容易发现的涉众出发，通常包括客户、管理者和相关的投资者

由初始涉众集体讨论，列出一个涉众类别列表

对上一步产生的涉众类别列表进行分析，缩减为一个关键涉众类别列表 由上一步的各个关键涉众类别选择代表，集中讨论，列出新的涉众类别列表

如果涉众类别列表趋于稳定，就结束涉众识别过程 ，否则转向第 2 步

结果：得到涉众类别列表，交互网络草图

涉众描述

个人特征	工作特征	地理特征	社会特征
年龄、性别、教育背景	职业类型、工作经验、收入水平	居住地、常出没地点	婚姻状况、家庭结构、社交圈
健康状况、兴趣爱好、技术熟练度	行业领域、职位等级、工作时长	所在城市、出行方式	文化背景、价值观、社交习惯
经营经验、个人信誉、创新能力	业务范围、经营模式、员工数量	店铺位置、辐射区域	商业网络、行业地位、社区参与
管理经验、专业技能、责任心	岗位职责、工作班次、决策权限	办公地点、管辖范围	组织归属、团队角色、专业社群
学段年级、学习成绩、课外活动	学习专业、实习经历、奖学金情况	学校位置、住宿方式	同伴关系、师生关系、家庭支持

涉众基本描述标准格式：

涉众	特征

根据下面的原则对涉众进行具体描述：

n 对项目的关注点和兴趣所在，态度是反对还是赞同；n 对项目的期望，成为项目赢家的条件；

n 可能受到的项目的影响，影响的具体内容及影响程度；n 可以对项目施加的影响，力量的施加点及其强度。

涉众具体描述标准格式：

涉众	主要目标	态度	主要关注点	约束条件

涉众评估

优先级评估

涉众并不是完全平等的，有些涉众比其他涉众更为重要

优先考虑涉众的基本特征，尤其是任务特征表格如下：

用户群体	任务	群体数量	优先级

进一步基于涉众扩展特征进行涉众优先级的评估

风险评估

分析态度

化解涉众风险策略，标准如下：

共赢分析：

Stakeholder/Issue 关系图

列出系统的所有涉众类别，明确描述他们的兴趣和对系统的期望；

从涉众们的兴趣和期望中发现背后涉及的共同问题（Issue）；

建立涉众类别和问题的关联，如果某个涉众类别对一个 Issue 存在兴趣，那么该涉众 类别和这个Issue 就存在关联关系；

对每一个 Stakeholder Issue 关系，标明该关系上面所被寄予的期望；

涉众选择

代表采样

完整采样: 每种涉众类别都有自己的代表

态度积极: 愿意提供帮助

数量适中

太少 : 个人看法倾轧群体共同看法

太多: 达成一致困难

代表数量的准确数字要视项目的上下文环境来确定, 一般 5至10

比例恰当

计算机技能

业务技能

社交技能

参与策略

让代表们在合适的时间参与合适的工作，参考示例图：

用户替代源

因为业务关系而和用户频繁接触的人 ，能够代替他们发表看法

1. 市场人员
2. 服务咨询人员
3. 技术支持人员
4. 领域专家

得到的涉众选择图如下：

3.3 获取内容

概述：根据《项目前景与范围文档》获取内容。

 《项目前景与范围文档》已知。详见项目启动阶段文档。

3.4 获取环境

概述：根据系统环境，获取环境。

3.5 选择获取方法、执行获取

概述：根据获取源，获取内容，系统环境，通过业务解释，得到问题域特性，通过分析业务问题的期望得到用户需求。

用户需求

在《面谈报告》中详细描述。

问题域特性

在《问题过程分析过程文档》中已描述。

3.6 记录结果

概述：整理问题域特性，用户需求，通过记录结果得到获取笔录。

参考资料

丁二玉、骆斌《需求工程——软件建模与分析》