Software Engineering part02-Software Requirements and Requirements Specification

Course Introduction

The "Software Engineering" course is the core course of the software engineering major. It is a comprehensive course that uses engineering methods to guide software development, maintenance and management. The content involves the theory and technology related to software analysis, design, implementation, maintenance and project management. , methods and CASE tools.

Exam syllabus

⚫Software 重点掌握engineering 基本概念and 基本原理;
⚫Based on the current needs of China's software companies for software development, master and be able to 运用software engineering, 基本原理practical 软件开发技术and basic 管理技术;
⚫Software 了解engineering discipline 知识结构.

⚫(1) Software engineering concepts and basic elements of software engineering
⚫(2) Software process
⚫(3) Software requirements and software requirements specifications
⚫(4) System specifications and software design
⚫(5) Software testing
⚫(6) Software engineering Management⚫
(7) Software Quality, Quality Characteristics and Software Quality Assurance⚫
(8) Computer Aided Software Engineering CASE Tools and Environment

Software Requirements and Requirements Specification

2.0 Feasibility Analysis

The main task of the feasibility study is to "understand the customer's requirements and the actual environment, study and demonstrate the feasibility of the software project from the three aspects of technology, economy and social factors, write a feasibility study report, and formulate a preliminary project development plan."

2.1 Overview of Requirements

UR SR BR Reference: https://www.zhangshilong.cn/work/307775.html Software requirements describe the software services (functional requirements)
to be realized by software products and the constraints that need to be met (non-functional requirements) . Users use these services to complete work tasks and meet business needs. **SR (System Requirements, System Requirements) is the product of requirements analysis and modeling. System analysts analyze, refine, and organize UR (User Requirements, User Requirements)**, so as to generate more accurate and guiding development Software Requirements. SR is written in the "Software Requirement Specification", SRS (Software Requirement Specification, Software Requirement Specification) , which fully expresses the expected characteristics of the software project, and provides the basis and foundation for the subsequent software design and testing.

Classification of needs

Classification of user needs:

(1) Functional requirements: Define what the system does
(2) Non-functional requirements: Define the characteristics of the system when it works

User needs content:

(1) function
(2) performance
(3) environment
(4) interface
(5) user or human factor (
6) document
(7) data
(8) resource
(9) security and confidentiality
(10) cost consumption and development progress
( 11) Quality Assurance

Functional Requirements:

What does the system do?
When does the system do what?
When and how will the system be modified or upgraded?

Performance requirements (technical indicators for software development)

Storage Capacity Limitation
Execution Speed, Response Time
Throughput

Environmental requirements:

Hardware equipment: model, peripheral, interface, location, distribution, temperature, humidity, magnetic field interference, etc.
Software: operating system, network, database

Interface requirements:

Is there input from other systems?
To output from other systems?
Is there a requirement for the data format?
Are there requirements for data storage media?

User or person elements:

What does the system do?
user type?
Various user proficiency levels? What kind of training is required?
How difficult is it for users to understand and use the system?
Possibility of user error operating system?

Documentation requirements:

What documents are required?
Who is the documentation for?

Data requirements:

Input and output data format?
How often do you receive and send data?
Data accuracy and precision?
Data Flow?
How long should the data be kept?

Resource requirements:

The data and software required for the software to run. resources such as memory space.
Manpower required for software development and maintenance, supporting software, development equipment, etc.

Security and confidentiality requirements:

Do you need to control access to the system or system information?
How to isolate data between users?
How are user programs isolated from other programs and the operating system?
System backup requirements?

Software material cost consumption and software development progress requirements:

Is there a set timeline for development?
Are there any restrictions on hardware and software investment?

quality assurance:

System reliability requirements?
Must the system monitor and isolate errors?
Specifies the average time to error of the system? ?
After an error, the time allowed to restart the system?
How are system changes reflected in the design?
Does maintenance include improvements to the system?
System portability?

2.2 Requirements Engineering Steps

2.3 Demand Acquisition

Purpose

(1) Clearly understand the problem to be solved;
(2) Completely obtain user needs.

demand acquisition method

(1) Interviews and questionnaires
(2) Group discussions;
(3) Series of scenarios;
(4) Participation in and observation of business processes;
(5) Description documents of existing products and competitors;

2.4 Requirements specification

A model is an abstract, generalized or approximate representation of the formalized features of the object system; formal language: mathematical language, graphics, etc.; the process of constructing a model is an abstract and analytical process.

2.4.1 Logical Model and Physical Model

2.4.2 Requirements Analysis Process Schematic

(1) Obtain a specific model (physical model) of the current system through the investigation of the real environment

(2) Remove the non-essential factors in the concrete model and abstract the logical model of the current system.

(3) Analyze the difference between the current system and the target system, and establish a logical model of the target system.

(4) Improve and supplement the target system, and write a complete demand statement;
(5) Review the demand statement until it is confirmed that the document is complete and meets all the needs of the user.

2.4.3 Structured analysis model

2.4.4 ER diagram is the basis of data modeling

2.4.5 Data Flow Diagram

Data Flow Diagram, DFD, is an excellent tool to describe the logical model of the system, and uses graphical symbols to describe the flow direction and processing of data in the system. After the data is input into the system, it undergoes a series of processing, and finally outputs new data.
Basic composition:

Data flow, processing, files, source and destination.

Description of the problem:
The purchasing department of a factory needs an order report every day. The report is sorted by part number, and all parts that need to be ordered again are listed in the table. For each part that needs to be reordered, the following data should be listed: part number, part name, order quantity, current price, primary supplier, secondary supplier. Parts storage or storage is called a transaction, and the transaction is reported to the ordering system through the CRT terminal stored in the warehouse. When the part inventory is less than the inventory threshold, it is decided to order again.

Problem Analysis: Source/Destination, Processing, Data Storage, Data Flow
1) Source/Destination: Entities outside the system (people, things, systems)
Source: Warehouse Administrator Endpoint: Purchaser
2) Processing:
Report required －> Generate reports
and handle daily affairs－> Transaction processing
3) Data storage: order information inventory list
4) Data flow:
Order report: part number, name, quantity...
Transaction: part number, transaction type, quantity...

2.4.5.3 Dataflow Naming Rules

1) Top-level processing can use the name of the software item.
2) The name preferably consists of a predicate verb plus an object. Such as "calculate the handling fee", "check the legitimacy" and so on.
3) The name should reflect the function of the whole process, not a part of it, otherwise it should be decomposed into multiple processes.
4) Don't use empty names. Such as "calculation" and "processing"
5) If you encounter difficulties in naming, it is probably caused by improper decomposition, and re-decomposition should be considered.

In hierarchical data flow diagrams, data storage is generally limited to a certain layer or layers.
The naming method is similar to data flow

2.4.5.6 Hierarchical decomposition of DFD:

2.4.5.7 Draw layered DFD guidelines:

(1) Balance between parent graph and subgraph The
continuity of data flow must be maintained when the model is refined, that is, the input and output of each refined part must remain unchanged (the input data and output data of the parent graph and subgraph should be consistent).

2.4.6 Data Dictionary

2.4.6.1 Data Flow Entry

Give the definition of a data flow in DFD,
usually including:

Data flow identification
Data flow source
Data flow destination
Data composition of data flow
Flow attribute description: frequency, data volume

2.4.6.2 Datastore entries

2.4.6.3 Data Item Entry

2.4.6.4 Processing items

The processing logic is given for the basic processing process, and some information related to processing is also included, such as execution
conditions, priority, error handling, etc.

Processing logic description tool:
1) Use structured language
2) Use decision table to describe
3) Use decision tree to describe

2.5 UML requirements specification

2.5 UML requirements specification UML (Unified Modeling Language, Unified Modeling Language), is a visual modeling language defined for object-oriented software development methods, and is an industry standard modeling language. The standard modeling language UML is suitable for describing any type of system with object-oriented technology, and is suitable for different stages of system development, from requirement specification description to testing and maintenance after the system is completed.

2.5.1 UML composition

2.5.2 Use Case Diagram

2.5.3 Use case description

2.6 Requirements Specification (SRS)

1 Preface
1.1 Purpose
1.2 Scope
1.3 Definitions, Abbreviations, Abbreviations
1.4 References
2 Mission Overview (Project Overview)
2.1 Product Description
2.2 Product Functions
2.3 User Features
2.4 General Constraints
2.5 Assumptions and Basis
3 Specific Requirements
3.1 Data Description (DFD, DD)
3.2 Functional description
3.3 Interface
3.4 Performance requirements
3.5 Attributes
3.6 Other requirements

Summarize

This series of blogs is related to software engineering. This article is the second part of software requirements and requirements specifications.