* 在大规模的精益和敏捷项目中，用例作为需求建模的工具很有价值。

* 要想详细说明、深入分析以及更好地理解复杂系统的行为，用例可以提供非常多的好处。

* 在构建大规模系统时，没有哪个工具能像用例那么强大，用例可以用来发现解决方案中用户、系统以及子系统之间的互动关系。而且，就我所知，用例技术可以用来识别所有的变化场景，这样我们在涉及系统级别的质量和便捷程度的相关议题时就不会出现遗漏。

...

1. The list of goal names provides executives with the shortest summary of what the system will contribute to the business and the users. It also provides a project planning skeleton, to be used to build initial priorities, estimates, team allocation and timing. It is the first part of the completeness question.

2. The main success scenario of each use case provides everyone involved with an agreement as to what the system will basically do, also, sometimes more importantly, what it will not do. It provides the context for each specific line item requirement, a context that is very hard to get anywhere else.

3. The extension conditions of each use case provide the requirements analysts a framework for investigating all the little, niggling things that somehow take up 80% of the development time and budget. It provides a look ahead mechanism, so the customer / product owner / business analyst can spot issues that are likely to take a long time to get answers for. These issues can and should then be put ahead of the schedule, so that the answers can be ready when the development team gets around to working on them. The use case extension conditions are the second part of the completeness question.

4. The use case extension scenario fragments provide answers to the many detailed, often tricky business questions programmers ask: "What are we supposed to do in this case?" (which is normally answered by, "I don't know, I've never thought about that case.") In other words, it is a thinking / documentation framework that matches the if...then...else statement that helps the programmers think through issues. Except it is done at investigation time, not programming time.

5.The full use case set shows that the investigators have thought through every user's needs, every goal they have with respect to the system, and every business variant involved. It is the final part of the completeness question. (And yes, I did indeed sit down and walk through 240 use cases with a client, at the end of which, I turned to her and asked: "And is that everything?" She said, Yes, and we built that, delivered it, got paid for it, and it is still in use ten years later.)

* 在大规模的精益和敏捷项目中，用例作为需求建模的工具很有价值。

* 要想详细说明、深入分析以及更好地理解复杂系统的行为，用例可以提供非常多的好处。

* 在构建大规模系统时，没有哪个工具能像用例那么强大，用例可以用来发现解决方案中用户、系统以及子系统之间的互动关系。而且，就我所知，用例技术可以用来识别所有的变化场景，这样我们在涉及系统级别的质量和便捷程度的相关议题时就不会出现遗漏。

...

1. The list of goal names provides executives with the shortest summary of what the system will contribute to the business and the users. It also provides a project planning skeleton, to be used to build initial priorities, estimates, team allocation and timing. It is the first part of the completeness question.

2. The main success scenario of each use case provides everyone involved with an agreement as to what the system will basically do, also, sometimes more importantly, what it will not do. It provides the context for each specific line item requirement, a context that is very hard to get anywhere else.

3. The extension conditions of each use case provide the requirements analysts a framework for investigating all the little, niggling things that somehow take up 80% of the development time and budget. It provides a look ahead mechanism, so the customer / product owner / business analyst can spot issues that are likely to take a long time to get answers for. These issues can and should then be put ahead of the schedule, so that the answers can be ready when the development team gets around to working on them. The use case extension conditions are the second part of the completeness question.

4. The use case extension scenario fragments provide answers to the many detailed, often tricky business questions programmers ask: "What are we supposed to do in this case?" (which is normally answered by, "I don't know, I've never thought about that case.") In other words, it is a thinking / documentation framework that matches the if...then...else statement that helps the programmers think through issues. Except it is done at investigation time, not programming time.

5.The full use case set shows that the investigators have thought through every user's needs, every goal they have with respect to the system, and every business variant involved. It is the final part of the completeness question. (And yes, I did indeed sit down and walk through 240 use cases with a client, at the end of which, I turned to her and asked: "And is that everything?" She said, Yes, and we built that, delivered it, got paid for it, and it is still in use ten years later.)

1. User stories and backlog items don't give the designers a context to work from – when is the user doing this, and what is the context of their operation, what is their larger goal at this moment?

2. User stories and backlog items don't give the project team any sense of "completeness" – what I keep finding is that the development team bids/estimates the projects at (e.g.) 270 story points, and then as soon as they start working, that number keeps increasing, seemingly without bound. The developers are depressed and the sponsors are equally depressed by this. How big is this project, really?

3. Related to completeness, user stories and backlog items don't provide a good-enough mechanism for looking ahead at the difficulty of upcoming work (In principle they could, just in practice they don't) – I keep hearing this complaint, "We asked our customer (product owner) a question and she/he took 2 weeks to get us an answer. We must have the wrong person in this role." No, they don't have the wrong person, they have a broken process – certain types of questions take a long time to research, as the various departments and user groups work out what is the correct, balanced answer for the whole lot of them. Staring at the set of extension conditions in a use case lets the analysts suss out which ones will be easy and which will be difficult, and to stage their research accordingly. User stories and backlog items are not set out in that granularity early enough on for that assessment - the extension conditions are usually detected mid-sprint, when it is too late.

原文中问道：

我们该如何做好？我们现时在做的到底有用么？只有一个正确方法呢，还是有两个不同的 正确方法呢？或者视乎实际情况而定？会不会是有些情况下用用例较好，而有些情况下用用户故事较好呢？还是其实没太大分别呢——像用例中（或许）包含多个用 户故事而该用例因为一个用户情节内外都貌似用户故事呢）

Each user story is composed of three aspects:

1. Written description of the story, used for planning and as a reminder
2. Conversations about the story that serve to flesh out the details of the story
3. Tests that convey and document details that can be used to determine when a story is complete