Basic Steps for Application Design (iterative programming)

ArticleDirectory

• How to find Use Cases

(The design referred to in this Article refers to products sold in batches, rather than customized Cases)

Many developers with two to three years of development experienceProgramThey really want to improve their application design and analysis capabilities and hope to be a system analyst in the future. However, this skill is hard to learn from books or the Internet directly, and there is no suitable teacher around them, therefore, there is often a lack of flexibility. It is often because the design model is more familiar than their architects, but it is also difficult to design anything.

Writing these series of articles is not intended to allow you to "suddenly change" from a programmer to an analyst, but to provide you with learning directions and fragmented skills.

Well, let's get down to the truth. How can we do our analysis? At the beginning, you don't have to think about receiving a system at once, even if it's a little small (it's not good. Projects that are easy to take over are some independent small modules. They seem to have a single function, and you need to consider a much smaller area.

Now let's assume that you have received the design task of this module in a glorious way. Some people may have to wait for coding (this function is too simple, although I am also engaged in extreme programming, we do not recommend that you do not perform system analysis at all. Or step by step:

• Find reasonable functional use cases;
• Analyze the importance of case arrangement;
• Design the first version that meets the basic functions (no documentation? Yes, basically only use cases );
• Use Case test;
• Add some unimplemented use cases, reconstruct the current version, and create another cycle.
• Until you think that the construction period is approaching, stop it quickly, or you are very smart and have completed all the use cases;
• Document.

Hmm? Is it similar to what I wrote in the book? Of course, it's almost impossible for me to invent a new design methodology. As a matter of fact, I just want to help you review it :).

The steps are the same. The most important thing is how to do it.

How to find Use Cases

It is very important to find rational use cases. Generally, you can find use cases in these areas:

• If you have an old version, how can you lose the features of existing products? Otherwise, your functions will be messy. The customer still said: this is not as good as before.
• In fact, our sales staff spent 60% of their time on selling their products, in addition to spending 10% of their time with customers, and of their time talking about our functions, there is still 30% of the time to talk about how the competitor's products are not good. You can see that they do not have this function. The ability to "absorb" Good designs from competitors will reduce your troubles.
• From previous secondary development cases, whether well done or not done well, since these cases exist, it indicates the fact that these requirements exist.
• Well, if you have enough time, energy, and approval from the boss, you have another option to pick up some of your typical users and go to the client, look like an airman to see how they work. Don't take a notebook and show your smiling face. Excuse me, what are your requirements.

Oh, you must have discovered that I put communication with customers at the end, isn't that a big taboo? To solve this problem, I will discuss the considerations for finding use cases:

• The customer you are dealing with is a professional in his industry, not a "software professional". You are a "talent". Are you asking him what he wants wrong? Therefore, customers can use their own subjective methods to "understand" others' needs. The demand they put forward is a layman's demand, and you need to realize it by yourself.
• Use Cases should avoid expansion of demand. The main manifestations of demand expansion are:
• Temporarily unavailable features are not considered in the next eight years;
• Over-performance and load are clearly small factories with hundreds of users, but they have to work out a load balancing mechanism for concurrent operations by thousands of online users;
• With too much compatibility, your product clearly only sells for 10 thousand yuan, but you need to launch sqlserver and Oracle versions;
• The customer's demand is "strong. This should be avoided. Many articles have issued such warnings.
• Use cases must be simple. The summarized use cases must be very simple. If they are too complex, we recommend that you split them into several simpler use cases. Simple use cases can reduce ambiguity during communication.

There are many templates for use cases on the Internet for reference. The most important thing is: input and output, which must be described accurately.

Well, the article is also the same, it is better to be a little short. I will continue to write the article when I have time: how to convert the demand caseCode.