- Software Requirements
Software Requirements:
Refers to the user's expectations of the system in terms of functionality, behavior, performance, and design constraints.
Divided into two processes of requirements development and requirements management .
Demand development:
- demand acquisition
- demand analysis
- Requirements definition (requirements specification)
- Requirements verification: pull customers to review together, and sign if there is no problem.
Here, after the review is confirmed, the requirement baseline is formed . The following is requirements management. If the requirements are changed, they exceed the baseline.
Requirements Management (to support requirements development):
- Change control: Adding requirements must be strictly controlled.
- version control
- Requirements Tracking: Track requirements changes.
- Requirement status tracking: Whether the requirement is completed or not.
Key points: Software requirements are divided into three categories : business requirements , user requirements and system requirements . (Focus: Business Requirements , User Requirements , and System Requirements )
Business requirements: reflect the high-level target requirements of the enterprise and customers for the system, usually from project investors, marketing department or product planning department.
User requirements: describe the specific goals of the user, and the tasks that the user requires the system to complete, usually using user interviews and document investigations.
System requirements : requirements from a system perspective, divided into functional requirements, non-functional requirements, and design constraints.
Functional requirements: The functions that developers need to implement.
Non-functional requirements: properties necessary for the system, such as maintainability, high efficiency, reliability and other performance.
Design constraints: Some constraints on the system, such as the database system that must use independent intellectual property rights, must run under the Linux system, etc.
real question:
A software company is undertaking the task of developing a word processor. During the requirements analysis stage, the relevant personnel of the company sorted out some related system requirements, among which, "Find out the spelling mistakes in the document and propose a list of replacement items to choose to replace the spelling Wrong word" belongs to ( ); "Displays a dialog box offering replacement words and implements document-wide replacement" belongs to ( ); "Users can effectively correct spelling errors in the document" belongs to ( ).
- Business needs
- User needs
- Functional Requirements
- performance requirements
Answer: B, C, A
Parse:
The third one has a high level of abstraction "users can effectively correct spelling errors in documents" first, and then the first "find errors and replace errors".
The first one finds the bug and replaces it, the user goes for it.
The second shows the word, Functional Requirements.
The third requirement that can be effectively found is business requirements.
The third one is proposed and has no demand. After it is proposed, the user will find the error correction, the first one. So the third is the business requirement and the first is the user requirement. The second sentence is implementation, using code.
2. Demand Acquisition
Requirements capture the needs and constraints of the various users and stakeholders.
Common access methods:
User interviews, questionnaires, sampling, story series, joint requirements planning, requirements recording techniques.
Joint Requirements Planning (JRP): It is a joint meeting of all parties, such as demand analysts and developers.
Questionnaire survey: A large amount of data cannot be interviewed one by one.
User interviews: good flexibility, wide range of applications, but there are problems such as obtaining large amounts of information, difficulty in recording, and requiring sufficient knowledge domains.
Sampling: Based on the principle of mathematical statistics , it is not only used to collect data, but also can be used to interview or collect users to reduce data deviation.
3. Demand Analysis
Requirements Analysis: Transform messy user requirements into user requirements.
Structured needs analysis :
Top-down, step-by-step decomposition, data-oriented.
Three models: functional model (data flow diagram), behavioral model (state transition model), data model (ER diagram) and data dictionary.
Rectangle: external entity.
Round or oval: processing.
Arrow lines represent: data flow.
The two lines represent: data storage.
Data flow: Must be processed.
Processing:
With input but no output, it is a black hole.
It is a miracle that there is output but no input.
Insufficient input to generate output is a gray hole.
External entities:
Personnel or organizations outside the software system refer to the origin and destination of the system.
- Data Dictionary
Data dictionary DD
The data dictionary provides descriptions for each data flow, file, processing, and constituent data flow or file data item in the data flow diagram.
4 categories: data flow, data item, data storage and basic processing.
Processing logic has structured language, decision table and decision tree .
= means defined
= and x=a+b, indicating that x is composed of a and b
[...|...] or, x=[a|b], x means a or b
{...}, x=[a], composed of 0 or more a
- Requirements definition
Requirements definition is the basis of the entire requirements development. SRS is one of the most important documents in the software development process and should not be lacking for any size and nature.
Requirements definition method:
- Strict definition is called pre-definition, and all requirements can be pre-defined. Accurate and clear communication between developers and users,
- Prototype method: an iterative and cyclical development method. Prototypes are a means of overcoming difficulties. All project stakeholders have communication difficulties.
Requirement verification:
It is called requirements confirmation, and the purpose is to confirm the requirements together with the user and to review the requirements specification SAS.
Requirements review: formal review and informal review.
Requirements Testing: Design concept test cases.
After the requirement verification is passed, a signature is required and cannot be changed arbitrarily.
Demand tracking is divided into two-way tracking, forward tracking and reverse tracking.
Forward tracking to see if there is any lack of product implementation.
Backtrack to see if the previous document has been implemented.
( Key) The management process of requirements changes:
Change request, team analysis impact assessment, notification of assessment results to stakeholders, CCB approval (absolute leadership),
agree
Implement changes, document change implementation, distribute new documentation
CCB is the Control Board.