软件架构设计之横切竖割需求

转移技术贴 | 2007-06-06 17:08:00 | 阅读 1408 次 | 评论(0)
软件架构强调的是整体,而整体性的设计决策必须基于对需求的全面认识;
 
软件架构应该是稳定的,而遗漏了重要需求的架构设计面临的是返工的命运。
 
一言以蔽之,全面认识需求,是生产出高质量软件所必须的“第一项修炼”。
 
作为一个软件架构师,也不应对所有需求“胡子眉毛一把抓”,而是应全面认识需求——分门别类地将需求梳理清楚。
 
下图所展示的“需求空间分割图”揭示了全面认识需求的要求。要全面认识需求,意味着我们必须从不同级别来考察需求:组织级、用户级、开发级,还要对每个级别考虑不同类型的需求:功能需求、质量属性、约束。

 

 

一方面,需求是分层次的。一个成功的软件系统,对客户高层而言能够帮助他们达到业务目标,这些目标就是客户高层眼中的需求;对实际使用系统的最终用户而言,系统提供的能力能够辅助他们完成日常工作,这些能力就是最终用户眼中的需求;对开发者而言,有着更多用户没有觉察到的“需求”要实现……
 
关注需求层次的实践意义在于,在需求之间建立起“可跟踪性”,避免因遗漏需求而造成软件“达不到要求”,也避免开发人员一厢情愿地为用户“制造”没有实际意义的无用功能。理解了需求分层的道理,软件人员在听到客户方的老板说“需求就是我希望这套软件能帮我赚更多的钱”时,就不会觉得好笑了,因为他知道这可能就是创建这套软件系统的商业目标,并会对其他需求和设计产生影响。
 
另一方面,需求应该被分为不同的类型。例如,一个网上书店系统的功能需求可能包括“浏览书目”、“下订单”、“跟踪订单状态”、“为书籍打分”等,质量属性需求包括“互操作性”和“安全性”等,而“必须运行于Linux平台之上”属于约束性需求之列。实践一再表明,忽视质量属性和约束性需求,常常导致架构设计最终失败。
 
总之,通过需求分类,将有助于全面认识需求、分门别类地把握需求、设计出高质量的软件架构。
 
全面认识需求还有一层含义,那就是应当在深思熟虑之后做出合适的需求权衡和取舍。一方面,众多质量属性需求之间往往会有冲突,我们必须权衡。另一方面,如果通过复杂设计所支持的变化根本不会发生,那么这种过度设计(Overengineering)就造成了资源的浪费并增加了开发难度。有人主张不要预测未来,本书并不同意,本书认为应当有依据地支持未来变化,对变化的判断应该来自对需求及需求背景的深刻把握。
文章评论,共0条
游客请输入验证码
浏览64957次