Work problem set related to software requirements (1)

1. What content does the requirement work involve?

The first requirement includes product requirements, user requirements, and software requirements. Product requirements focus on product standardization and generalization. The collected user requirements are classified and optimized, and abstracted and generalized based on industry standard system models. User requirements reflect the problem domains faced by users and the expected solutions based on the problem domains; software requirements are structured and documented in software engineering languages to describe user requirements and product requirements.

Requirement work involves requirement development and requirement management. Requirement development involves requirement research, requirement collection, requirement analysis, and requirement development. The key tasks include business processes, data dictionaries, business rules, and interface prototypes. For object-oriented development rules that involve business use cases, system use cases (stakeholder, basic flow, extended flow, business rules, interfaces, operations), and many more. Requirement management involves the status management, change management, requirement tracking, and requirement verification and confirmation.

In our demand analysis and development, there are two main points that are most easily overlooked: one is the lack of demand analysis and development processes, and the user requirements are directly taken as software requirements, there is no process for Requirement Modeling and abstraction. Another point is that non-functional requirements such as performance, security, ease of use, maintainability, and scalability are not taken into account. As a result, the developed system is a poor semi-finished product. CMMS puts demand management at Level 2 and demand development at level 3. In fact, improving the demand analysis and development capabilities is the way to solve the demand problem. Demand analysis and development are not good, and demand change or tracking management is useless. At this point, we cannot put the cart before the horse.

2. What kind of knowledge is required for requirement analysis?

The Demand Analysis job is mainly responsible for the work of system analysts. The personnel responsible for requirement analysis must have the basic knowledge of software engineering, and it is best to have a certain amount of software development experience. Only when I have done design and development work can I understand how to do a good job in the system and how to better link the software requirements with subsequent implementations. There is a book about software requirements, which is very systematic and worth reading carefully. If you use object-oriented development and analysis methods, you must be familiar with the Unified Process and case analysis and modeling of RUP.

Management software cannot be separated from the business fields involved. Therefore, to do a good job of requirement analysis, you must be familiar with the business fields involved in management software and analyze and study the standard models related to the business fields, be familiar with some industry standards and best practices. For example, the supply chain management system and software should be familiar with the SCOR Model of industry standards, and the ERP model should be combined with the ERP products of large manufacturers in the industry, the R & D management system can be integrated with pace and IPD. Only when you are familiar with the business field can you provide a lot of constructive comments during demand research and analysis, or the demand analysts can really guide users instead of being held by users.

3. What are the requirements analysis steps and outputs?

The first step is to collect requirements, which can be conducted through surveys, interviews, industry standards, discussion and communication at meetings. The first is to be able to clearly describe the status quo, and the second is to clearly understand the user expectations. At the same time, we must weaken how the user expects the system to be implemented. Because the user is not familiar with system implementation and Internal principles, our software needs not only to consider the implementation of functions, but also to consider the reuse of requirements, business abstraction, scalability, configuration, and other issues.

The collected requirements need to be analyzed, including dynamic behavior analysis and static data analysis. Dynamic Behavior analysis involves case analysis, business process and activity input and output analysis, data stream analysis, and business operation rule analysis. Static data analysis is designed to analyze Business Object Modeling, data dictionary, organizational structure, and permissions. At this stage, the focus is on systematic and structured requirements. It is best to embody the requirements in standard documents. In the software development process, the document output that we emphasize most is the requirement document and the overall design document.

Another key output in the demand analysis stage is the prototype and demo. In order to better communicate with users and explore requirements, we need to describe our ideas after understanding them more vividly to users, the prototype is very important. Whether the prototype is discarded or not, the prototype that the customer sees must be basically the same as that of the final implementation system. Therefore, prototype development requires a certain amount of time and is continuously corrected based on the customer feedback. Investing more time in the prototype will reduce the rework time caused by a later requirement change. Software prototyping is an effective way to reduce the risk of demand changes.

4. Requirements abstraction and modeling are reflected in what aspects

First, we must understand that the purpose of requirement analysis and design is to meet the current situation and adapt to changes. To adapt to changes, business modeling and demand abstraction are necessary. When we understand that the organizational structure and process of the business are subject to changes and adjustments, we need to consider introducing standard organizational structure models, permission models, and workflow models. The introduction of these models enables business and demand changes to be adapted through flexible system configurations. Software Systems must adapt to changes not from the design phase, but our software needs to adapt themselves.

Abstract requirements include the abstraction of business object models, business rules, and processes. The most important is the conceptual model formed by business object abstraction and the Data Interaction Model Formed by process abstraction. For some object modeling, process modeling, organization structure and permission modeling, Business Rule modeling, and BPEL Business Process Orchestration that are understood by the quick software development platform, the most important content of requirement abstraction is exactly.

To abstract requirements, you must have two knowledge aspects. First, you must understand the business fields involved and their standard models, second, we have accumulated much experience in software system analysis and architecture design. Only by having both knowledge can we do a good job in requirement modeling.

5. What are the requirements for verification and validation?

We can simply understand the difference between verification and validation. The process of determining whether the final developed system is consistent with what the user wants is confirmation, whether the process for your understanding and description is consistent with my original ideas is verification. The requirement Verification involves a lot of content, involving the participation of upstream and downstream personnel in software development. First, you need users to verify that your structure and documentation requirements are consistent with their ideas, and whether your actual intentions are clearly described to ensure the correctness of your requirements. Personnel in the subsequent design and development stages also need to review the requirements to ensure the feasibility of the requirements, confirm whether the requirement description is clear, whether it is achievable, and for business objects, whether there are unfeasible fuzzy descriptive words in the process and rules. For testers, it is mainly to confirm whether the requirements are testable and whether a large number of easy-to-use and good words are introduced in the Requirement Description, such as uncertain and untestable words. For large-scale software projects, if there are specialized productization standards and UI groups, you also need to evaluate the ease-of-use and product interaction needs to evaluate the productization of the entire software system.

Check whether the system meets the original requirements when the software system has been developed and delivered to the user for acceptance. In order to ensure that the validation process is smooth, we must pay attention to the requirement verification process. The requirement verification is not only the review of the requirement documents in the requirement stage, but also the design, development and other stages to verify the implementation of requirements.