时间已经悄悄的和你擦肩而过，留着的只有记忆我们或多或少会在某些时候有些深刻的故事，总结那一段时间的经过是非常重要的。总结的精髓在于客观的查错改错。我们该如何去写一份优秀的总结范文呢？小编现在向你推荐需求分析工作总结范文，欢迎阅读，希望大家能够喜欢！
工作总结之家工作总结频道为大家整理的需求分析工作总结范文，供大家阅读参考。更多阅读请查看本站工作总结频道。
需求分析是项目开发的基础，基础打的牢不牢直接关系到后面所有的工作，是项目实施成败的关键
项目经理博客
总体上说，我们的需求分析是做了，但是做得很不够，我们做的需求只解决了我们能做出这样的项目，但是没有解决这样的项目是不是真就是客户想要的。造成这种状况的原因主要是下面几个情况：
客户本身说不清楚
文物网是这样，中彰国际更是这样，但是这不能怪客户，毕竟客户在软件方面的知识要少的多，也没有相关的经验，可能心里只有一个想要的软件的轮廓，于是可能会要求我们去替他们来完整这个轮廓的细节，而我们的能力、我们能否真正站在客户角度去搜集和整理这些需求，就决定了这个需求的完整性和有效性。
需求自身经常变动
随着客户对这个项目越来越深刻的理解，那么可能他的需求也会随之改变，这些变化的可能性越大项目风险就会越大，我们在需求分析的时候就要充分考虑到哪些需求是相对固定的需求，哪些可能会是产生变动的需求，考虑到他的可变性，这样设计功能和数据库的时候不致因为后面的变动而影响整个工程。
分析人员或客户理解有误
毕竟，不是每个分析人员都是专业而合格的，为避免这种情况的发生，需求分析必须要有审核制度，公司自己内部要审核一遍，客户再审一遍，提出意见，修改后双方共同评审签字，确认。
由此出现的问题：
a) 需求分析过于笼统，只关注到面上，没有关注到点上，开发出来的东西在具体的细节上和客户的理解有误差，并且无法严格界定是否属于需求变更。中彰的方案就是这样的。
b) 需求报告只求我们这方评审通过，不去关心客户的评审，认为只要客户签字认可就行。虽然签字认可能够给日后出现问题时划清我们的责任，但是不能保证使项目实施成功。
c) 需求分析中含有技术实施上有难度的功能，一味的求全和盲目按照客户的设想，受客户影响过大，毕竟，很多时候，客户的想法在实际实施过程中是不现实的，或者可以有更为简便的方法来替代的。如中彰国际的在线交易功能，后台大批量邮件群发功能。
d) 对双方已经确定的需求，实现以后并不适合客户使用，需要按照变更手续执行的时候，客户可能会纠缠，提出“你们是专业人士，你们应该事先能提醒我们可能会出现这种问题”并以此来把责任推给我们，而我们又不好完全按照变更手续执行，因为可能激化双方的矛盾，比如508的批量处理功能，因为属于人事管理比较专业的细节问题，需求分析师开始没有对客户业务熟悉到如此细致的地步，而客户也没有过多关注这些细节，导致软件的某些功能不合用，较为繁琐，而重新按着客户的意见修改的话工作量比较大，导致成本增加、工期延长。
e) 项目的成熟度受客户预算的限制。大部分客户在项目投入上都是有预算的，在成本有上限的前提下，项目的功能设计（软件的成熟度）方面必然受一定影响，毕竟功能越多越完善，相应的开发成本就越高。这种功能上的不完善需要事先告知客户并得到理解。
f) 此项工作的反复造成思想上的倦怠，使需求分析最后虎头蛇尾。需求分析是一项繁琐枯燥的工作，需要和客户之间不断的商讨、确认和反复，另外由于大部分的客户虽然安排专人负责这项工作，但是该人并不只做这项工作，特别当他被很多其他的事情缠身的时候，而无心细看提交过去的需求报告的时候，他很可能会给你一个错觉，让你认为他已经真正的理解并认可了你的设计。结论
a) 需求分析是整个项目管理中需要重点控制的几个关键节点之一，首先思想上一定要重视。
b) 需求分析报告的编写者要参与到需求的搜集工作中，准确领会客户的意图，并转化成软件能够实现的功能。对于说不清楚需求的客户，要善于问关键问题，引导客户提出自己的需求。可以采取的措施是事先编制一个问卷调查之类的文档，详细列举需要客户回答的问题，以便防止遗漏。
c) 需求报告的编写者要能够对客户需求进行深入分析，区别出哪些需求存在日后变更的可能，哪些需求属于相对固定的，哪些需求能够实现，哪些需求需要变通才能实现，以便于指导后面的功能设计。
d) 需求分析报告对功能细节的描述不能有歧义，描述一定要全面、准确，防止开发方和客户只见对同一个问题有两个截然不同的理解。可以通过评审，用大家的力量来避免这种情况发生
e) 需求报告的每个关乎功能的描述都要让客户明白和理解，客户在理解之上的确认才能够保证日后一旦出现问题不致出现双方互相推托责任纠缠不清的情况。
f) 需求报告一定要经过一个有技术人员和业务人员参加的评审，要充分发挥团队的力量，重视每个人的才智，一个模块一个功能的逐一的过，让大家来共同找出需求报告里不合理的、有歧义的、不完善的、遗漏的等等问题
g) 帮助客户去理解提交给他的需求分析报告而不是只等签字，对于有能够用好几种方式实现的功能，尽量做到能让客户去比较和选择。不要让客户对报告中的部分产生歧义。只有客户对报告的完全的理解，才能在日后客户提出的修改被认为是需求变更的时候能够得到客户的理解
h) 最后，需求分析报告一定要双方共同签字确认
Gz85.Com更多总结小编推荐
需求分析小结
需求分析是项目开发的基础，基础打的牢不牢直接关系到后面所有的工作，是项目实施成败的关键
项目经理博客
总体上说，我们的需求分析是做了，但是做得很不够，我们做的需求只解决了我们能做出这样的项目，但是没有解决这样的项目是不是真就是客户想要的。造成这种状况的原因主要是下面几个情况：
客户本身说不清楚
文物网是这样，中彰国际更是这样，但是这不能怪客户，毕竟客户在软件方面的知识要少的多，也没有相关的经验，可能心里只有一个想要的软件的轮廓，于是可能会要求我们去替他们来完整这个轮廓的细节，而我们的能力、我们能否真正站在客户角度去搜集和整理这些需求，就决定了这个需求的完整性和有效性。
需求自身经常变动
随着客户对这个项目越来越深刻的理解，那么可能他的需求也会随之改变，这些变化的可能性越大项目风险就会越大，我们在需求分析的时候就要充分考虑到哪些需求是相对固定的需求，哪些可能会是产生变动的需求，考虑到他的可变性，这样设计功能和数据库的时候不致因为后面的变动而影响整个工程。
分析人员或客户理解有误
毕竟，不是每个分析人员都是专业而合格的，为避免这种情况的发生，需求分析必须要有审核制度，公司自己内部要审核一遍，客户再审一遍，提出意见，修改后双方共同评审签字，确认。
由此出现的问题：
a) 需求分析过于笼统，只关注到面上，没有关注到点上，开发出来的东西在具体的细节上和客户的理解有误差，并且无法严格界定是否属于需求变更。中彰的方案就是这样的。
b) 需求报告只求我们这方评审通过，不去关心客户的评审，认为只要客户签字认可就行。虽然签字认可能够给日后出现问题时划清我们的责任，但是不能保证使项目实施成功。
c) 需求分析中含有技术实施上有难度的功能，一味的求全和盲目按照客户的设想，受客户影响过大，毕竟，很多时候，客户的想法在实际实施过程中是不现实的，或者可以有更为简便的方法来替代的。如中彰国际的在线交易功能，后台大批量邮件群发功能。
d) 对双方已经确定的需求，实现以后并不适合客户使用，需要按照变更手续执行的时候，客户可能会纠缠，提出你们是专业人士，你们应该事先能提醒我们可能会出现这种问题并以此来把责任推给我们，而我们又不好完全按照变更手续执行，因为可能激化双方的矛盾，比如508的批量处理功能，因为属于人事管理比较专业的细节问题，需求分析师开始没有对客户业务熟悉到如此细致的地步，而客户也没有过多关注这些细节，导致软件的某些功能不合用，较为繁琐，而重新按着客户的意见修改的话工作量比较大，导致成本增加、工期延长。
e) 项目的成熟度受客户预算的限制。大部分客户在项目投入上都是有预算的，在成本有上限的前提下，项目的功能设计（软件的成熟度）方面必然受一定影响，毕竟功能越多越完善，相应的开发成本就越高。这种功能上的不完善需要事先告知客户并得到理解。
f) 此项工作的反复造成思想上的倦怠，使需求分析最后虎头蛇尾。需求分析是一项繁琐枯燥的工作，需要和客户之间不断的商讨、确认和反复，另外由于大部分的客户虽然安排专人负责这项工作，但是该人并不只做这项工作，特别当他被很多其他的事情缠身的时候，而无心细看提交过去的需求报告的时候，他很可能会给你一个错觉，让你认为他已经真正的理解并认可了你的设计。
结论
a) 需求分析是整个项目管理中需要重点控制的几个关键节点之一，首先思想上一定要重视。
b) 需求分析报告的编写者要参与到需求的搜集工作中，准确领会客户的意图，并转化成软件能够实现的功能。对于说不清楚需求的客户，要善于问关键问题，引导客户提出自己的需求。可以采取的措施是事先编制一个问卷调查之类的文档，详细列举需要客户回答的问题，以便防止遗漏。
c) 需求报告的编写者要能够对客户需求进行深入分析，区别出哪些需求存在日后变更的可能，哪些需求属于相对固定的，哪些需求能够实现，哪些需求需要变通才能实现，以便于指导后面的功能设计。
d) 需求分析报告对功能细节的描述不能有歧义，描述一定要全面、准确，防止开发方和客户只见对同一个问题有两个截然不同的理解。可以通过评审，用大家的力量来避免这种情况发生
e) 需求报告的每个关乎功能的描述都要让客户明白和理解，客户在理解之上的确认才能够保证日后一旦出现问题不致出现双方互相推托责任纠缠不清的情况。
f) 需求报告一定要经过一个有技术人员和业务人员参加的评审，要充分发挥团队的力量，重视每个人的才智，一个模块一个功能的逐一的过，让大家来共同找出需求报告里不合理的、有歧义的、不完善的、遗漏的等等问题
g) 帮助客户去理解提交给他的需求分析报告而不是只等签字，对于有能够用好几种方式实现的功能，尽量做到能让客户去比较和选择。不要让客户对报告中的部分产生歧义。只有客户对报告的完全的理解，才能在日后客户提出的修改被认为是需求变更的时候能够得到客户的理解
h) 最后，需求分析报告一定要双方共同签字确认
词法分析工作总结范文
工作总结之家工作总结频道为大家整理的词法分析工作总结范文，供大家阅读参考。更多阅读请查看本站工作总结频道。
词法分析是编译器工作的第一阶段，它的工作就是从输入（源代码）中取得token，以作为parser（语法分析）的输入，一般在词法分析阶段都会把一些无用的空白字符（white space，即空格、tab和换行）以及注释剔除，以降低下一步分析的复杂度，词法分析器一般会提供一个gettoken()这样的方法，parser可以在做语法分析时调用词法分析器的这个方法来得到下一个token，所以词法分析器并不是一次性遍历所有源代码，而是采取这种on-demand的方式：只在parser需要时才工作，并且每次只取一个token。
token和lexeme
首先，token不等于lexeme。token和lexeme的关系就类似于面向对象语言中“类”和“实例”（或“对象”）之间的关系，这个用中文不知该如何解释才好，比如语言中的变量a和b，它们都属于同一种token：identifier，而a的lexeme是”a”，b则是”b”，而每个关键字都是一种token。token可以附带有一个值属性，例如变量a，当调用词法分析器的gettoken()时，会返回一个identifier类型的token，这个token带有一个属性“a”，属性可以是多样的，例如表示数字的token可以带有一个表示数字值的属性，它是整型的。
如下代码：
int age = 23;
int count = 50;
可以依次提取出8个token：int(值为”int”)，id(值为”age”)，assign(值为”=”)，number(值为整型数值23)，int(值为”int”)，id(值为”count”)，assign(值为”=”)，number(值为50)
正则表达式
正则表达式可以用来描述字符串模式，例如我们可以用digit+来表示number的token，其中digit表示单个数字（这里说正则表达式并不完全和实现的正则引擎所识别的正则表达式等价，这里只是为了描述问题而已）。
然而像c语言的的多行注释，用正则表达式来描述就比较麻烦，此时更倾向于直接用有穷自动机（finite automaton）来描述，因为用它来描述非常直观且很容易。
有穷自动机(finite automata)
有穷自动机也称为有限状态机，状态在输入字符的作用下发生迁移，因此，它可以用来识别token，也因此，我们只要画得出fa，之后再用代码实现这个fa，那词法分析器也就差不多弄好了。
有穷自动机分确定性（dfa）和非确定性（nfa）两种，如果对于同一个输入，只会有一个确定的状态迁移路线，也就是只有一个确定的“下一状态”，那就是dfa，否则就是nfa。
因为dfa对于同一个输入只有一个确定的下一状态，所以词法分析器当然优先采用它，那nfa拿来干嘛用呢？nfa用来做描述用时更方便，我们可以非常迅速地画出一个识别token的nfa图，但要想直接画出个dfa那要动不少脑筋。
根据正则表达式构建nfa
如上所述，nfa更容易画出，那我们就先研究nfa，在定义token时，我们可以用正则表达式来描述它，因为正则表达式干这行很合适，例如一个digit+就可以描述数字，多方便。因此，我们需要根据正则表达式画出与之等价的nfa。而这个算法非常简单，就是tompson’s construction，这个书上写得很清楚了。
将nfa转化成dfa（nfa的确定化）
对于计算机来说，面对同一个输入，如果有多个下一状态，那计算机就不清楚要转到哪个状态，所以我们期望能从正则表达式得到dfa，而不是nfa，因为这样将来编程实现时比较自然（同一输入有确定的一个下一状态），而幸运的是，每个nfa都可以转化成dfa。为什么nfa可以转化成dfa？因为fa(finite automata)中的状态都是我们自己画的，只要fa能正确的识别token，那就ok了，也就是，如果nfa和dfa都可以达到一样的效果：识别token，那其它的我们就不管了。而nfa确定化的本质，就是将原来多个状态改用一个状态来表示，新状态其实是一个状态集，比如nfa中状态s1在输入a下可以到达s2和s3，那么，在dfa中，就把s2和s3合起来认为是一个状态。还有一个问题是nfa中的空转换（?输入），如果s1在?输入下可以到达s2，就表示s1可以无条件地转移到s2，那s1和s2自然可以合并起来作为dfa中的一个状态，于是nfa转dfa的算法也就好理解了。但首先得先定义下空闭包（?-closure）：
?-closure: 状态s的?-closure即s经过?转换可以到达的状态集，s的?-closure永远都会包含s自身。一个状态集的?-closure即该状态集中各状态的?-closure的集合。
nfa确定化算法(subset construction)：
从开始状态开始，计算它的?-closure，得到状态集set1，然后考察set1在某个输入a的作用下会迁移到哪些状态，把这些状态集中到一起，再求这个集合的?-closure，得到set2，这样我们就可以画两个圈，一个标上set1，另一个标上set2，然后画条从set1到set2的线把这两圆连起来，在线上标上a，这样dfa的一部分就画好了，然后我们再考察set1在其它输入下可以达到的状态集的?-closure，同样画圈连线，以此类推，最后的时候，把包含了原nfa中终结状态（final state或acceptin state）的dfa状态（在转换后的dfa中，每个状态都是包含了一个或多个原nfa中的状态）标记为终结状态。
最小化dfa状态数
由一个正则表达式，可以构建出一个等价的nfa，然后nfa又可以确定化成dfa，似乎到此事情搞完了，但事实证明（有时也可以显然地发现），最终构成的这dfa似乎有些复杂，有些状态好像很冗余，呃，是的，dfa是可以最小化的。
最小化dfa状态数算法的思想是，在开始时，假设是最完美的情况，整个dfa只有两个状态，一个终结状态，一个开始（难道不能有只有一种状态的情况么？如果原dfa中存在非终结状态，当然就不能，非终结态怎么可以和终结态合并！），当然，这是假设，不是真的，所以这个算法，就是在这个完美的假设下，对假设进一步考察，如果发现有些状态不能合并，那就分出来吧，这样重复考察，直到发现没有状态会不能合并时，就做完了，此时不也正是解么。
嗯，就是这个，所以一开始，我们把所有非终结状态用一个袋子包起来，看成是一个状态，把所有终结状态也用另一袋子包起来，也看成是一个状态，注意，别把原dfa中各状态间的连线给扯断了。然后，我们抽出其中一个袋子，考察其中的各个状态，我们准备好所有的可能输入，然后逐个拿出来测试，如果该袋子中的所有状态在某个输入a下达到的状态正好都在这个袋子中，那就说明，这个袋子中的这些状态“在目前看来”是可以合并的，也就是说，如果在所有的可能输入的作用下，袋子中的状态达到的新状态正好也都是这个袋子中的状态，那它们就可以合并。而如果，在某个输入a下，袋子中的一部分状态会转移到同一袋子中的其它状态，而有几个叛徒，假设是s1和s2，竟然在输入a下会迁移到其它袋子中的状态，那就说明s1和s2是不可以和其它转移到同一袋子中的状态合并的，于是，我们就把s1和s2装成一个新袋子，从原袋子中分出来，当然，现在还是假设s1和s2可以合并，所以才把它们装一起，究竟真的可不可以合并呆会还要再考察。考察完输入a，还要接着考察其它的可能输入。如果在考察完一个袋子后，发现所有状态在a输入下都可以转移到本袋子中的状态，那么最后的dfa它们就被合并成一个状态，并且在a输入下，它有一个到自身的状态迁移。实现词法分析器
对于一个token，比如用来表示数字的token：num，我们可以用正则表达式描述它，然后画出nfa，再将nfa转化成dfa，再最小化dfa的状态，但是我们的词法分析器是不是分析一个token，所以我们要把所有类型的token的dfa合并成一个dfa，这样，这个dfa也就可以识别语言的所有token了，如果在某一连串的输入下，dfa达不到终结状态，那就说明源代码有错误了。
我用c#实现了一个用于《compiler construction: principles and practice》中tiny语言的词法分析器，tiny语言有关键字：if, then, else, end, repeat, until, read, write，有操作符+，-，*，/，=，<，(，)，;，:=（全角逗号不算，是文章的分隔符）这10个，然后其余的token有number (一或多个数字)和identifier(一或多个字母)，其dfa如下图：
上面这张图和《编译原理及实践》中的一样，其中的带中括号的输入说明这个输入是lookahead的，在匹配成功后是要重新放回输入流中的，比如识别num时，如果发现个非digit的，那就说明识别到了一个number，但是最后识别的那个非digit字符是要放回输入流的，因为它要留着下一次识别。
其中从start到done的那个other，指所有非white space，非{，非letter，非digit，也非:的字符，它有可能是合法的+, *, /这些，也可能是不合法的其它输入，如#号。因此，done这个状态只是说本次gettoken已经结束，状态机是有可能因为不合法的输入而进入done状态的。究竟从start到done是因为合法的，如+号导致的，还是由不合法的如#号导致的，将在代码中实现判断，但可以肯定的是，不管是+号还是#号作用于start状态，都会进入done状态。
环境分析工作总结范文
工作总结之家工作总结频道为大家整理的环境分析工作总结范文，供大家阅读参考。更多阅读请查看本站工作总结频道。
一、房地产市场宏观环境分析
1、宏观环境分析
（1）9月房地产开发投资呈反弹趋势
——房地产开发投资额恢复到7月水平
成都市统计局数据显示，今年1－9月成都市房地产开发投资额达到311.72亿元，同比增长59.1％。开发投资额略有反弹，7月房地产开发投资额35.01亿元，8月为29.77亿元，9月为34.22亿元，接近7月投资额。受房交会影响，9月商品住宅开盘数量和可供应量较上月有所提高，同时也刺激了房地产开发投资额的回升。
（2）1－9月销售面积降幅减小，呈现回暖势头
今年年初，商品房销售面积下降29.9%。6-9月房地产销售面积降幅分别为11.9%、8.9%、2.1%和0.2%，销售面积降幅逐月递减。1-9月全市商品房销售（预售+现房销售）面积为784.4万平方米，下降0.2%。商品房预售面积为680.81万平方米，增长16.9%。销售降幅减小且期房所占比例上升，新政带来的短期需求萎缩现象开始慢慢改变，市场正逐步回暖。
（3）1－9月商品房空置面积持续下降，楼市逐步恢复活力
1－9月，商品房空置面积为143.26万平方米，下降3.7%，其中，住宅空置55.80万平方米，下降19.2%；商业营业用房空置55.13万平方米，增长29.0%，大大高于全国4.2％的增长率。从商品房空置特性来看，空置期在一年以内的“待销房”为79.92万平方米，增长16.3%。空置期在一年以上的“滞销房”和“积压房”为63.34万平方米，下降21.9%，其中：住宅空置24.62万平方米，下降36.4%；商业营业用房空置23.95万平方米，增长33.9%。由此可见，成都的住宅房地产市场状态良好，而商业房地产市场前景不容乐观。
（4）9月商品房销售额增幅加快
受去年商品房开工面积持续多月下降的影响，商品房的竣工面积继续呈下降态势，竣工面积为360.18万平米，下降20%，比上月降幅低3.6个百分点。竣工面积的减少和去年销售旺盛空置房大幅下降，导致商品房销售面积持续下降。九月，继续下滑的势头得到抑制；销售面积与去年基本持平，仅略有下降，为0.2%，其中：预售继续加快，面积为680.81万平米，增长16.9%，比上月增幅提高2个百分点；现房销售下降继续减弱，面积为103.59万平米，下降49.1%，下降幅度比上月低0.9个百分点。这使商品房销售额增速加快，为249.47亿元，增长16.7%，比上月快1.1个百分点。
（5）1－9月房价“温柔”上涨，新政作用明显
今年1～7月，商品住宅均价为3677元／平方米，比去年同期上涨16.95%。受新政影响，6月、7月涨幅从5月的21.93%降低到15%左右。从8月份开始，成都房价出现回升，到9月20日止，成都楼市整体均价已回升至3750元／平方米。预计，成都房价在今年年末仍将小幅上涨。
点评：以上数据显示，在新政实施的最初4个月中成都房地产市场经历了从需求强劲到需求滞缓的变化，但到了9月后，成都房地产市场已经适应了新政实施带来的变化，正逐步回暖，楼市也在慢慢回复活力，市场由此进入了需求回升阶段。
2、房地产政策及影响
重点政策解读
成都市物管企业退出物业项目管理指导意见
我市首部《成都市物业管理企业退出物业项目管理指导意见》日前全面出台，于９月１日起正式施行。《意见》针对物业管理企业退出物业项目管理时容易出现４种易产生纠纷与矛盾的情形，分别对物管企业和业主委员会等做了不同的要求。若不按照《意见》规定，擅自退出物业项目管理的物管企业，将被记入企业信用档案，并作为不良行为记录向社会公布。