有一些组织内的软件项目,软件的用户需求——任务书是由系统方下达的。由于软件任务是由系统方自顶向下分解的,所以系统方下达 的任务书理论上就当能够定义清楚软件应完成的任务,即软件需求范围。
正是由于90%以上的软件开发人员有了这样的认知,他对下属的任务书就不会关注其需求范围定义的是否合理,而只去关注需求描述的一致性、准确性、有无二义性等等。
软件开发人员给任务书提出的问题都是这样式的:
不符合任务书模板要求。如,没有给出流程图;某项功能的描述没有给出异常处理等。
需求描述不准确。如,没有给出输入/输出数据的值域范围; 没有给出数据处理方式等。
需求描述不一致。如,功能描述的执行流程与流程图中表述不一致。
需求描述错误。如,对应管脚应为继电器IO口。
但是对于需求范围定义是否合适,是否真正满足系统的需求,软件开发人员都没有去关注。
而需求开发工作的第一要务就是:定义项目的业务需求,也就是明确项目的目标和范围(摘自《软件需求最佳实践》)。软件对于用户来说,是完成某项任务的工具,软件是否满足用户需求,取决于软件在用户完成该任务的过程中提供多少助力。
所以要定义清楚软件的用户需求范围,就应先了解用户要完成的任务,以及完成任务过程中用户遇到的难点和痛点。
虽然任务书是由系统方编写下发的,但并不能保证任务书中中定义的业务需求就是充分的、完整的。如果软件开发人员在与系统方沟通任务书的过程中,也能站在系统方的角度考虑软件应完成的任务,那么,会减少任务书中遗漏的需求项的数量,根据错误发散性原理——早期的问题或错误,会导致后续开发工作中出现十个甚至百个问题或错误,会使得后面开发工作中避免大师的需求变更和Bug的出现。
软件开发,不应仅仅满足于完成用户在任务书中明确表达的需求,还应进一步挖掘出用户没有表达出来的,但对于用户完成自己的工作大有裨益的真正的需求。这样,才是真正完成了用户需求开发的任务。
微信号:IdeaofSE
联系客服