关于“XX管理”的用例：这种用例无法从业务流程中映射，但系统需要它们来支撑。也只有对于这种支撑的管理基本数据的用例，才用“XX管理”来打扫战场。"XX管理"这样的用例往往是给管理员管理基本数据用的，而且都是千篇一律。
软件工程的“底层”：怎样才能使这段代码更容易维护和扩展？这段代码达到的功能和性能对涉众意味着什么？
2). 系统用例规约：也就是以用例方式组织的需求规约，我们需要通过书写用例规约把用例背后封装的各种相关需求表达出来，并用类图展示用例的各项内容。
用例包含的内容：
a. 前置条件和后置条件：用例通过前置条件、后置条件以契约的形式表达需求。可以想象成：在满足前置条件的开始，按照说明的路径步骤走，就能达到后置条件。
后置条件分类：最小后置和成功后置。最小后置指在用例失败的情况下也要满足的约束，而成功后置指用例成功时系统需要满足的约束。
前置、后置条件的要求：
一、前置条件、后置条件必须是系统能检测的。
二、前置条件必须是用例开始前系统能检测的。
三、前置后置条件是约束，不是动作。
四、前置后置条件要有系统的味道。
五、登录的问题：登录不是用例，不能从登录扩展出产看订单等功能，扩展的正真意思是分支。正确的做法应该是把登录变成被其他用例包含的被包含用例，在写用例规约的时候发现下单、查单等用例都有登录步骤，为节省工作量把这些形成一个小目标的步骤集合分离出一个只能被其他用例包含的用例。如：会员【登录】中，加括号的登录表示这是一个被包含用例，他的步骤和约束在另外的地方描述。
涉众利益的要求：前置条件是起点，后置条件是终点，这中间的最要的内容就是涉众利益，即：某类人担心什么、希望什么，若没有涉众利益很难得到正确的需求。认识到需求由涉众利益的平衡和冲突决定，可以帮助我们直入需求的核心。
一、如何寻找涉众：定位用例涉众的场景：如果系统的这个用例做不好，谁或者哪个系统会遭殃？谁会担心自己的直接利益受侵害？
从执行者触发寻找涉众：若果执行者是人，其便为用例涉众。否则，执行者没有利益主张，不算涉众，但是要留意其背后可能的涉众。
从“上游”寻找涉众：执行者使用系统做某个用例，需要一些资源，这些资源的提供者可能是涉众。
从“下游”寻找涉众：执行者使用系统做某个用例，会产生后果，这个后果所影响到的人也是涉众。
从“信息的主人”寻找涉众：用例用到的相关信息所涉及的某些人（也可能其不知道这个系统的存在）的利益受系统好坏的影响。随着策略环境变化、组织需要调整，原有良好的系统确实要改变，这才是真的需求变更。
从“给涉众排位”寻找主要涉众：涉众排位是否准确，直接影响了需求的内容，开发人员别只盯住了“用户”而忽略了前排涉众。并没有一定的排位准则，只能根据所改进组织的特点归纳总结。
“亲兄弟，明算账”：在描述涉众利益时，要把不同涉众关注的不同利益体现出来。在列出涉众利益后，在照顾前排涉众利益的同时，也要争取兼顾和平衡其他涉众的利益。涉众利益放在用例规约里可以体现出不同涉众针对不同用例有不同利益的特点。
“基本路径”：我们需要写出能够平衡各方涉众利益的路径、步骤和补充约束。用例需要有一条基本路径，若干条扩展路径，首先把基本路径单独分离先写出来，因其代表用例核心价值的路径。
书写路径步骤的要点：
1.) 按照交互四步曲书写：执行者和系统一个个回合进行交互，直到达成目的。每回合步骤分为四类：请求、【验证】、【改变】、回应（有的回合可能没有验证和改变），其中括号表示操作在系统内。
2.) 使用主动语句理清责任：把动作的责任人放在主语的位置，用Cockburn的话就是“球在哪里”。
3.) 主语只能是主执行者或系统。写需求时要把系统当作一个黑箱，仅描述它对外提供的功能和性能，而系统如何构造不属于需求描述的范围。
4.) 使用核心域的概念：路径步骤是功能需求，应该使用核心域的概念来描述，也就是说，要说“人话”。应该避免“技术”、“业务”等名词，而换用“核心域”、“非核心域”来代替。
5.) 不要涉及交互设计的细节：避免把界面细节带入到需求中。“人有眼镜”不是需求，需求是“人能看”。
需求的判断标准：需求是问“不这样行吗”，而不是“这样行吗”。需求确实需要写的细，是需要将需求（问题）写的细，而不是将设计（解决方案）写的细。