How to analyze the needs of software projects ....

Requirement Analysis
Before analyzing specific research requirements, let's take a look at the concept of software engineering. Software Engineering is divided into three layers: Process Layer, method layer, and tool layer. At the most basic process layer, the most important thing is a set of frameworks called key process areas (kpas) (the concept of kPa is described in detail in the document on CMM ). The key process area forms the basis of software project management and control, and establishes the relationship between the context areas, which specifies the adoption of technical methods and engineering products, models, documents, data, reports, tables, etc. Creation of milestones, quality assurance, and appropriate management of changes. The method layer mainly implements the process technically. It solves the problem. Software Engineering Methods cover a series of tasks: requirement analysis, design, programming, testing, and maintenance. At the same time, he also includes a set of basic principles that control every key process area. The tool layer provides automatic and semi-automatic support for the process layer and method layer. These auxiliary tools are called case.
We can see the location of demand analysis, but in fact demand analysis spans three layers of software engineering. This is the same as other processes. Of course, what we emphasize here is that the method layer of software engineering also involves some process layer ideas. As for the tool layer, we will not discuss it any more, however, we will mention some tools that are suitable for application in demand analysis, such as Word, Excel, and Visio.
Method
What methods are involved in requirement analysis? Here are some of the methods recommended in demand analysis,
1) Draw a system Association diagram, which is a simple model used to define the boundaries and interfaces between the system and external entities of the system. It also clarifies information flows and material flows through interfaces.
2) create a user interface prototype. When the developer or user cannot determine the requirement, develop a user interface prototype-a possible local implementation-to make many concepts and possible things more intuitive and clear. By evaluating the prototype, the user can help the project participants better understand each other's problems. Be sure to find out all the conflicts between the requirement document and the prototype.
3) analyze the feasibility of each requirement, analyze the feasibility of implementation of each requirement with the cost and performance requirements, and clarify the risks associated with the implementation of each requirement, this includes conflicts with other needs, reliance on external factors, and technical barriers. 4) determine the priority level of the requirement, and apply the analysis method to determine the priority level for the use of instances, product features or individual requirements. Determine the features or requirements of the product version based on the priority. When a demand change is allowed, add each change to a specific version and make the required change in that version plan.
5) establish a model for the requirement. The graphic analysis model of the requirement is an excellent supplementary description of the Software Requirement Specification. They provide different information and relationships to help locate incorrect, inconsistent, missing, and redundant requirements. Such a model includes a data flow diagram, an object diagram, a State Transformation Diagram, a dialog box diagram, an object class diagram, and an interaction diagram.
6) create a data dictionary that defines all data items and structures used by the system to ensure that developers use a unified data definition. In the demand phase, data dictionaries should at least define customer data items to ensure that customers and development teams use consistent definitions and terms. Analysis and design tools usually include data dictionary components.
7) quality feature allocation (QFD) is an advanced system technology that associates product features and attributes with the importance to customers. This technology provides an analytical method to identify the characteristics that are most important to customers. QFD classifies requirements into three types: Expectation requirements, that is, the customer may not mention them, but they will be dissatisfied with the lack of requirements; general requirements; exciting demands, that is, the realization will bring surprises to the customer, however, if it is not implemented, it will not be blamed (zul1_1993; Pardee 1996 ).
Remember, don't try to use these methods in your project. Four Modernization tasks won't be implemented overnight. Similarly, try to use methods that you think are very helpful to you. After you have received the results, consider continuing to learn the methods. Because all of the above mentioned are big methods of demand analysis, there are actually a lot of methods to use, for example, use SRS templates, specify the source of requirements, Add labels for each requirement, record business specifications, create a requirement tracking capability matrix, review requirement documents, write test cases based on requirements, and write user Manual and qualified criteria.
Business Modeling
Many people do not realize what to do in the business demand phase. In fact, business modeling is the most important thing. Do not think that business modeling is profound and confusing. In fact, all the people who have done requirement analysis have done business modeling. For example, if you understand the enterprise's operation model? Is a business modeling in your mind. However, most people do not have scientific, systematic, and documented business modeling.
The purpose of business modeling is:
Understand the structure and mechanism of the target organization (the organization in which the system will be deployed.
Understand the current problems in the target organization and determine the possibility of improvement.
Ensure that customers, end users, and developers reach consensus on the target organization.
Export the business requirements required by the target organization.
Isn't the above Abstract? In fact, there is nothing complicated: People and computers are totally different ideas (ways of thinking ). Therefore, the originally appropriate business process may not be appropriate for computers. In order to maximize the use of computers, you must understand the original business process and make it easy to transform (Process Automation). Of course, these actions need to be approved by the user. Some people think that only ERP systems need to restructure business processes. However, whether it is a department-level MIS system or a social-Level E-commerce system, all of them need to transform the business process. what is different is the degree of transformation.
Business modeling is very important when analyzing enterprise processes and analyzing basic business objects. If you have better translation, please tell me ). Any enterprise has some basic elements, such as the Bank's CBO account and the CBO in the manufacturing industry. One time a friend of mine who has been studying enterprise applications for many years told me a secret, he said, the company's CBO is nothing more than four: customers, employees, products, and suppliers (bank suppliers should be referred to as peers ). All other CBO have been developed on the basis of the four CBO. For example, in CBO, the relationship between customers and products is many-to-many. According to the theory of relational data, any many-to-many relationship can be split into multiple one-to-many or one-to-one relationships. You can introduce the order class between the two categories. There is one-to-many between the customer and the order, and there is one-to-many between the order and the product, in this way, a multi-to-many relationship is split into two one-to-many relationships, and the new order class is produced in turn. When the order class is generated, you may also add an associated class: salesman class. The salesman class inherits from the employee class. Therefore, the four CBO types of enterprises can form a large number of CBO operations through different combinations and relationships.
CBO is the basis for business modeling. Based on this, it evaluates the business status, describes the current business, determines the business process, improves the definition of the business process, designs the Business Process implementation, and improves roles and responsibilities, research Process Automation, development of domain models, and a series of workflow defined in RUP to achieve the goal of business modeling.
Requirement acquisition
Requirement elicitation is the subject of the requirement project. For recommended software products, obtaining requirements is a process of determining and understanding the needs and limitations of different user classes. Obtain the intermediate layer of user requirements at three levels of software requirements. Business Requirements determine user requirements. They describe the tasks that users need to complete by using the system. From these tasks, analysts can obtain specific software functional requirements used to describe system activities that help users execute their tasks. Requirement acquisition is the first step to build a bridge between the problem and its final solution. An essential result for obtaining a requirement is a general understanding of the customer requirements described in the project. Once you understand the requirements, analysts, developers, and customers can explore a variety of solutions that describe these needs. Participants can only design the system after they understand the problem. Otherwise, any improvements to the requirement definition must be reworked in a large amount. Focusing requirement acquisition on user tasks rather than user interfaces helps prevent development teams from making mistakes due to hasty design issues. Requirement acquisition, analysis, Writing Requirement Specification descriptions and verification do not follow a linear sequence. These activities are separated, incremental, and repeated. When you work with the customer, you will ask some questions and obtain the information they provide (the requirement is obtained ). At the same time, you will process the information to understand them, divide them into different categories, and link customer requirements with possible software requirements (analysis ). Then, you can structure the customer information and write it into documents and descriptions ). Next, let the customer representative review the document and correct the existing errors (verification ). These four processes run through the entire demand analysis phase. Requirement acquisition may be the most difficult, critical, error-prone, and communication required in software development. Requirement acquisition can be successful only through cooperation between valid customers and developers. Analysts must establish an environment for thorough discussion of problems, which are related to products. To facilitate clear communication, it is necessary to list important groups, rather than imagining that all participants share the same view. A comprehensive investigation of the demand issue requires a technology that not only considers the functional requirements of the problem, but also discusses the non-functional requirements of the project. Confirm that the user understands that the discussion of some features does not mean that it will be implemented in the product soon. Must we focus on the expected needs and set the priority ?, To avoid an infinitely large project that cannot bring any benefits. Demand acquisition is a highly cooperative activity, not a simple release of the customer's requirements. As an analyst, you must understand the real needs of the customer based on the customer's surface requirements. Asking an extensible question helps you better understand your current business processes and understand how new systems help or improve their work. Investigate possible changes to user tasks, or use other possible methods of the system. Imagine that you are learning about your work. What task do you need to accomplish? What's your problem? From this perspective, we can guide the development and utilization of requirements.
Also, explore exceptions: what will prevent users from successfully completing tasks? What do users think about the reflection of system errors? When asking questions, what else can I do? "Have you ever thought about" and "Have you ever been" Start. Write down the source of each requirement so that you can trace down until you find a specific customer.
Sometimes, it is helpful for customers to open up their phone when they try to ask "stupid" questions. If you directly ask the customer to write out how the business is implemented, the customer will not be able to complete it in any case. But if you try to ask some practical questions, for example, "In my understanding, after you receive the order, you will ...". The customer will immediately point out your mistakes and start talking about the business. You should listen carefully. This trick is called "throwing a brick and mortar ".
At the Demand seminar, you must use a laptop and specify a skilled person to record all the discussions. At the same time, you must record them. If you do not do this, you will find that there is only a vague impression of all the discussions, and demand is still a distant thing for you. After the discussion, write down the items discussed and ask the users involved in the discussion to comment and correct them. Early and frequent discussions are a key way to succeed in obtaining a requirement, because only those who provide the requirement can determine whether to actually obtain the requirement. Perform in-depth collection and analysis to eliminate any conflicts or inconsistencies.
Try to clarify the customer's assumptions, especially those that conflict with each other. Understand between lines to identify the characteristics or features that the customer does not clearly express but wants to add. Gause and weberger (1989) propose to use "context-independent problems"-this is a high-level problem that can obtain all information about business problems and possible solutions. The customer's answers to these questions, such as "How accurate the product requires" or "Can you help me explain why you disagree with someone's answers ?" These answers give you a more direct understanding of the problem, which cannot be achieved by the close-end question.
Demand retrieval utilizes all available information sources that describe the problem domain or the rational features in the software solution. A study shows that a successful project uses more communication methods (Kiel and Carmel 1995) between developers and customers than unsuccessful projects ). Discussing with a single customer or potential user group is a traditional source of demand for business software packages or Information Management System (MIS) applications. The process of directly hiring a user to obtain the requirement is a way to get support and buy (buy-in) for the project.
Try to understand the thinking process that users use to express their needs. Fully study the process of making decisions when users execute tasks and extract potential logical relationships. Flowcharts and decision trees are good methods to describe these logical decision paths.
During requirement acquisition, you may find that there is an error in the definition of the project scope, either too large or too small. If the range is too large, you need to collect more requirements than you really need to deliver enough business and Customer values. At this time, the acquisition process will be delayed. If the project scope is too small, the customer will propose important but out-of-scope requirements. The current range is too small to provide a satisfactory product. Obtaining the requirement will lead to modifying the scope and task of the project, but be careful when making such a far-reaching change. As is often said, the requirement is mainly about what the system is doing, and how the solution is implemented is within the scope of the design. This is concise, but it seems too simple. Demand acquisition should focus on "what to do", but there is still a certain distance between analysis and design. You can use the assumption "How to do" to classify and improve your understanding of user needs. In the process of obtaining requirements, the analysis model, screen graphics, and prototype can make the concept table clearer, and then provide a way to find errors and omissions. Consider the model and screen effect you have created in the demand development stage as a conceptual proposal for convenient and efficient communication, rather than a limitation on the designer's choice. Too many participants in the demand acquisition seminar will slow down the process. It is best to roughly control the number of people between 5 and 7. These people include customers, system designers, developers, visual designers, and other major engineering roles. On the contrary, collecting information from very few representatives or hearing only the voices of users with the highest voices and the most influential opinions can also cause problems. This will lead to ignoring the important requirements of a specific user class, or its requirements cannot represent the needs of the vast majority of users. Most? The good balance lies in selecting product representatives authorized to speak for their users. They are also supported by other representatives of the same group of users. There is no simple and clear signal indicating when you have obtained the requirement. When customers and developers chat with their colleagues, Read industry and commercial literature, and think during morning bath, they will all create new ideas for potential products. You cannot fully collect requirements, but the following prompts will imply that you return points during the request acquisition process.
1. If you cannot come up with more instances, you may have completed the collection requirement. The user always determines the use of the instance in the order of its importance.
2. If the user proposes a new instance, but you can obtain the new instance from other functional requirements related to the instance, then you may have completed the collection requirement. These new instances may be optional for other instances you have obtained. 3. If you start to repeat the previously discussed issues, you may have finished collecting requirements.
4. If the new requirements are lower than the ones you have determined, you may have collected the requirements.
5. If the user asks for future products, rather than the specific products we discuss now, you may have finished collecting requirements.
The above knowledge roughly discusses how to do the demand analysis. In fact, there are many methods for the demand analysis, and some theories have been formed. Of course, this theory is more biased and methodological, the Application of methodology mainly depends on the individual. Therefore, when you use it in practice, you may wish to use some methods selectively based on your actual situation, so that you are successful.