OO System analyst Path--use Case Analysis Series (8)--How to write a complete UML requirement specification

Finally, it's almost over. This will be the last of the use Case Analysis series, resulting in the requirement specification to end the requirements analysis process. After seven previous jobs, we get the business use case model from the initial business use case acquisition, which is our business scope; After analysis, we get the business scenario, which is our business blueprint, and we plan to come up with a use-case implementation view, which is our system scope; We get the use case implementation and domain model, including use case specification, business rules and business data, which is our conceptual model. We have basically completed the requirements analysis from the necessary elements required by the requirements. As we said at the end of the last article, the work to be done is essential to make our needs more perfect. This discussion will include: Use case supplement specification, system prototype, and requirements specifications

Let's start with the use Case Supplemental protocol.

The use-case protocols we have previously obtained are functional, and they are descriptions of the functional feature required for actor to complete the target business. However, in addition to the functional feature, some of the systems we face are not related to business functions, and this part of the requirement is to supplement the content of the Statute.

What kind of requirements have nothing to do with business functions? In general, it is the system requirements, such as reliability, usability, extensibility, ease of use, and so on. Users proposed that the system must provide 7 * 24 hours of service, it should have a certain ability to adapt to business changes, the system interface should be easy to learn, with basic computer knowledge can be used without training can use it and so on. These requirements have nothing to do with specific business requirements, and even if one is not implemented, the system can run. But these requirements are so important that they are essential for the system to meet user expectations. Even in the view of the user, some supplementary requirements than the business requirements are more important, a business requirements are not done well, users may be tolerant, if you say the system can not provide 7 * 24 hours of service, the user is certainly unacceptable. These requirements are the content to be explained in the Supplemental Use case specification.

I have a habit, in the previous article also mentioned that is accustomed to the global rules are also written to the supplementary use case statute inside. For example, the user proposed that all system users in the system any operation, should be able to record, if the data is changed, whether it is modify,add or delete, the data will be a backup, response time may exceed 1 minutes of function, to provide progress bar and so on ... In reality, these global rules are generally done by the system framework or by some middleware, which is part of the system architecture. So these requirements are functional, but I think it is more appropriate to use them as supplementary requirements, along with system requirements such as reliability, to be handled by higher-level designers or architects.

So is the supplemental use case specification a use case to write a copy or is it all concentrated together? The template provided by RUP is a use case to write a copy as long as they are relevant to the use case. In practical work, I think it seems more reasonable to concentrate on a document. One is to reduce a lot of duplication of effort, and the second is to centralize more easily to manage and verify.

As for the format of the supplementary Statute is not so important, as long as the user proposed, or the user did not propose, but as the system builders know that the system to run very well must go to join those characteristics, are all written understand, OK. Of course, sometimes a supplemental requirement does only relate to a particular use case, such as paying a loan fee, and one possible supplemental requirement is security, including data security and transmission security. Other use cases do not need to enter the secure channel. At this time, the special for the payment of borrowing costs to write a supplementary statute is also a reasonable and recommended way.

Again, System prototypes. The so-called system prototype according to the purpose of different, also divided into many kinds, this article is not intended to delve into, roughly speaking, and only describe the requirements of the process-related prototypes. For example, we might want to use a whole new technology, to verify its technical feasibility, a small prototype may be developed to grasp or prove that we can use this technology, and that this technology can support subsequent development, which is a validated prototype; we have an initial idea, but I don't know how far down we can go, The idea is feasible, it can also develop a prototype, this is an exploratory prototype, we have to explain to others a product, in order to visualize, can also develop a prototype, to show others explicitly to deepen understanding, this is an auxiliary prototype ... For different purposes, there are many prototypes. Another classification method is to divide the prototype into discarded and progressive, the so-called discard, is used to throw out, progressive type, it is in the future will be gradually improved on the basis of, or even form the final system.

The prototypes we need to do our needs are primarily complementary, turning the use case scenario into an operational prototype and, if it is a web system, essentially static HTML. First, it can help the system analyst to communicate better with the user, at the same time let the user of the brain Lake Tu understand, oh, the original is such ah ... Second, this prototype can help users deepen demand, imagine the user is difficult to provide specific and clear requirements, when faced with an operational interface, often Evans fountain. Third, this prototype can help the system analyst to verify the results of the requirements analysis, if the text description of the use case scenario becomes difficult to operate after the interface, then you have to change the use case scenario.

So the system prototype of the demand is discard type or progressive type? Not necessarily. Some organizations have rapid page generation tools, can quickly transform the needs of the interface, these interfaces are simple, can not meet the development requirements, the end of the demand is often abandoned; some organizations will carefully develop the interface prototype in order to collect the user's look and feel requirements in the process of requirements. These interfaces will be the basis for future development. It is true that most organizations have completed the HTML development, and the programmer fills in the dynamic code to form asp,jsp Dynamic Web pages.

When does the system prototype need to be? Although this series of articles to the end to discuss it, but the author's proposal is to start from the beginning of the prototype production. Many people complain that the demand is difficult to do, users can not speak clearly and said unclear, today said is not the same as tomorrow, complaining that users do not understand the computer. It's normal to complain, and demand is never easy, but if you don't make a good demand with this as an excuse, you're not a qualified system analyst. If the user knows the computer, what else do you want to do? Still have the nerve to take "high salary", so-called "High-tech talented person"? It is the responsibility of the system analyst to put out what the user wants to say and not to say or not to say at all. The prototype will play a huge role here, a graphical display is better than thousands of words, UML is the birth of this reason. In the initial phase of the requirements, the interface prototype may not be developed, but it is not difficult to draw a few simple illustrations with Word,visio,powpoint? Even if you draw a prototype on a draft paper, it will also play a huge role in communicating with your users.

All our preparations have been completed and we are about to hand over the results of our work-requirements specifications. Some readers will be surprised that the work we did before is not always a requirement statement? How come there's a demand specification? The reason is that our previous work is indeed a requirement statement, but these requirements are fragmented and poorly organized. Take the author to provide you with examples, the reader in the time to see how it feels? There is no chapter, no outline, nor the author's idea of organization, to see a need to understand a needs, several diagrams, spread several layers. Not a problem for the system analyst, but what about the user? Can you expect them to be satisfied with such documents and let you pass the check? Another reason is that now the system construction is generally in accordance with GB to require documentation, such as gb9385-88, especially for the supervision of users. Therefore, it is very necessary to write a requirement document in accordance with GB format requirements.

There is no need to worry about how much work the requirements specification will bring to you, but all the elements are already in place, and the work that needs to be done is simply to organize the elements together. The author provides a simple example to illustrate how to organize them. But this example does not mean that this is a standard format, you should organize these elements according to the organization specification, user requirements. What I want to explain is just the idea of an organization document and what elements are necessary for reference. Click here to download

The last point to note is that in this example, the user requirements and system requirements are divided into two parts, which corresponds to the business use case and the use case implementation. User needs are not necessarily system requirements, some user requirements need not be implemented into the system, such as the diagram delivery process in the example of this series of articles, without which the user needs are incomplete, but in reality this is a manual process, without the participation of the computer, and the user's needs may not all contain system requirements, For example, user requirements do not mention transaction processing, Operation Records, but as a robust system, these requirements are essential.

Postscript...

Over the past six months, the article on the analysis of the system analyst use cases here is over. Thanks to the support and encouragement of netizens, we have come to this day. System analysis and UML are a huge topic, and only eight articles can uncover the tip of the iceberg. Practice can grow faster than theoretical study. As far as I am concerned, if we want to discuss theoretical knowledge, we may not be able to trained the system analysts. Just a lot of practice, there are some experience accumulated to share with you. The author believes that theory-practice-theory, is always a way to grow up. As long as this series of articles for everyone still some help, it is not worth more than half a year of pen.

I do not expect to be able to talk about all the knowledge and experience in this short eight articles, nor do we guarantee that readers in need can find the answer here. But the author of the blog is still, there is no plan to collect the mountain, but this series of articles to the end of the time. If the reader has questions, there are instructions, can be in my blog message, to martial Friends is specially prepared for everyone. I guarantee that each message will reply. Thank you.

A little preview, the use Case Analysis series is over, and then the author will start the system analysis and design of a series of articles, is commonly referred to as the Ood process, which is to transform the requirements into the middle stage of the code, the audience is facing the OO system designers. Hope to continue to receive the support and encouragement of everyone. Please look forward to it.