Today, I am watching "Agile Software Development", I read the introduction to UML in the appendix, I can't help but sigh: I used to be so feet when I was in UML, especially when describing the needs.
I just designed a project, and I encountered a headache problem - demand analysis. I want to cancel the document method described in our previous use of text, using UML graphicalization. There are two reasons for cancellation, one is that the project team members are not willing to see the document to understand the needs, our technical text expressions are not like, their own things are still good, give others, I can't help the test. The second is that the document is too much trouble. After the demand changes, there is no time to change the document, and the team members are also communicated with the only words inside oral or mail, and the result document has become a piece, demand I didn't really manage it in the end.
But how do you use UML to clearly describe the needs? Seriously read "UML DISTILED", this is very easy to understand, it is easy to get started. However, in the specific application process, it has encountered trouble. If you can express the needs, that is the example of the example, the area map can also be used. What is more important is that the example map is too simple to describe the demand, that is, the actor plus USE CASE, almost painted a simple and clear figure. And that area map, more biased towards analysis design, is not suitable for communicating with people who do not understand technology. In this case, only the description of the graphic text is used to match the text description of the large segment by a simple graph. This also makes me feel awkward.
After reading the introduction of UML in "Agile Software Developments, I have a new inspiration. For example, use the example map, you can use the Extension Point to connect to use cases. For example, when the customer pays, you can choose a variety of payment methods, and each payment method has a different process. If the payment is used as the use example A, a variety of payment methods are used as a use case B1, use case B2, etc., use case B1, use case B2 to extend the use case A. This accurately describes the needs of a variety of payment methods. The description of the "include" relationship is also useful. These methods have seen before, but they did not see so clear today. Perhaps after experiencing setbacks, see a new solution, exceptional attention.
However, although some progress has been made in the UML graphical representation, the fundamental issue of demand management has not been resolved. There are a lot of needs (at least customers think so), such as: requirements on the interface, operational requirements (to support touch, etc.), refine the demand on the process (to be in the weekly promotion, etc.), all these needs How to manage how to manage the project, key processes, refinement processes, interface requirements, etc., how to manage it is a problem.
I am thinking, there are some eyebrows, these thinking will stay in my next article.
