A use case(UC) describes "who" can do "what" with the system in question. Ivar Jacobson put forward the idea of usage cases and usage scenarios. There are three key things for UC

1. The actor
2. The system
3. The functional goal, that the actor achieves using the system, the reason for using the system. (The goal must be value to the actor.)

Capturing UC scenarios with essential UC descriptions
A classic mistake made at this early stage of design is to go into technical detail and commit to a specific user interface design or implementation technology. An essential use case clearly  shows the order of events and the responsibilities of the actors and system in a single use case scenario, without committing to technical design decisions.
Use cases descriptions <> system requirements documents
There are all sorts of reasons why we might need to change software and some of them are inescapable. But there are two reasons that are largely avoidable,

1. Building something the user was expecting to get, but building it wrong.
2. Building something the user wasn't expecting to get.

When I make a cup of tea, I boil the kettle. I also boil the kettle when I make a cup of cocoa. When two or more use cases include the flow of another use case, they are said to include that use cases flow.
Many people get tripped up by <<include>> and <<extend>> relationships between use cases.

1. Make sure you've got the right kind of relationship:<<include>> means always included, but  <<extend>> means conditionally included.
2. Make sure you've got the arrows going the right way. <<include>> should point towards the use case being included. <<extend>> should point towards the use case(s) being extended (and not the extending use case).
   

There are a few simple steps to follow, and you can use your noodle to figure out the rest of the details:

1. Identify your actors: who will be using the system?
2. Identify their goals: what will they be using the system to do?
3. Identify key scenarios: in trying to achieve a specific goal, what distinct outcomes or workflows might we need to consider?
4. Describe in business terms the interactions between the actors and the system for a specific scenario
5. Create a UI prototype that clearly communicates the scenario to technical and non-technical stakeholders
6. Do a hgh-level OO design for the scenario
7. Implement the design in code
8. Get feedback from your user, ideally through structured acceptance testing
9. Move on to the next scenario or use case (rinse and repeat)

Do not, under any circumstances, attempt to design the entire system before writing any code. Break the design down into use cases and scenarios, and work one scenario at a time.

System Testing - Just as a storyboard adds implementation details to an essential use case scenario, so too can system testscripts add test data to the same scenarios. That's all a system test script is, in essence; a use case scenario with specific test data.

顺应时代（生存说），就是在变化很快的时代中，辨认出变化慢的因素。能力越是强的，找出的因素则越是守恒。
这个说法和我以前的想法，“在世界上唯一的永恒就是变化”，有了进一步的延伸。