Requirements and design process (1)-Use cases

1. Preface

Have seen too many of the "three-no" software, is no demand, no design, no comments. Strictly speaking, their needs and designs are still there, but they are not recorded in the documentation, but the annotations really do not. The software is big to small, but they all have a common feature, which is "difficult to maintain." Chatting with colleagues the other day, I heard that a XAML implementation is rewritten, replaced with a local protocol, and then considered to be compatible with XAML. Although I have not read the code of this project, I know that this project is basically "three none". Of course, this situation is also a major feature of the three, that is, after the forefoot is gone, the hind foot is "can not understand, not the hand", the result is not as easy as rewriting. From the staff point of view, of course, there is nothing wrong, but from the company and product perspective, it is a "meaningless loss."

A programmer who has a requirement for himself should ensure that he does not produce "three No" projects

Normalization resolves the three-none problem with the project. And this has been my respected, just have netizens started the 12306ng project, so also take this example to come, with you to report on my design ideas, but also as I set up in the company to prepare lessons for such courses.

2. About Design

The software design process is actually a derivation process, each step of the process has a variety of relationships: either refinement, or confirm, or complement. I studied design before, thought that looked at the textbook, according to what "Top down" or "bottom up" can be a step-by-step system design, but later found that I was wrong. I believe that a friend who is learning to design should also have this feeling.

The biggest difference between a computer and a human brain is that the former is a linear system, and the latter is a nonlinear system. The so-called non-linear, popular point, is topsy-turvy, ambidextrous, literary point, is to pay attention to "spiral up", in short, "mechanical" "overnight" action, the human brain is not good, of course, except genius.

Design is the same, it is the brain's processing results, so its process is necessarily non-linear. A design method, in order to be easy to learn and receive, it itself is a "spiral" improvement mechanism, that is, the PDCA process (plan-do-check-adjust), but in the design process is not obvious factors, mainly the process of DCA.

In the process of doing system design, the greatest feeling is not to limit themselves. Remember that year I to complete the design, to meet the "top down" requirements, deliberately limit themselves not to think deeply, the result of course is failure. Of course, "restriction" is not only the limit of the level of thinking just talked about, but also the limit of the breakthrough tool. All the tools will limit the thought and even the progress of the work. So far, the best design tools are "pencils with erasers" and "paper," so you have to make good use of it.

3. Requirements

12306 is the most famous and well-known human-computer interaction experience poor site, how to make a better system than it? The answer is to "design more carefully." Before we design more carefully, we need to collect the requirements "more carefully".

The requirement of software is the "purpose" that the software realizes. Please do not mention "demand" as a "demand document", the document is only a form of expression of demand, another common form of expression is the memory of the programmer's brain. Crappy programmers often pass through their mouths, they prefer to take pains, say it over and over again, and don't want to spend a little time writing them down, and they can't tolerate a change in customer demand, but not the same demand that they say each time.

3.1. First step: Use case layering

Here we use the UML Use case diagram (UseCase) to represent the requirements.

Use case diagrams are also described hierarchically. The top-most use case diagram for all systems (level 0 use cases) is similar, and is a circle around a lot of characters, the difference is how many characters, and the words in the circle are not the same. This time our circle is written "12306ng train ticket Booking system", the external role only 2: Users and Administrators.

A one-level use case diagram is completely different. I have divided it into 7 parts, the first class use case name and the two-level use case name it contains are described below:

1. User management: Registration, login, exit, password retrieve, information view, information modification, user authentication, user inquiry

2. Enquiry: Timetable, remaining ticket, joint plan, late

3. Order: Place orders, cancel orders, modify orders, order inquiries, bookings

4. Ticket: Booking, ticket, change, refund, ticket inquiry

5. Funds: Payment, refund, enquiry to account, Bank Reconciliation

6. Ticket pool: Ticket, ticket, check pool, change pool

7. Maintenance: Parameter setting, dictionary maintenance, topology management, log query, backup, recovery

The above directly listed is to facilitate everyone to read, in fact, I also use such an outline to think. Then fill in the following diagram:

Of course, the above part is neither the initial state nor the final state, but I after many adjustments and improvements, to the present state, the future will be further adjusted according to the situation of analysis. In addition, we must note that a system of use case representation is not unique, different people give the use case is different, but in theory should be equivalent.

Each part of the use case diagram must be real, and something that can be customer-facing, and the smallest unit that it describes should be the business module. The criterion of judging use case is "business meaning", so-called "business meaning" means that after the completion of the business module, the whole business or business process can be pushed forward, and the result of this "promotion" should include the change of the role or the goal.

From the definition above, "funds", "query-to-account" and "Ticket pool." The lock ticket may not be a use case. I still hesitated until I wrote this article, but then decided to cull it because they didn't have an externally associated actor, although it was true that the two use cases could drive the business forward. From here I also get an experience, that is, in the first level and level two use cases it is best not to show the actor is an internal module or system situation.

(Transferred from http://blog.csdn.net/binyao02123202/article/details/8082387)

Requirements and design process (1)-use case (RPM)