This is the 26th day of my participation in the Gwen Challenge.More article challenges
Examine the key
Requirements engineering section mainly examines requirements acquisition, requirements analysis, UML4+1 view, UML diagrams, UML relationships, these are more important in this section, among which the most important is UML diagrams.
An overview of the
Software requirements refer to users’ expectations of the system in terms of functionality, behavior, performance, design constraints, etc. Demand development is the main line, is the goal, demand management is support, is the guarantee.
Demand for
Access method
There are several methods to obtain software requirements: data collection, joint discussions, user interviews, written surveys, field visits, business practices, historical documents, and sample surveys
Classification of demand
Functional requirements: The things that the system must do, that is, the actions that the product must perform in order to provide useful functionality to its users. Non-functional requirements: the attributes or qualities that a product must have, such as performance, response time, reliability, fault tolerance, and scalability. Design constraints: Also known as constraints, supplementary specifications, these are usually constraints on the solution, such as the need to use proprietary database systems, the need to run under UNIX operating systems, etc.
From different levels
Business Requirement: Reflects the high-level goals and requirements of an organization or customers for a system or product. Usually, the problem definition itself is the Business Requirement. User Requirement: It describes what tasks users must complete when using the product and how to complete them. It usually conducts User interviews and surveys on the basis of the definition of the problem, and sorts out the scenarios used by users, so as to establish requirements from the perspective of users. System Requirement: Describes software requirements from a System perspective. It includes functional requirements, quality attributes, non-functional requirements, and design constraints specified by features.
Requirements Analysis – Data Flow Diagram (DFD)
It is the main tool of STRUCTURED systems analysis and a graphical method to express the software model by using graphics to express the logical function of the system, the logical flow of data in the system and the logical transformation process
The element | instructions |
---|---|
An external entity | Refers to people or things that are outside the system and interact with the system |
The data processing | Also known as data processing, it means to receive certain data input, process it, and produce output. The objects dealt with are: data structures or data content. |
The data flow | Refers to the data input or output of the processing function. The arrow indicates the data flow. |
Data is stored | It can represent temporary or persistent data, files, databases, and other system elements. |
DFD drawing
DFD drawing is a top-down, outside-in process that usually follows the following steps.
- To draw the input and output of a system: to draw the input and output data streams of a system at the edges of a graph. This step is to decide the research content and the scope of the system. When drawing, you can draw as many inputs and outputs as possible, and then delete the excess and add the missing ones.
- Draw the inside of a data flow diagram: connect the inputs and outputs of a system with a series of processes, drawing from the input data flow to the output data flow, or drawing out from the middle.
- Name each data flow: Good naming is closely related to the comprehensibility of the data flow diagram, and empty names should be avoided.
- Name the process: Note that verb-object phrases should be used. Do not consider the initialization and endpoint, do not consider the error path details, do not draw control flow and control information.
Requirements analysis-ER diagram
The element | instructions | graphics |
---|---|---|
entity | The data object | A rectangle |
attribute | Attributes that data objects have. Primary keys are underlined | The oval |
Relationship between | Relationships between data objects | The diamond |
Derived properties: Properties that are not permanently stored in the database, such as a user’s nuggets, which change with the number of likes and views on a user’s article.
Multi-valued attributes: Articles can have multiple tags, represented by a double-line ellipse.
Optional attributes: Not all attributes must have a value. Some attributes may have no value. This is the optional attribute, indicated by (0) after the text of the ellipse