【Soft Engineering】Acquisition of requirements

Chapter 4 Obtaining Requirements

4.1 Requirements process - the process of obtaining requirements

SRS Software Requirements Specification

Get requirements process

4.2 Demand triggering

4.3 Requirement Type

Functional Requirements - describe the functions or services that the system is expected to provide

Services to be provided by the system
How to react to input
Behavior of a system under certain conditions
Description method : text description, icon representation
Functional requirements description should be complete and consistent and accurate

Non-functional requirements refer to those requirements that are not directly related to the specific functions of the system

Response time
Ease of use
high reliability
low maintenance cost
such as POS machine,

field needs

Derived from the application domain requirements of the system
Respond to the basic problems in the application field, which directly affects the availability of the system
copyright restrictions,

4.4 Demand characteristics

correctness
consistency
Unambiguous
integrity
feasibility
Correlation
Testability
traceability

4.5 Modeling Notation

4.5.1 ER图

four ingredients

Rectangular box : represents the entity, and the entity name is included in the box
Diamond box: write the contact name in the contact box between the entity and the entity
Oval : Indicates the attribute of an entity or a relationship, and writes the attribute name into it
connection
- one to one
- One-to-many: many parties write N
- Many-to-many: many parties write N, M

Construct ER Diagram

The method comprises the following steps: identifying the entity set; identifying the relationship set; identifying the attribute value set; identifying the main attribute.

Example 1: • Build an ER diagram with two entities, book and author, and their attributes and connections.

– Book attributes: ISBN, title, publisher, price

– Attributes of the author: ID number, name, age

4.5.2 UML class diagram

Standard Modeling Language UML

UML basic primitives: class, object, package, interface
UML model diagram: formed according to UML modeling rules. For example: use case diagram, class diagram, object diagram, state diagram, etc.
UML modeling rules: UML model diagrams must be organically combined according to specific rules to form an organic and complete UML model diagram

Class Diagram Summary

The main purpose of the class diagram is to reflect the structure of the class (attributes, operations) and the relationship between the classes. It describes the structure of the software system and is a static modeling method.
The "class" in the class diagram corresponds to the concept of "class" in the object-oriented language, which is an abstraction of things in the real world

Class Diagram Explanation

kind
- It is divided into three parts from top to bottom, which are class name, attribute and operation. class name is required
- If a class has attributes, each attribute must have a name, and can also have other descriptive information, such as visibility, data type, default value, etc.
- If the class has operations, each operation also has a name, and other optional information includes visibility, parameter names, parameter types, parameter default values, and the return value type of the operation, etc.

Relationships in Class Diagrams

Association relationship: describes the relationship between the structure of the class. Has information such as direction, name, role, and multiplicity. General association semantics are weak. There are also two strong semantics, namely aggregation and combination
Generalization relationship: In object-oriented, it is generally called inheritance relationship, which exists between parent class and subclass, parent interface and subinterface
Implementation relationship: Corresponds to the relationship between classes and interfaces
Dependency: Describes the situation in which a change in a class affects the classes that depend on it. There are many forms of expression, such as binding (bind), friends (friend) and so on. Friends are a mechanism for accessing private variables.
- display method
- bind

Tomomoto

4.5.5 Petri nets

Any system can be abstracted as a ternary structure of state (or condition), activity (or event) and the relationship between them. In Petri nets, states are represented by places, and activities are represented by transitions. The role of migration is to change the state, and the role of location is to determine whether migration can occur. The dependency between migration and location is represented by flow.

Petri net structure—Petri net structure is a triplet N = ( P , T , F ), where,

① P = { p 1, p 2,..., p n} is a finite set of positions;

② T = { t 1, t 2, ..., t n} is a limited transfer set ( P È T ¹ Æ, P Ç T = Æ);

③ F Í( P ×*T**)*È( T ×P) is a flow relationship.