一、需求和设计的理解
对于初学者来说，编写需求和设计，将面对很多问题，其难度不言而喻。所谓的难度就是不知道需求该写些什么，包含那些内容，写到什么程度，需求做到怎么样才比较合理。对于设计阶段，设计则要如何和需求衔接，如何从需求来做出设计。而对与从事多年的IT 的人，他们对编写需求的难度又是另外一方面，他们所谓的难度是如何去挖掘需求，如何去纠正潜在的错误需求，客户说出的需求未必就是他们想要的。开发需求的难度还在于确定需求的范围，按需求的优先级别来划分需求。所以需求在前期可能只能覆盖20%-30%，如果需求比较稳定了可以达到设计的要求了，就可以进入设计了。当然需求的开发并没有停止。需求开发只有到项目完成了，需求才算告一段落。
设计，当拿到需求的时候，或许你又束手无策了。前提在你熟悉了需求后，你自然会在脑里想出自己如何去实现会比较好（可以和经验有关），从数据的流转，想出自己的物理架构（部署图，例如要有什么服务器，服务器如何交互等），然后是逻辑架构，也就是你应用程序要分成几个子系统或服务，这些又是如何交互的。这些都需要从宏观到微观的方法，一步一步细分下来。当然，还要时刻留意自己这样分的优势和劣势，以及有没有利于可扩展性等软件性能。最终权衡各种方案，选择最适合本需求的方案。
二、如何去分析需求，做设计
需求分析方法结构化需求分析方法，面向对象分析方法。当然结构化的需求分析方法是靠流程图和数据流图，而面向对象则主要用UseCase来叙述、分析需求。当然这两种只是表现形式不一样而已，实质上都是要寻找如何解决对需求进行分解，挖掘系统需求，使其可以进行概要设计。
这里以UseCase为例来讲解，UseCase也是从宏观到微观的方法来分析UseCase，每个UC(以下简称UC)就是一个主场景和异常情况。主场景是一个与系统交互的过程，异常情况则是在交互过程中发生一些可预料或不可预料的情况处理。每个UC有其进入的前提，和结束的状态等。通过UC，你就可以知道系统到底必须提供什么功能了。当然UC要描述要描述出执行者和项目相关人员的目的和利益。
这些是需求要做的，并且也要记录下来，作为后续工作的根据。具体如何去做可参考相关书籍。
当需求分析到可操作的地步（各人依靠自己的经验，可操作的地方也不尽相同）。那么就可以用例实现，用例实现依靠协作图，活动图来完成。抽象出里面的尽可能多的对象（主要是其中的名词），当然可以用CRC卡，写出这个对象的职责，在完成CRC卡的同时，你会对这些名词进行刷选。剩下的对象，在概要级上对其进行分析其相互之间的关系（1：1，1：n，m：n，组合，聚合，继承等）。概要级别的静态结构图，可以说是本系统要实现的领域模型。
完成了概要设计已经完成了设计的一大半路程了，概要设计的好坏将直接影响系统的扩展性和健壮性等非功能需求。所以要时刻对概要设计进行检验，按V模型来说，从需求开始，你就必须时刻检验自己的工作是否是正确的，有效的。这样在后续的返工，和修改量就会很少。
下一步就是要实现具体的功能了。详细设计主要是通过协作图，时序图，状态图来分析系统的功能实现。通过这些图来模拟系统的功能，才知道那些概要类，要用什么字段、方法来实现。具体的如何用UML来实现，可参考相关书籍。这些都是详细设计所要做的，和编写的内容。当然根据不同的状况，看是否对方法内进行伪代码编写。这样到编码阶段只要翻译成平台相关的语言就可以了。
三、怎么的需求和设计才叫好
要做出优秀的需求和设计，需要付出一定的代价，从时间，资源上，所以想做成什么程度的需求完全是由成本所定。这里我们不假定这些问题。那么怎么样的需求和设计才能叫优秀呢？需求唯一不变的就变化，那么有变化是必然的，只有经过不断变化考验的需求，才能做出好的设计。太稳定的需求未必是好事。那我们描述需求如果说是好需求的话，那么这些需求对执行者和项目相关人员都是有利的，那么这些需求肯定都是好需求。没有人会去实现一个对自己都不想看到，想用的东西。但需求只有更好，没有最好。所以要尽量做好这个原则。只有最大化的满足客户的需求才是好需求。那么得到好的设计呢？好的设计则是权衡的结果，这里的前提又是不考虑成本，时间等其他因素。好的设计是满足了功能需求的前提下，满足非功能需求。非功能需求做的越好，那么设计就越优秀。针对某一个系统，其设计没有最好的，只有更好。更好是在权衡各种因素下（权衡是一大理论）得到的，权衡并不是一个人来权衡，是综合各个人的看法，和系统要的目的来达到的。优秀的设计并非是设计模式满天飞，也并非是代码量少，执行效率高。有时候，很多东西都是片面的。要从全局上去考虑。只有做到这些，才能叫做好设计。