Before the project began
Have you ever had the feeling your project is doomed to failure even before the project started? Sometimes it might be so, unless you first establish some basic criteria. Otherwise, maybe you can now proposed to close it and save some money to investors.
In the beginning of the project, you need to determine needs. Just listen to the views of users is not enough to read the "pit of demand," for more information.
Conventional wisdom and constraint management is not possible to unlock the puzzle to unlock the topic. Whether you are doing needs analysis, coding, still in testing, you will encounter various problems. Most of the time, they are in fact not initially seem so difficult.
When you think you've solved the problem, you may still think you can not start the project. This is just delaying, or do not have meaning? "When you are ready," I will tell you when to listen to the voice warned mind issue you are prudent.
Start too fast is a problem, but waited too long could be worse. In the "normative trap", we will discuss the various advantages of the specification by example.
Finally, we will examine some of the defects of various forms of development process and methodology of the circle and arrow. No matter how detailed it has been considered, or whether it includes what best practice, there is no way to replace thinking.
Before the project started to solve these critical issues, you can better avoid "analysis paralysis" and the actual start your successful projects.
Pit of needs
Mining demand
When you around digging in the dust, how can you identify the real needs? The answer is simple and complex.
The simple answer is that demand is a statement of something needs to be done, the following statements is a good demand:
- Only designated personnel to view employee records.
- The temperature of the cylinder head not exceed the critical value which varies with engine
- The editor will highlight the keywords, these keywords are determined according to the two points are editing the file type.
However, very few clear demand like this, which is the analysis of very complex reasons demand.
Users may be stated first statements listed above: "Only employees superiors and personnel department staff can view files' this statement really needs it today perhaps, but it is embedded in an absolute statement.? commercial policy, the policy will often change, so we may not want them hard to write our needs our advice is, and as an example of the policy information sent to developers - the example they need to support the transaction. Finally, the policy can be a metadata applications.
this is a relatively subtle difference, but the developer has had a profound effect. If the demand is stated as "only the personnel department to see employee records," developers could finally will write code explicitly checks at each application to access these files. However, if the statement is "only authorized users can access employee files", the developer could design and implement some access control system. when the policy when changed, only the metadata of the system needs to be updated. in fact, in such a way to collect demand Naturally let you go to support the development of metadata systems were good decomposition.
In discussing the user interface, the difference between demand, policy and implementation may become very blurred. "The system must allow you to choose the loan period "is a statement of requirements." we need a list box to select the term of the loan "may, or may not. If the user must have a list box, then it is demand. on the contrary, if they are selected in the ability to describe, but just use the list box as an example, this statement may not demand block page will discuss the need for a user interface ignored because of serious problems and production projects.
to find out the reasons why users do specific things, not just their current do this way, which is very important. in the end, you have to develop solutions to their business problems, not just to meet the needs of their stated reason behind the record needs to be with you when the document will be realized in the daily decision-making team brings invaluable information.
work with the user, as a user would think.
Establish requirements document
You'll write them down and publish everyone can be used as a basis for discussion of the document - developers, end users and project sponsors.
Fairly broad range of listeners.
The memorandum formalized as a template, you can make sure you include all the information required use cases. For example: "Oh, we have to do YYY, xxx unless we can meet the conditions."
Use Case Diagram
Can capture workflow using UML activity diagrams, and sometimes modeling for the transaction at hand, the concept of class diagrams useful layer.
Excessive regulations
Too specific when making a big danger when the requirements document. Good requirements document will remain abstract. Involved in local demand, the easiest, statements accurately reflect business needs is the best. This disease can be vague and non-means you - you have to put the same items as the underlying semantics capture, and the specific or current work practices as a policy included in the document.
Demand is not architecture. Demand is not designed, nor is the user interface, the demand is required.
Look farther
Demand will only provide for the use of date. It might indicate, that certain mathematical operations to date. It may Hui tell you, the date will be stored on various forms of secondary storage, the real needs of these statements about the date module or class.
Add a touch thin layer of mint
许多项目的失败都被归咎于项目范围的增大——也称为特性膨胀，蔓延特性论、或是需求蔓延。这是”石头汤与煮青蛙“中煮青蛙综合症的一个表征。我们要做些什么。才能防止需求悄悄地蔓延到我们身上呢？
在各种文献中，你会找到对许多度量方式的描述，比如报告与修正的bug、缺陷密度、内聚、耦合、功能点、代码行数，等等。可以通过手工或软件方式追踪这些度量。
遗憾的是，积极地追踪需求的项目似乎并不是很多，这意味着，它们无法报告范围的变化——谁请求增加新特性、谁批谁的、批准的请求总数是多少，等等。
管理需求增长的关键是向项目出资人指出每项新特性对项目进度的影响。当项目已经拖后了一年，各种责难可使纷飞时，能够准确、完整地了解需求增长是怎样及时发生的，会很有帮助。
我们很容易被吸进”只是再增加一个特性“的大漩涡，完整地了解需求增长是怎样及何时发生的，会很有帮助。
只是再增加一个特性，其实已经是本月新增的第15个新特性。
维护词汇表
一旦开始讨论需求，用户和领导专家就会使用对他们有特定含义的术语。例如，他们可能会区分”客户“和”顾客“。于是，再在系统中随意使用这两个词就是不合适的
要创建并维护项目词汇表——这是定义项目中使用的专用术语和词汇的地方。项目的所有参与者，从最终用户到支持人员，都应该使用这个词汇表，以保证一致性。这就意味着，可以访问词汇表的人员范围应该很广泛——这是基于Web文档的一个有效论据。
把话说出来
在全都是写中我们将会讨论怎样把项目文档发布到内部的网站上去，以方便所有参与者的访问。这种发布的方法对于需求文档特别有用。
通过把需求制作成超文本文档，我们可以更好地满足不同听众的需要——我们可以给每个读者他们想要的东西。项目出资人可以在更高层的抽象层面上巡视，以确保商业目标得以实现。程序员可以使用超链接”钻入“越来越深的细节中。
解开不可能解开的谜题
不时地，你会发现自己与一个遇到了非常困难的”谜题“的i昂木牵连在一起：某项工程设计你就是找不到头绪，或是你发现有些代码比你想象得要难以编写得多。也许它看起来不可能解决的。但它真的有看上去那么困难吗？
考虑现实世界的谜题——那些好像是作为圣诞礼物、或是从旧货市场突然出现的形状奇特的小木块、锻铁、或是塑料。你要做的全部事件就是拿掉铁环、或是T形块放进盒子里，等等。
于是你拉动铁环，或是试着把T形块放进盒子，并且很快发现明显的解决方法没有用。你无法像以前那样解开谜题。但即使这很明显，人们也仍然会继续尝试同样的事情——一次又一次——并且认为那样肯定能行。
当然不行。解决方法在另外的地方。解开这个谜题的秘结是确定真正的（而不是想象）约束，并在其中找出解决方法。有些约束是绝对的；有些则只是先入之见。绝对的约束必须受到尊重，不管它们开上去有多讨厌或多愚蠢。另一方面，有些外表上的约束也许根本不是真正的约束。例如，有一个酒吧里的老把戏：你拿一瓶全新的、未开启的香槟酒，打赌说你可以从中喝出啤酒来。诀窍是把酒瓶倒过来，在瓶底的凹处倒一点啤酒。许多软件问题都可能具有相同的欺骗性。
自由度
流行的俗话”在盒子外面思考“鼓励我们找出可能不适用的约束，并忽略它们。但这个俗话并不能完全准确。如果”盒子”是各种约束和条件的边界，那么诀窍就在于找到盒子——它可能比你以为的要大得多。
解开谜题的关键在于确定加给你各种约束，并确定你确实拥有的自由度，因为在其中你将到你解决方案。这也是有些谜题为何如此有效的原因；你可能会太快就排除了潜在的解决方案。
在面对棘手的问题时，列出所有在面前的可能途径。不要排除任何东西，不管它听起来有多无用或愚蠢。现在，逐一检查列表中的每一项，并解释为何不能采用某个特定的途径。你确定吗？你能否证明？
想一想特洛伊木马——一个棘手问题的新奇解法。你怎样让军队潜入城池，而又不被发现呢？你可以打赌，“走前门”一开始就作为自杀行为而被排除了。
对你的各种约束进行分类，并划定优先级。木匠开始做活路时，会首先锯出最长的木料，然后再从剩下的木头中锯出较小的木料。按照同样的方式，我们想先确定最为严格的约束，然后再在其中考虑其余的约束。
一定有更容易的方法！
有时你会发现，自己在处理的问题似乎比你以为的要难得多。感觉上好像是你走错了路——一定有比这更容易地方法！或许现在你已落在了进度表后面，甚或失去了让系统工作起来的信心，因为这个特定的问题是“不可能解决的”
- 有更容易地方法吗？
- 你是在设法解决真正的问题，还是被外围的技术问题转移了注意力？
- 这件事为什么是一个问题？
- 是什么使它如此难以解决？
- 它必须以这种方式完成吗？
- 它真的必须完成吗？
等你准备好
了不起的表演者有一个共同的特征：他们知道何时开始，何时等待。跳水运动员站在高台上，等待完美的时刻起跳/指挥站在乐队前面，举起手臂，知道它感觉到某个瞬间适用于开始演奏。
你是一个了不起的表演者。你也需要倾听内心的低语声：“等一等”。如果你坐下来，开始敲击键盘，在你的头脑里反复出现某种疑虑，要注意它。
以前有一种网球训练方法，叫做“内在的网球”。你要花上数小时击球过网，并不特意追求准确性，而是用语言描述球击中的地方与某个目标的相对位置。其思想是反馈会训练你的下意识和反应能力，于是你的球技就会得到提高，而又无需有意识地了解怎样提高或为何能提高。
作为开发者，你在整个职业生涯中都在做同样的事情。你一直在试验各种东西，看哪些可以，哪些不可以。你一直在积累经验与智慧。当你面对一件任务时，如果你反复感觉到疑虑，或是体验到某种勉强，要注意它，你可能无法准确地指出问题所在，但给它是时间，你的疑虑很可能会结晶成为某种更坚实的东西，某种你可以处理的东西。软件开发仍然不是科学。让你的直觉为你的表演做出贡献。
是良好的判断，还是拖延
每个人都害怕空白的纸页。启动新项目（或是已有项目中的新模块）可能回事让人身心交瘁的经验。我们许多人更愿意延缓做出最初的启动承诺。那么，你怎样才能知道，你什么时候是在拖延，而不是在负责地等待所有工作准备就绪？
在这样的情形下，我们采用的一种行之有效的技术是开始构建原型。选择一个你觉得会有困难的地方，开始进行某种“概念验证”。在典型情况下，可能会发生两种情况。一种情况是，开始后不久，你可能就觉得自己是在浪费时间这种厌烦可能很好地表明，你最初的勉强只是希望推迟启动。放弃原型，回到真正的开发中。
另一种情况是，随着原型取得进展，你可能会在某个时刻得到启示，突然意识到有些基本的前提错了。不仅如此，你还将清楚地看到可以怎样纠正错误。你将会愉快地放弃原型，投入正常的项目。你的直觉是对的，你为你自己和你的团队节省了可观的，本来会浪费的努力。
当你做出决定，把构建原型当作调查你的不适的一种方法时，一定要记住你为何这样做。你最不想看到的事情是，你花了几个星期认真地进行开发，然后才想起你一开始只是要写一个原型。
规范陷阱
编写程序规范就是把需求规约到程序员能够接管的程序的过程。这是一个交流活动，旨在解释并澄清系统的需求，比如消除主要的歧义，除了最初实现的开发者交谈之外，规范还是留给未来进行维护和增强的几批程序员的记录。规范也是用户的约定——是对他们的需求的汇编，也是一份隐含的合约：最终系统将会符合该合约的要求。
编写规范是一项重要职责。
问题是许多设计者发现很难停下来。他们觉得，他们不应领取每日的薪水，除非每一处小细节都极端详细地确定下来。
这是一个错误，原因如下：首先，认为规范将捕捉系统或其需求的每一处细节和细微差别，这很幼稚。在受限的问题领域中，有一些形式方法能对系统进行描述，但他们仍然要设计者向最终用户解释该表示方法的含义——人的解释仍然会搅乱事情。即使这样的解释中的固有问题并不存在，一般用户也可能无法说出他们的所需系统。他们可能会说，他们已经理解了需求，他们可能会在你制作的200页的文档上签字，但你可以确信，一旦他们看到运行的系统，你就会被各种变更要求淹没。
其次，语言自身的表达能力存在着问题。所有的图示技术和形式方法都仍然依赖于用自然语言表达要进行的操作，而自然语言实在不能胜任这项工作，看一看任何合约的措词：为了进行精确的表达，律师不得不以最不自然的方式扭曲语言。
这里有一个挑战：写一份简短的描述，告诉别人怎样系鞋带。
对于有些事情“做”胜于“描述”
最后，还有“紧身衣效应”。没有给编码者留下任何解释余地的设计剥夺了他们发挥技巧和艺术才能的权利。
作为注重实效的程序员，你应该倾向于把需求搜集、设计、以及实现视为同一个过程——交付高质量的系统——的不同方面。不要信任这样的环境：搜集需求、编写规范、然后开始编码、所有这些步骤都是孤立进行的，相反，要设计采用无缝的方法：规范和实现不过是同一个过程——设法捕捉和编纂需求——的不同方面。每一步都应该直接流入写一步，没有人为制造的界限。你将会发现，健康的开发过程鼓励把来自实现与测试的意见反馈到规范中。
圆圈与箭头
从结构化程序设计开始，经过主程序员团队、CASE工具、瀑布开发、螺旋模型、Jackson、ER图、Booch云、OMT、Objectory、以及Coad/Yourdon，直到今天的UML，计算技术从来都不缺少意图使程序更像工程的方法。每种方法都聚集了自己的追随者，并且都享受到一段时间的流行，然后一种方法又被下种方法取代。在所有这些方法中，或许只有第一种——结构化程序设计——拥有长久的生命
还有一些开发者，在有许多已沉没项目的大大海里漂流，不断抓住最新的时尚，就像是遇到海滩的人紧紧抓住漂来的木头一样 每当有新的木头飘过时，他们都会费力地游过去，虚妄这一块会更好。但到最后，不管漂浮物有多好，这些开发者仍然漫无目的地漂流着。
我们应是否使用形式方法
绝对应该。但始终要记住，形式开发方法只是工具箱的又一种工具。如果在仔细分析之后，你觉得愮使用形式方法，那就采用它——但要记住谁是主人。不要变成方法学的奴隶：
圆圈与箭头会让你变成糟糕的主人。注重实效的程序员批判地看待方法学，并从各种方法学中提取精华，融合成每个月都在变得更好的一套工作习惯。这至关重要，你应该不断努力提炼和改善你的开发过程。绝不要把方法学的呆板限制当作你的世界的边界。
