写软件需求分析

尽管看了小组里面很多人的软件需求分析，但是我还是感觉稀里糊涂的，我也就只好照猫画虎了，写我的软件需求分析了，但是自我感觉很不好，我们也讨论了可是最后还是不了了之了，而且现在想干的人也没有几个了。我想我会完成的，不论它的好坏，而且我要去吸引更多的人参与。但是，今天突然看到一本软件需求，这不就是我要的吗？
书名是《Software Requirements》 作者是Karl E.Wiegers
看这本书，而后再一步一步开始了写自己项目的需求分析！我写完后将上传到
http://repo.or.cz/w/gocoso.git感兴趣的人看看。先看书这中的重点内容：
IEEE软件工程标准词汇表（1997年）中定义需求为：
（1）用户解决问题或达到目标所需的条件或权能（Capability）
（2）系统或系统部件要满足合同,标准，规范，或其他正式规定文档所需具有的条件或权能。
（3）一种反映上面（1）或（2）所描述的条件或权能的文档说明。
软件需求包括：业务需求，用户需求和功能需求——也包括非功能需求。
(software requirements specification,SRS)
应该避免，（1）无足够的用户参与 （2）用户的需求不断增加 （3）模棱俩可的需求 （4）不必要的特性
（5）过于精简的规格说明书 （6）忽略了用户的分类
必须解决需求中的所有的TBD项。
需求规格说明的特点：（1）完整性 （2）一致性 （3）可修改性 （4）可跟踪性
需求开发可进一步分为：问题获取（elicitation），分析（analysis），编写规格说明(specification)和验证（verification）。
需求分析(requirement analysis)包括提炼，分析和仔细审查已收集到的需求，以确保所以的风险承担者都明白其含义并找出其中的错误，遗漏或其它不足的地方。
由于自己的软件开发经验不是很足，所以我感觉有时还要根据模板来开发，以不断提高自己的水平。
（一个模板）需求过程改进的活动计划
项目：<项目名称>
目标：<成功执行这份计划后希望达到的一些目标。说明业务方面的目标，而不是过程变更方面的。>
成功度量：<描述怎样确定过程变更是否达到了预期要求。>
组织受影响的范围：<说明在本计划中所描述的过程变更带来影响的广度>
人员和风险承担者：<明确谁实施该计划，每个人的角色，及投入时间承诺。>
跟踪和报告过程：<说明怎样跟踪计划中的活动条目进展情况，以及报告其状况结果等>
依赖，风险和限制：<明确对计划成功有帮助或有阻碍的各种外部因素。>
估计所有活动的完成日期：<希望该计划什么时候完成>
活动条目：<为每个活动计划写了3－10个活动条目>

一日是你的用户终身是你的用户。

软件需求规格说明模板
1.引言 1.1目的 1.2文档约定 1.3预期的读者和阅读建议 1.4产品的范围 1.5参考文献
2.综合描述 2.1产品的前景 2.2产品的功能 2.3用户类和特征 2.4运行环境 2.5设计和实现上的限制
2.6假设和依赖
3.外部接口 3.1用户界面 3.2硬件接口 3.3软件接口 3.4通讯接口
4.系统特征 4.1说明和优先级 4.2激励/响应序列 4.3功能需求
5.其它非功能需求 5.1性能需求 5.2安全设施需求 5.3安全性需求 5.4软件质量属性 5.5业务规则
5.6用户文档
6.其他需求
附录A：词汇表 附录B：分析模型 附录C：待确定的问题的列表

根据上面的学习完成了自己软件需求分析，我上传到了http://repo.or.cz/w/gocoso.git
哪位感兴趣，可以去那里下载。