Chapter 1 demand analysis

One, the introduction

1. Writing purpose

Ii. Documentation

  1. Document purpose

Iii. System introduction

  1. System Overview

  2. System User Positioning

  3. Roles in the system

Iv. System Description

  1. System function structure diagram

5. Functional requirements

  1. The function point

  2. Functions overview

  3. Nonfunctional requirements

  4. Performance requirements

6. System function use case diagram

【 Function point text and text brief introduction 】

Chapter 2 outline design

I. Overall system structure

Ii. Functional module structure

3. System framework

Four, the use of technology

Chapter 3 detailed design

[Design of function points, including structure diagram, use case diagram, sequence diagram, flow chart, class diagram, topology diagram, ER diagram, block diagram and database table structure, requires meticulous procedures for each step]

System UI interface

Chapter 4 Test Report

Enterprise and commercial specifications generally have hundreds or thousands of pages, detailed to how to do, what to do, will be detailed in the document, so requirements analysis, outline design, detailed design, test reports will also be separated

The whole system phase is roughly as follows:

1. Requirements analysis Overview

1.1. Concept of software requirements

Software requirements are the user’s expectations of the target software system.

In order to develop software products that truly meet users’ needs, users’ needs must first be known. A deep understanding of software requirements is a prerequisite for successful software development, and no matter how well people design and code their software, programs that don’t truly meet users’ needs will disappoint users and frustrate developers.

Requirements analysis is the last stage of the software definition period. Its basic task is to answer the question “what the system must do” accurately. The final product is a “software requirements specification”.

Generally speaking, the needs of users include the following aspects:

  • The functional requirements

Requirements in this area specify the services that the system must provide. Requirements analysis should delineate all functions that the system must perform

  • Performance requirements

Performance requirements Timing or capacity constraints that must be met by the system, including speed (response time), information rate, main storage capacity, disk capacity, and security requirements.

  • Reliability and availability requirements

Reliability requirements quantitatively specify the reliability of a system. Availability is closely related to reliability and quantifies the extent to which users can use the system.

  • Error handling requirements

These requirements describe how the system should respond to environmental errors. For example, what it should do if it receives a message from another system that violates the protocol format. It is important to note that this type of error is not caused by the application itself.

  • Interface requirements

Interface requirements describe the format in which an application communicates with its environment. Common interface requirements include user interface requirements, hardware interface requirements, software interface requirements, and communication interface requirements.

  • The constraint

Design constraints or implementation constraints Describe the constraints that must be followed when designing or implementing an application system. Common constraints are precision, tool and language constraints, design constraints, standards that should be used, and hardware platforms that should be used.

  • Reverse demand

Reverse requirements specify what the software system should not do. Theoretically, there are infinitely many adverse requirements, and one should only select those that clarify the real requirements and eliminate possible misunderstandings.

  • Possible future requests

Clearly list requirements that are not part of current system development but are likely to be analyzed in the future. The goal is to prepare for possible future extensions and modifications to the system during the design process so that such extensions and modifications can be made more easily if they are indeed needed.

1.2. Criteria for requirements analysis

Although there are many different structured analysis methods for requirements analysis, all of them follow the following guidelines.

The information domain of the problem must be understood and described. According to this rule, the data model should be established. ERD tools are mainly used, namely entity-relation diagrams, which depict data objects and the relationships between data objects. The function that the software should complete must be defined. According to this criterion, DFD tool, namely data flow diagram, is mainly used to establish the function model, which describes the logical process that data is transformed when moving in the software system, and indicates the function that the system has to transform data, which is the basis for establishing the function model. Must be described as a result of the external event software behavior, the standards require that behaviour model is set up Mainly using STD tool, namely the state transition diagram, pointed out the behavior as a result of the external event system, describes the system’s various behavior patterns (referred to as the “state”) and the method of conversion between different states, is the basis of behavior modeling; Models describing information, functionality, and behavior must be broken down to show details in a hierarchical manner.

1.3. Tasks and steps of requirements analysis

Requirements analysis tasks include:

  1. Build an analysis model
  2. Write requirements specification

The steps of requirements analysis include:

  1. Problem analysis
  2. Requirements describe
  3. Requirement review

2. Common methods and steps for obtaining requirements

Joint analysis Group

A joint analysis team consisting of user representatives, domain experts, and system analysts analyzes user requirements

Customer interview

Fully prepare, find common language, step by step, step by step to guide customers to propose and refine requirements. Interviewing was the first technology to acquire user requirements, and it is still widely used today. There are two basic forms of interview, formal interview and informal interview. During the formal interview, the system analyst will ask specific questions prepared in advance, such as what kinds of products the company sells, the number of salespeople it employs, and how quickly it should respond to information. In an informal interview, the analyst will ask open-ended questions that the user is free to answer to encourage the interviewed person to speak up, for example, asking the user what they don’t like about the system they are currently using. There are two basic forms of interview, formal interview and informal interview. In formal interviews, the system analyst will ask specific questions prepared in advance, while in informal interviews, the analyst will ask open-ended questions that users are free to answer in order to encourage interviewees to express their ideas. Using scenario analysis techniques during user interviews is often very effective. The so-called scenario analysis is to analyze the methods and results of solving a specific problem with the target system in the future. The use of scenario analysis technology is mainly reflected in the following two aspects:

  1. It demonstrates the behavior of the target system in a way that is easily understood by the user, and may reveal further requirements that the analyst is currently unaware of.
  2. Because scenario analysis is easily understood by users, using this technique ensures that users always take an active role in the requirements analysis process. Observe the user workflow

Problem analysis and validation

List the general research direction:

① On-site observation and “snooping”

② Interview/interview

③ Questionnaire survey and “harvesting”

(4) Conference discussion, “brainstorming”

⑤ Prototype evaluation, “Interface (sample) iteration”

⑥ Scenario analysis and “Imitation”

⑦ Others, “Literature Archaeology”, “Use Case Analysis”

3. Analysis and modeling

  • chart
  • Use case diagram
  • Sequence diagram
  • The flow chart
  • ER figure
  • frame
  • The topology
  • The class diagram
  • Database analysis

Example:

  • System structure drawing:

  • Use case diagram:

  • Sequence diagram of system etc:

  • Flow chart:

  • ER diagram :(ugly and wrong, hope to help you, but do not imitate)

  • Frame:

  • Topology :(very simple drawing, still need to add a lot of things)

  • Class diagram :(not drawn)

  • Database analysis :(Markdown is too difficult to draw tables, so it is a little simple)

Party Member Information Form

Field list The field A primary key A foreign key type The length of the instructions
party_id id is Int 11 Is not empty
party_name The name Varchar 128 Is not empty
party_sex gender enum The default is 0, 1
party_number Id Card Number Varchar 18 Is not empty
party_nation national Varchar 20 Is not empty
party_birth Native place Varchar 100 Is not empty
party_birth_date Date of birth datetime Is not empty
party_education Record of formal schooling Varchar 20 Is not empty
party_time The party time datetime Is not empty
party_tel Contact phone number Varchar 20 Is not empty
branch _id Branch id is Is not empty
party_job Party positions Is not empty
relation Relationship transition type Enum Default null, 0 for incoming and 1 for outgoing

Login Information Table (Users)

Field list The field A primary key A foreign key type The length of the instructions
in_id Id is Int 11 Is not empty
username account Varchar 128 Is not empty
password password Varchar 128 Is not empty

4. Test section

Integration strategy: Incremental bottom-up integration is adopted

Test policy: first of all, test the specified normal functions, with black box test as the main, white box test as the auxiliary to design test cases, test cases should try to cover all program functions, record the problems in the test.

About software:

There are many software models:

  • POWERDESIGNER (PD is drawing database very powerful software, but is English interface, can be Chinese)
  • visio
  • Draw.io (install-free and installed versions)
  • RSA9.0
  • Visual Paradigm (charging, you can experience the professional version for free for one month, the community version is free, but there is a watermark, the sequence chart will automatically add the number, very convenient, other need to manually add, sometimes a sequence map will have dozens of serial numbers, very troublesome.)
  • Yitu (Web version)
  • ProcessOn (online, lots of templates)

I recommend small white use visio and draw easy to get started.

  • RSA9.0:blog.csdn.net/a054545641/…
  • draw：www.diagrams.net/
  • Million figure: www.edrawsoft.cn/edrawmax/ed…
  • ProcessOn：www.processon.com/
  • Visual Paradigm:www.visual-paradigm.com/cn/download…
  • Modeling software: link: pan.baidu.com/s/1QSmcXPUE… Extraction code: WAzg

So here, a simple system specification is completed, and later needs to be modified according to customer needs, but it is no problem to complete a simple undergraduate thesis.

This article is my (small white) first time to write the system manual, according to this manual also made the system, if there is anything wrong, please point out, thank you for consulting.

Need to be reproduced, please indicate the source!!

Need to be reproduced, please indicate the source!!

Need to be reproduced, please indicate the source!!