写下这个标题，脑子里马上浮现出项目中的恩怨情仇，相爱相杀的场面。
要件是个日本词汇，在国内被翻译成需求，其实这种翻译过于笼统，概念没有细分，需求的日文词汇是需求或者是要望，要望（需求）类似于RFI，之后是RFP（提案），然后是RFQ（报价）。
在合同签约之后，才进入到要件定义阶段。
要件定义和基本设计之间常常有一些灰色重合地带，以至于经常责任不清，互相推诿。
要件定义阶段最常见的产出是要件定义书，其中包含了机能要件定义和非机能要件定义（系统性能要求）
Usecase是最具有争议的东西，有的说UC应该在要件定义阶段，有的放在基本设计阶段。个人观点是看要件定义阶段的预算和工期长短，UC的粒度比较细，但如果是Agile开发，一个UC可以被划分成一个user story，因此放在要件定义阶段也无不可。UC配合UI页面迁移也常能给出比较清晰的结构。
很多公司还是在用结构设计法，原因是面向对象设计虽然对于开发（Class的设计）有着很好的契合，但是由于Model的建立是从系统出发，对于用户需求遗漏常有发生。
因此有些公司是采用结构分析法和面向对象设计并用的方式。
但两者并用工作量比较大，因此哪些省略哪些必须也需要不断摸索。
对于复杂的工程系统和较为简单的系统，设计完全是不同的。
尤其是像Web系统，手机APP的开发，IOS在设计的时候已经略过了沉重的设计，直接用APP的设计替代。
而Web的架构，不外乎是MVC，和它的几种衍生模式，因此架构也被省略了。
面向对象设计、UML等自成体系，形成设计美学，而渐渐过重也形成项目中设计与开发之间的争斗，过于强调设计，对于代码的发挥是一种限制，因此代码变成了搬砖的机械劳动。
不过在大型系统中这个似乎难以避免。
相比之下，开源的Web系统，手机APP等比较小型的APP则灵活，但其之所以灵活又脱不了其小的特点。
架构似乎成了程序员的攀登高地，但问题是架构一般只对大型企业级别系统有需要，中小型系统一般是沿用既有的架构模型，因此架构师多由技术leader来担当，做一些新技术导入前的POC等，但实际上架构师的要求是Biz和技术的平衡，甚至技术对于战略（简短地说Cost和ROI）的支持和调整。
因此或许一些既有的package和开发的并用，也是一些小型公司的选择。
网友评论