您的位置:首页 > 其它

软件设计之旅(3)软件需求规格说明

2016-04-06 22:42 330 查看
中间过了一个清明节,上班后整理了两天流程说明的报告,都快疯了,公司要用流程来管理项目,流程整理的特别细,当然里面的好多东西有些是乱编的,如果真按照流程走的话这个项目什么都不需要做了,一项都要好久。个人感觉公司的主线有些偏离,哪里是流程在指导或推进项目啊,还不是各方面的人在弄,现在反而在流程上消耗了大量的时间,现在每一块都没有人员保障,尤其是上层的技术牛人在,整太好的流程也只是看看。毕竟下面的人要成长到照流程做事,还要好久的路要走,成长起来,估计也该离职了



不扯了,转入正题,几天没有推进报告了,已经超期限了,节点是今天

,感觉自己能力有限,只能慢慢来了,今天查了一些资料,模块都是教科书式的讲解,硬套到当前项目中也不太适用。晚上,在梳理一个模块并写添加项该如何处理时,首先,梳理了一下之前现有代码模块的处理流程,分了两个子函数,第一个子函数中包含原始量获取,计算,第二个子函数中是状态的转换,这个在需求规格说明中底层模块中介绍了三个处理流程。感觉单位这样写,在规格说明的文档里面模块太深入底层,当然这个不牵涉到实现,只包含功能流程。

在写三个处理流程时,自己把现有代码的功能翻译了一遍,当然这对报告去符合软件来说很简单,感觉如果需求规格说明如果要详细一点,就应该详细的了解功能流程,规格说明里功能的描述就是实际功能的描述,但是如何提炼一个未知功能的实现流程,并把准确的划分成实现模块,这个应该怎么做?还需要摸索。

因为要添加修改的模块,所以重新梳理了原始量的获取,包括硬件接口的部分的修改,因为之前用5个bit获取32个通道,现在通道个数增加,通道bit数也应该增加,在写这一块时感觉模块的整个流程应该从硬件交互或其他接口交互入口开始,到最终硬件状态更改结束,中间为软件的状态更改流程,当然软件会维持相应的转换规则。

在这里没有说接口的问题,因为还没有整理到这一块,所以今天就先写这么多,祝好!!
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: