Use the [iconix] method to practice Blog Design 3 [Requirement Review]

Use the [iconix] method to practice Blog Design 3 [Requirement Review]

The purpose of the requirement review is to ensure that the use case and domain model meet the customer's requirements at the same time.Functional requirements. Make sure that the customer knows the development team
Design Based on these requirements. It is also a milestone in the system analysis phase (milestone ).

The position of this phase in the iconix method is as follows:


The first gathering of the three giants: customer representatives, Development Team representatives, managers on existing tools (use cases, prototypes and Domain Models)
Helps customers understand their needs and determine system functional requirements. In this process, the iconix method considersTrackability
(Traceability)It emphasizes how each requirement is transformed into one or more use cases, and the domain model.
How can one or more classes and one or more prototype elements work together with these use cases to meet requirements.

The domain model and use case model have been explained and put into practice in the previous two chapters. The prototype has not been omitted before,
It is necessary to give a brief introduction here.
First, the so-called "prototype" in the iconix method is different from the prototype highlighted in XP. Iconix method emphasis
Instead of using code to create a prototype (or working front-end, or even something between the two), use a pencil on white paper.
Draw a line chart and call it an interactive flow chart ). This graph is actually a large
The above is a small screen line chart and the navigation options between these screens. This GUI prototype discovers and
The "takeoff point" of the exploration case ". Make sure that the use case text is consistent with the navigation conditions specified by the prototype, and help ensure that the created system is
Correct. If there is no visual framework for reference, what the user interface designer creates may be the same as what the use case describes.
User needs do not match.
Then, we will go deep into this idea and explore GUI and system behavior. Repeatedly communicates with users regarding the appearance of the system,
After learning about the two or three screens, write corresponding use cases. At the same time, the case text should be consistent with the corresponding GUI elements.

The use case text involves the GUI details. But as described in the iconix method,Some outstanding
OO experts hold the opposite view. They believe that the use case text should not describe a large amount of details and should be abstracted as much as possible. Incoix
The method assumes that the efficiency of the Code in the future will be lower when the abstract use case is driven than the specific use case.".

This stage is also the stage for checking the use case text, and the method for writing the use case text is
I have talked about it in this article.

Well, with the introduction of a bunch of knowledge above, I believe you have a general understanding of the practical process to be done in this article.
The following describes how to review requirements :)

The requirements listed below are described in the (question) Domain Modeling stage:
Registered users can post, comment, leave a message, Link, album, and download files (such as RAR or ZIP files) in the management background ),
Signature, personal information, and basic blog information settings.
After logging on to the console, you can reply to other articles from the front-end..
The background administrator can manage all the articles in the system, including setting them as excellent posts and creating groups such as clubs (or groups,
Review User Registration Information.

When you see this text, compare it with the following use case diagram (from case modeling)

I suddenly found that the following requirements were not "converted" into use cases:
1. download the file (such as RAR or zip ).
2. After logging in, the user can reply to an article published by another person at the front-end.
3. The background administrator can manage all the articles in the system.
4. Set the excellent posts as administrator.

Of course, more things will be discovered if the demand persists :)

The setting tips here may be used as sub-user meetings for managing document use cases, and the use cases can be adjusted only by administrators.
. The requirements of 1 and 2 will be added to the use case diagram as two use cases. After the above check for missing traps, the use of the blog
The following figure shows the example.

When checking the "delete file" Use Case, it is assumed that the case description is as follows:

Basic Process:
The user clicks the delete button on the corresponding file in the Upload File List. The system prompts whether to delete the file.
After confirmation, the corresponding file is deleted from the file list.

Branch process:
If you click the delete button in the prompt box, the system will not perform any operations and redirect the page"
Upload File List page.

The operation interface described in the use case text is a bit vague. Here is a brief description. Refer to the GUI provided by the user:

Here, I find that a use case is "lost", that is, "browsing the file list". This step is critical because
In the GUI, it is associated with two possible user operations, namely, deleting and downloading files. Therefore, it is necessary to add it and repair it accordingly.
Modify the use case diagram and add the following descriptions:

Browse File List (uc30)
Basic Process:
When you browse the file list, the system displays the file name, size, type, file description, and other information. At the same time
The download and delete buttons are displayed on the left side of the file name.

Branch process:
If you have not uploaded any files, the Upload File List page prompts you that you have not uploaded any files.

Another term that appears in this description is to upload the "File List". It does not appear in the domain model. It is also supplemented here.
(Make sure that the use case text references the domain object ).

There will be a lot of things in this chapter, but they are basically at the "communication" and "Confirmation" levels. Because the first two articles
The work done in the article is rough, especially the analysis requirements, Case merging, and case text description. Therefore, I feel that this chapter can save energy and get to the table.
There are not many discussions. At the same time, I believe that this is also a problem that many people are easy to make in their actual work.
"Makeup" occurs during the work.

The iconix method passesRequirement ReviewThis step can alleviate the secondary effect of this problem. It is both a summary and for me
Our "overheated" project analysis is "stepping on the brakes", so that we can understand and think about the system we want to develop from the perspective of users again. At the same time
The document does not review the requirements, but allows the coders to write the code as they wish:
"Can a Requirement Review save this project (a C3, XP proud project? We are not sure, but we should point out that
The process team determines the demand priority, and the project sponsor reviews the priority together, will inevitably sacrifice the schedule".

This article is coming to an end, but I still feel like I haven't finished talking about it. Maybe it is this kind of requirement analysis that is not done in place
The fear has been affecting me, so I am not satisfied with this article. I believe everyone will feel this way, but we should look at it from both sides,
Maybe this kind of dissatisfaction will make me pay attention to it in future development and put an end to the re-occurrence of similar things.

At last, I will list the most common requirements review errors. You can discuss them with the content of this article. I will take your feedback
Modify the text information, update it after accumulating a certain amount, and attach your name to it.

Ten Most common requirements review errors

10. There is no need to review the requirements at all, but to allow the coding staff to write as they wish.
9. do not ensure that the use case text meets the required system behavior.
8. Do not use any GUI prototype or screen model to help verify system behavior.
7. Use Cases are highly abstract, so that customers who do not know the technology are like reading tianshu.
6. do not ensure that the domain model accurately reflects conceptual objects in the real world.
5. Do not make sure that the use case text references the domain object.
4. Do not question the use cases that do not distinguish any branch processes.
3. Do not question whether all the branch processes are taken into account in each use case.
2. Whether or not the use case is written in passive voice.
1. Whether or not the use case occupies four pages.

Rose file (reviewed use cases and Domain Models):/files/daizhj/blog_requirements_review.rar