Ten problems in Software Requirement Analysis and Management

Ten problems in Software Requirement Analysis and Management

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.

6. Why is demand management necessary?

Requirement management is the scope management of IT projects, and requirement management is the source of the entire IT project. It project estimation, planning, and subsequent tracking control, verification and validation are all closely related to requirements. Therefore, in order to ensure the smooth implementation of the project progress, quality, and cost objectives, ensure the seriousness and enforceability of the project plan, and ensure that the final product developed by the software system is exactly what the customer expects, demand management must be done well.

Demand management should be a full-Lifecycle Requirement management. From the proposal of users' original requirements to the final formation of software products, the user verifies the demand implementation to form a closed-loop process. Therefore, we need to track and understand the evolution of the demand status. The software life cycle model of a large project is complex. The implementation of a requirement is subject to user requirements, software requirements, overall design, detailed design, development and unit testing, and integration testing, system testing and acceptance testing are performed in multiple phases. In this process, a requirement tracking is required to confirm the consistency of work products generated in the requirement and intermediate stages. In addition, change management is another focus of demand management, and requirements need to be baseline and controlled after review and confirmation, when there is a demand change, the corresponding demand impact analysis must be performed to confirm the handling method of the demand change. When the workload of the change is greatly affected, adjustments should be made and the baseline project plan should be reactivated.

The entire requirement investigation, analysis, and requirement development process also needs to be managed during review and confirmation. One of the key points in this process is to get the user's requirement output documents, and the joint confirmation and commitment from the project team design and developers.

7. What is the significance of demand change management? Specific content

The user constantly submits request modifications, and the project progress is not guaranteed to be extended. A change to the requirement leads to various unexpected errors and exceptions in the originally stable system; these are the symptoms of defects in requirement management. The importance of demand management is embodied in the seriousness and enforceability of the project plan to ensure the realization of the project objectives. After the requirement change management is introduced, the software requirement document becomes a document that everyone undertakes and serves as a reference. This document needs to be designed, developed, test and other roles are fully transferred and shared. In addition, through demand management, everyone is aware of the impact of changes on the project and the cost of changes, in turn to promote the improvement of demand development quality.

The demand change management includes the proposal of change requests. The CBB Committee conducts an impact analysis on the requirements to determine whether a change is required, and the design and development director confirms the modules andCodeAnd the specific modification method, the developer modifies and tests the change, and finally the change requestor verifies the requirements for the change. The impact analysis of changes generally needs to be carried out by the project team's Development Director. Large projects can be analyzed based on the requirement tracking established in demand management, however, tracking based on actual needs does not play a significant role in impact analysis.

8. Does the requirement need to be documented? What does it mean?

SRS requirement document is the most important document in the entire software development process. Regardless of the project size, personal opinions are related to Requirement documents. This document is the basis for multi-party communication between users, project managers, requirements, design and development personnel, so that everyone can have a consistent understanding of the requirements and carry out the work in accordance with this document. For agile software development, we also need to describe the use case scenario and document CRC cards to facilitate communication.

Once again, we emphasize that communication, especially face-to-face communication, is the most efficient way of information transmission. However, when a piece of information needs to be in different stages of the entire lifecycle of software development, when different roles are used for multiple times, they must be documented. The requirement document exactly belongs to this type.

9. Where do small and medium software development teams focus on demand development and management?

Small and Medium-Sized Project Teams must use lightweight methodologies and processes to achieve the target service. The purpose of the process is to solve the current problems and possible problems. In a process that is not in this scope, rules or work will not produce value and meaning.

For small and medium teams, first of all, they should be aware of the importance of the demand work, formulate the requirement documents and demo interface specifications, and document and structure the requirements. Second, the requirements for development must be reviewed and approved by users, implementers, and testers. Finally, after the requirement is documented, the artifacts need to be managed through various configuration management tools. After the requirement is completed, the artifacts should be archived and controlled in a timely manner. Changes to the requirement must be managed rather than randomly.

10. How to evaluate the priority of a requirement?

The purpose of demand priority is to enhance project management and user satisfaction. After a system is launched, it often occurs that the commonly used functions are concentrated on 20% of the functions, and many functions are rarely used. The demand priority allows us to better grasp the key points and allocate resources, and truly refine the 20% most important requirements and frequently used demands, only in this way can we truly improve user satisfaction and achieve the project goal.

the demand priority usually gives users the most say, but when a system involves multiple business departments and organizational structures, it is inevitable that all users will view the priority and urgency of requirements from their own standpoint. However, the contribution and effect of a demand on efficiency improvement, cost reduction, and cycle reduction are not measured. Therefore, the concept of value engineering should be considered for the evaluation of the demand priority. The priority of a demand should be reflected in the value generated and the cost saved after the demand is realized.