Demand Analysis of mobile game chat system and demand analysis of game chat system

Demand Analysis of mobile game chat system and demand analysis of game chat system

Demand Analysis of mobile game chat system

Reprinted Please note: IT_xiao xiaowu

Mobile development enthusiasts: 299402133

Planning requirement Diagram

 

Reference System: Legend of the turret

Click this button and the following dialog box is displayed.

Game type: Card

 

Analysis: The Legend Chat System of the turret is divided into three sections:

World: A speech can be made only when the team level reaches 24.

Guild: You can speak only after joining the trade union.

Private Chat: You must specify a private chat object to speak.

 

Component

Input box:

Composition:Input box + send button

 

Chat entry:

Composition:Role Avatar + grade + nickname + chat Information

 

Dialog Box:

Composition:Role Avatar + grade + nickname + from Union + chat button + black button + Delete dialog box button

 

 

Comment: The button is docked and displayed as a drawer. It is relatively simple and the interface will not be messy.

 

Arms Chat System

Game type: RPG (Role Playing)

Analysis: The system is relatively complete and can be divided into the following sections

 

Overall: displays information about all sections.

Current: displays the current chat information.

Team: displays team chat information.

Gang: displays gang chat information.

Portal: displays the portal chat information.

Camp: displays camp chat Information

World: displays chat information of all players.

System: displays system information, such as combat results, turntable, and reward information.

 

Rating: the interface is beautiful. A small speaker is displayed in the lower left corner, and a dialog box is displayed to the player.

 

Fighting Spirit Chat System

 

 

Game type: instant combat

 

Sections are divided:

World: World Channel, where you can see information sent by everyone.

Team: Team channel. Only the information sent by the team members is displayed.

Private Chat: private chat channels, only private chat information.

Team: Team channel.

Legion: Legion channel.

Camp: Camp channel.

System: displays system information.

 

Rating: similar to other OL channels, the interface is ugly.

 

The above are the three reference systems selected by the author and a simple analysis is made on them. I personally prefer 2nd display methods.

Later I will provide a Demo to share with you how to implement the chat system in mobile games.

If you think the blog is useful to you, please go to the following link to cast a sacred vote for Xiao Wu.Http://vote.blog.csdn.net/Article/Details? Articleid = 38272837

 

Who can help analyze the needs of an online chat system? The template may

1. Introduction
1.1. Background
Note:
A. Name of the software system to be developed;
B. the submitter, developer, user, and computing center or computer network that implements the software;
C. Basic relationships between the software system and other systems or institutions.
1.2. References
List the materials referenced and referenced in this Manual, such:
A. approved plans and tasks or contracts and approvals from higher authorities for this project;
B. Other published documents of the project;
C. Documents and materials referenced everywhere in this document, including the software development standards to be used. Lists the titles, document numbers, publication dates, and publishing units of these documents, indicating the source of these documents.
1.3. [Optional] assumptions and constraints
List the assumptions and constraints for the software development work, such as funding restrictions, development periods, equipment conditions, user information preparation and exchange issues.
1.4. User features [Optional]
Describe the features of end users of the software, fully describe the educational level and technical expertise of operators and maintenance personnel, and the expected frequency of use of the software. These are important constraints of software design.
2. Functional Requirements
2.1. System Scope
Clearly and briefly describe users' high-level system and product objectives, such as system development intent, application goals, scope of application, and other related background materials.
If the defined product is an integral part of a larger system, the relationship between the product and other components of the system should be described, to this end, you can use a block diagram to describe the composition of the system and the contact and interface between the product and other parts.
2.2. System Architecture (System with L2 architecture can be tailored to this section) [Optional]
Describe the overall architecture of the system by combining images with texts.
The overall architecture of the system should be provided as follows:

The overall system architecture is described as follows:

2.3. Overall system process
The overall process of the system is illustrated by combining images with texts.
Figure 1 shows the overall flowchart of the planning contract management system.

Figure 1
2.4. Demand Analysis
The purpose of requirement analysis is to acquire or describe every functional requirement in the system requirement and determine what the system can do through analysis? Who will use this system?
· Create a use case model: Discover roles and use cases, and determine the relationships between roles, use cases, and the relationships between roles and use cases.
· Description case: Specification Description of how the role interacts with the system.
2.4.1. XXXXXXX (function requirement name)
2.4.1.1. Function Description
Function No:
Functional requirements: Describe functional requirements from the perspective of user business.
2.4.1.2. Business Modeling
From a visual perspective -- use case diagram -- describe functional requirements
Figure 2 shows the use case diagram for contract editing of the integrated plan management system.

Figure 2
2.4.1.3. use case description
Describes the type of interaction between a role and the system in each use case in text.
1. XXXXXX (Use Case name)
Description Object Description
Unique Identifier of the use case
Brief description of the use case
List of participants related to the use case, and characteristics of the participants
Frequency the frequency of participants accessing this case
The status is generally divided into: in progress, waiting for review, passed review, or not passed Review
A list of prerequisites. If conditions are included in the List, these conditions must be met before accessing the use case.
A list of conditions for the backend condition. If conditions are included, these conditions are met after the use case is completed successfully.
Extended use case the extended use case (if any)
Included use cases the use cases contained in this use case (if any)
The main logical path followed by the participants in the basic operation process in the use case, that is, the work mode of the use case when all work is normal.
Optional path of the operation procedure when the working method is changed, an exception occurs, or an error occurs
Modified by: Date: reason:
If the problem exists, it is the problem related to the development of this case or the list of operation projects.

The following section describes the use cases added to the contract editing function in the integrated plan management system:
Description Object Description
Identifier ipms010...... remaining full text>

How can I write a requirement analysis report for chat software in LINUX?

First, let's get a glimpse of the LINUX application prospects.
Then let's talk about the chat software.