Before specific research needs analysis, let's take a look at the concept of software engineering. Software engineering is divided into three levels, process layers, method layers, tool layers. In the most basic process layer, the most important thing is a set of frames called critical process zones (KPA concepts in discussing CMM books). The key process area constitutes the basis of the management control of the software project, and establishes the relationship between the contextual regions, which specifies the use, engineering products, models, documents, data, reports, forms, etc., etc., etc., etc. Establishment, quality assurance and changes in changes. The method layer is mainly the process of technology. It is what the problem is to do. Software engineering methods cover a range of tasks: demand analysis, design, programming, testing, maintenance. At the same time, he also includes a basic principle that controls the key process area of each. The tool layer is well understood, and he provides automatic and semi-automatic support for process layers and method layers. These auxiliary tools are called Case. You can see the location of demand analysis, but in fact, demand analysis is three levels of software engineering. This is the same as the other process. Of course, we have focused on software engineering methods, and also involve some ideas of the process level. As for the tool layer, it is no longer our discussion, but it will mention some suitable for demand analysis. Tools such as Word, Excel, Visio, etc. What is the way to include the analysis? Here is some methods recommended in the "Demand Analysis" book, 1. Draw system-related maps, which is a simple model for defining the boundaries and interfaces between system and system external entities. At the same time, it also clarifies the information flow and material flow through the interface. 2. Create a user interface prototype, develop a user interface prototype when developer or user cannot determine demand - a possible local implementation - thus makes many concepts and possible things more decent. The user will make the project participant to better understand the problems to be solved by evaluating prototypes. Note To find out all the conflicts between demand documents and prototypes. 3. Analysis of demand feasibility, under the permissible cost, performance requirements, analyze the feasibility of each demand implementation, explicitly link the risk of each demand, including conflicts with other needs, dependence and technology for external factors obstacle. 4. Determine the priority level of the demand, apply the analysis method to determine the priority of the use of instances, product features, or single requirements. Determine which features or which type of product will be included based on priority. When the requirements are allowed, each change is added in a particular version and the required changes are made in that version plan. 5. To establish models, the graphical analysis model of the demand is an excellent supplementary description of the software requirements specifications. They provide different information and relationships to help find incorrect, inconsistent, missing and redundant needs. Such models include data flow diagrams, entity relationship diagrams, state transform diagrams, dialog boxes, object classes, and interactions. 6. Create a data dictionary, the data dictionary is defined for all data items and structures for the system to ensure that developers use unified data definitions. In the demand phase, the data dictionary should at least define the customer data item to ensure that the customer and the development team are consistent definitions and terms. Analysis and design tools typically include data dictionary components. 7. Use Quality Function Function, (QFD) is a high-level system technology that links product features and properties to the importance of customers. This technology provides an analysis method to clarify those characteristics that are the most concerned. QFD divides demand into three categories: expectation, that is, the customer may not mention it, but if it is missing, it will make them dissatisfied; ordinary demand; excited demand, that is, it will bring a surprise to customers, but if it is not implemented Will be blamed (zultner 1993; pardee 1996). Remember, don't try to use these methods in your project, four modernization can not be achieved overnight.
Similarly, trying to use what you think is very helpful to you, after receiving the effect, consider the continuation learning method. Because the above mentioned is the big method of demand analysis, there are still many ways to use, for example, using SRS template, indicating the source of demand, to note the mark, record business specification, create demand tracking Ability matrix, review demand document, based on demand, based on the test case, write user manual, and determine qualified standards. Many people in business modeling have not realized what should be done in the business demand phase, and actually modeling is the most important thing. Don't feel that this word is very affectionate, making people don't have the mind. In fact, all people who have done demand analysis have done business modeling, such as your understanding of the operation mode of the company is a business modeling in your mind. But most people have no scientific, systematic, documentation, have done business modeling. The purpose of business modeling is: • Understanding the structure and mechanism of the target organization (will be organized in it). · Understand the current problems currently existing in the target organization and determine the possibility of improvement. · Ensure that customers, end users, and developers reach a consensus on the target organization. · Export the business needs required to support the target organization. The above is not very abstract, in fact, there is nothing to complicate: people and computers are completely different ideas (way of thinking). Therefore, the original suitable business process is not necessarily suitable for the computer, in order to maximize the use of the computer, you must understand the original business process and transform this (process automation), of course, these actions need to be licensed . Some people think that only ERP has the need to reorganize business processes, but in fact, whether it is a department-level MIS system or a social-class e-commerce system, it is necessary to transform business processes, and different The degree of transformation. Business modeling is important to analyze the basic corporate object while analyzing enterprise processes (this word I translate is not good. If you have a better translation, please tell me). Any company has some of the most basic elements, such as banks of CBOs, with accounts, and the CBO of the manufacturing industry has orders. One of my friends in the application for many years have told me a secret. He said that the CBO's CBO is not 4: customers, employees, products and suppliers (bank suppliers should be called peer). All other CBOs have developed on the basis of these four CBOs. For example, customers and products in CBO are multi-to-many relationships. According to the theory of relational data, any multi-many relationships can be split into multiple one-to-one or one-on-one relationship. You can introduce an order class between these two classes, between customers and orders, there is a couple between orders and products, such a multi-to-many relationship is split into two pairs There are many relationships, and the new order class is also produced in a chapter. When the order class is generated, you may also join an associated class: Salesman class. And the salesman is inherited from the employee class. So, the four CBOs of the enterprise can form a lot of CBO operations through different combinations, different relationships.
CBO is the basis of business modeling. On this basis, by evaluating business status, the current business, the business process, improve business process, design business process implementation, improve role and responsibilities, research process automation, development domain model Workflows that are defined in RUP implement the goal of business modeling. Requirement Elicitation is the main body of the demand engineering. For proposed software products, the acquisition requirement is a process that determines and understands the needs and restrictions of different user classes. Getting user needs is located in the middle of the three levels of software requirements. Business needs determine user needs, which describes tasks that users need to be completed. From these tasks, analysts can obtain specific software feature requirements for system activity, which help users perform their tasks. Demand acquisition is the first step in the bridge between the problem and its final solution. An essential result of obtaining the demand is a general understanding of the needs of customers described in the project. Once demand, analysts, developers, and customers can explore multiple solutions to describe these needs. Participating in demand acquisitions can only begin designing systems after they understand the problem, otherwise, any improvements defined by the demand must be reduced. Get demand acquisitions on user tasks - rather than concentrating on user interfaces - help prevent development groups from damage due to problem processing problems. Demand acquisition, analysis, writing demand specifications, and verification do not follow linear order, these activities are spaced apart, increment, and repeated. When you work with our customers, you will ask some questions and get the information they provide (demand acquisition). At the same time, you will handle this information to understand them and divide them into different categories, but also link customer needs as possible software requirements (analysis). You can then make the customer information structure and write a documentation and schematic (description). Next, you can let the customer represent the evaluation document and correct the existing errors (verification). These four processes run through the entire stage of demand analysis. Demand acquisitions may be the most difficult, most important, most error-prone, and most need for communication. Demand acquisition can only succeed with a valid customer - developer's cooperation. Analysts must establish a environment that is thoroughly explored, and these issues are related to the product. In order to facilitate communication, it is necessary to list important groups, rather than imaginary all participants hold the same view. A comprehensive examination of demand issues requires a technology that uses this technology not only considering the functional needs of the problem, but also discusses the non-functional requirements of the project. Determining the user has understood: Discussions for certain functions do not mean that it will be implemented in the product. For the desired needs, you must centralize and set priority to avoid an unlimited project that cannot bring any benefits. Demand acquisition is an activity that needs to be highly collaborative, not a simple 誊 本 本 本 本 的. As a analyst, you must understand their true needs through the surface needs of our customers. Ask an Open-ended problem that helps you better understand the current business process and know how the new system helps or improve their work. To investigate changes that user tasks may encounter, or users need to use other possible ways. Imagine yourself in learning the user's work, what tasks do you need to do? What is your problem? From this perspective to guide the development and utilization of demand. Also, explore the exception: What will hinder the user's smooth completion tasks? Reflection on the system error, how is the user think? When I ask questions, what will happen with "What can I", "When?" "Have you ever thought about", "no one has once" begins. Make a record of each requirement, so track down until a specific customer is discovered. Sometimes, try to ask some "stupid" problems also help customers open the words.
If you ask the customer to write how the business is implemented, the customer's ten eight-nine cannot be completed. But if you try to ask some actual problems, for example: "With my understanding, you will receive the order, will ...". Customers will immediately point out your mistakes, and they will start talking about business, and you are listening carefully. This trick is called "throwing brick jade". At the demand seminar, you must use a laptop, and you have to specify a skilled person to record all the discussion, and record it to make certain finishing. If you don't do this, then you will find that all the discussion is only a fuzzy impression, which is still a distant thing for you. After discussion discussions, you will write down the items (Item) discussed, and participate in the discussion user comments and correct. Early and frequent discussions are a key way for demand to succeed, because people who provide demand can determine if they really get demand. In-depth collection and analysis to eliminate any conflict or inconsistency.
Try to explain the assumptions held by our customers, especially those that have conflicts. Understand the characteristics or feature of the characteristics or characteristics of the customer who have not expressed clearly from the line. GAUSE and Weinberg (1989) propose to use "context-independent issues" - this is a high-level issue that can obtain full information for business issues and possible solutions. Customers answer these questions such as "What is the accuracy of product requirements" or "Can you help me explain why you don't agree with someone's answer?" These answered can know more directly, and this is closed (Close- End) The problem cannot be done. Demand acquisition uses all available sources of information, which describes the problem domain or rational features in a software solution. A study showed that a successful project used more communication methods between developers and customers compared to unsuccessful projects (Kiel and Carmel 1995). Talk with a single customer or potential user group, which is a traditional source of demand for business packages or information management system (MIS). The process of directly hiring users to get the demand is a way to support and buy (Buy-in) for the project. Try to understand the approach of the user to express their needs. Fully study the process of making decisions when performing tasks, and extracts potential logical relationships. Flowcharts and decision trees are a good way to describe these logical decision-making paths. During the demand acquisition, you may find that there is a definition of the project range, not too much is too small. If the range is too large, you will have to collect more requirements than really need to deliver enough business and customer value, at which point the acquisition process will be delayed. If the project range is too small, the customer will propose important but in the current product range. The current range is too small to provide a satisfactory product. The demand will lead to the scope and task of modifying the project, but make such a profound change, be careful. As often said, the demand is mainly about what the system is doing, and how the solution is implemented as the scope of the design. This is said that although it is very simple, it seems too simplified. The acquisition of demand should focus on "what to do", but there is still a certain distance between the analysis and design. You can use hypothesis "how to do" to classify and improve your understanding of users' needs. During the acquisition process of demand, analysis model, screen graphics, and prototypes can make conceptual expression clearer and then provide a way to find errors and omissions. Describe the model and screen effects of your demand development phase as a conceptual recommendation that is convenient and efficient to communicate, and should not be considered as a restriction on the selection of designers. Demand Get Submissions If the participants are too many, the progress will slow down. The number of people is approximately 5 to 7 people. These people include major engineering roles such as customers, system designers, developers and visual designers. Conversely, from the very little representative there or only to hear the sound of the user's highest voice, the most public opinion impact, will also cause problems. This will lead to ignore important needs of a particular user class, or its needs cannot represent the needs of most users. The best trade-off lies in choosing some product representatives who have licensed their user classes, and they are also supported by other representatives of the same group user class. There is no simple, clear signal suggests when you have completed demand acquisition. When customers and developers chat with their colleagues, reading industrial and commercial literature and thinking when they bathe in the morning, they will have new ideas for potential products. You can't fully collect demand, but the following tips will imply that you will return to the point in the process of demand. 1. If the user can't comment out more instances, maybe you have completed the job of collecting needs. The user is always determined by the order of its importance. 2. If the user puts forward new usage instances, you can get these new usage instances from other related functions of other instances. Maybe you have completed the job of collecting needs. These new usage examples may be an optional process of other use instances you have acquired. 3. If the user begins to repeat the previously discussed questions, at this time, maybe you have completed the job of collecting needs.
4. If the new demand filed is low as the priority you have determined, maybe you have completed the job of collecting needs. 5. If the user puts forward the requirements for future products, not now the specific products we discussed, maybe you have completed the job of collecting needs. The above knowledge is roughly discussing how demand analysis should do, in fact, there are many methods for demand analysis, and have formed a certain theory. Of course, this theory is more biased towards and methodology, and the application of methodology is mainly deserved. So, when you actually apply, you may wish to combine your own actual, selective adoption of some methods, then you are successful. The use of examples have been used in demand analysis for many years, and analysts always use plots or experience to describe the interaction of users and software systems to obtain demand (McGraw and Harbison 1997). Ivar Jacobson (1992) describes this view to the use case (use case) method for demand acquisition and modeling. Although the use case is derived from an object-oriented development environment, it can also be applied in a project with many development methods, because the user doesn't care how you develop your software. Most importantly, the viewpoint of the use case and the change of the thinking process are more important than whether or not to draw official use case is more important than drawing. Note that users should use the system to do far from what the user wants the system to do this traditional approach. The important function of the use case is to identify and divide system functions with the functions of the example example. It divides the system into a role (actor) and use case (use case). Role (actor) represents the role (Role) that the system user can play. These users may be people, may be other computers, some of the hardware or even other software systems, and the only standard is that they must be outside the system part of being divided. They must be able to stimulate the system part and receive returns. Use examples describe the activity of the system when the role gives the system specific stimulation. These activities are described by text. It describes the nature of the triggered case, input, and output to other actors, and convert the input to the output. Using an example text usually describes the possible errors and rescue measures that should be taken at a special active line. This may be very complicated, in fact, one example describes the system and a role (actor) interaction order. The use case is defined as a series of actions performed by the system, and the result of the action execution can be perceived by the specified role. Use examples can: • Use example to capture some user visible needs and implement a specific user objective. • Use an example by role activation and provide exact values to the role. • The use case can be large, but it must be a complete description of a specific user objective. In UML, the use case is expressed as an ellipse. The role refers to the role that the user played in the system. Its graphical representation is a small person. There is many role instances (such as many salespersons) in some organizations, but they all play the same role in the system, and they are used in one role. A user can also play a variety of roles. For example, a senior marketing personnel can be both a trade manager or an ordinary marketing personnel; a marketer can also be a salesman. When processing the role, it should be considered, rather than a person or work name, this is important. We use the line segments that do not have arrows to connect the role and the use case, indicate that the exchange information between the two is called communication. Role trigger use case and exchange information with the use case. A single role can be associated with multiple use cases; in turn, a use case can be contacted with multiple characteristics. For the same case, different roles have different roles: they can take values from the examples or participate in the use case. It should be noted that the role is represented in the example of the example, despite the execution, but the role is not necessarily a person.
For example, the role can also be an external system, which may need to obtain information from the current system, interact with the current system. A use case may include many logical related tasks and interactions that complete a task. Thus, a use case is a collection of related usage descriptions, and an explanation is an example of the use case. This relationship is like the relationship between classes and objects. In the use case, an explanation is considered an event (Normal Course), also called the main process, the basic process, ordinary stream, or "Happy Path). The order of the executter and the system is interacting or conversation between the executor and the system when describing the normal process. When this interaction ends, the executor has also achieved the expected purpose. Other descriptions in the use case can be described as an optional process. Optional procedures can also facilitate successful completion tasks, but they represent details of the task or the change in the way to complete the task. In the interaction sequence, the normal process can be decomposed into an optional process on some decision points, and then reroute a general process. Role and Role Example Software Products are ultimately used for some users, and the difference between users is very large. The reason for the difference includes different degrees of cognition of the computer, the use habits, different positions in the software target tissue, different geographic locations, and different business proficiency. Different users have their own series of functional requirements and non-functional needs. People with different degrees of proficiency in computers may have different requirements. Users with low proficiency may wish to have a friendly interface. Users with high proficiency may more want to have shortcuts or macros to improve work efficiency. It is necessary to consider the behavior of the user, classify and study user classes. Therefore, before doing specific needs, classify user branch behavior and characteristics, for research, collecting users' demand is very helpful. You can use a simple table to list some of the original categories and then constantly improve this form. Confirm that there is no intersection between your classification. And fully describe the behavior, purpose, requirements, etc. of the user classification. In business analysis, common classifications may include, suppliers, customers, departments, etc. Just like classes in C and objects, we are called "role classes", refer to actual users as "role instances". After getting the user classification, the most important thing is to select the user representative, the user representative is not only in the demand phase, but also responsible for the entire process of the project. The user represents the needs of the user's classification. Seizing the needs of the user representatives will roughly hold the needs of the user. Of course, demand analysis still needs to be a large-scale survey in the user, just put the focus on the user representative. Make sure you communicate directly with your users! Do you have a game that has been playing a message, it may be seen. A group of people are arranged in a row, and one sentence is passed from the row, until the end, the sentence is already unrecognizable. So, be sure to ensure that the project team can contact the user directly. For direct communication with users, the general application system for specific enterprises is of course not a problem, but if it is a development industry software, and users directly communicate becomes almost impossible. In this case, there are generally several solutions: to do a large-scale market survey, making a market survey for your target market, and establish your mathematical model according to statistical theory. This part of the work effect is the best, and its nature is like some game companies will post some DEMO version of the game. However, for a general company, this work is expensive and high cost is often refundable. My opinion is that the method is very good, but you can use a compromised approach, such as a representative business, making a smaller version for specific enterprises and collect feedback.
This involves many marketing content, not my profession, not much ax there.
Industrial experts, an industry expert can often play an extremely important role in project demand. A industry expert often has a large number of industry experience and industry interpersonal relationships. In terms of product design, this industry expert offers a lot of valuable comments. This approach is used in the development of a lot of software. There are two kinds of industry experts: one is a deep qualification in this industry, but it is not familiar with software technology; the second is software specialists who have developed similar software. This kind of person has accumulated in the development of similar software. A large number of project experience and has software development knowledge. This approach is the best way to get demand. Analyze comparison with the same software, Microsoft is developing Office, Visual Studio, is also a mature product of Lotus and Borland. This method is characterized in that the cost is low, and it is more suitable for use in other ways. However, pay attention to yourself has no patent law. Some of the conflict of demand, although users have classified and selected by users. But there are many sources of demand, often there is a contradiction between demand. After the demand is collected from all directions, people are difficult to resolve conflicts, clarify the blurring, and the coordination is inconsistent. Some people have to make decisions separately from the range issues to occur. In the early stage of the project, you must decide who is the decision maker of the demand problem. If you don't know anyone who has the right and responsible to make decisions, or authorized individuals don't want to or can not make decisions, the role of decision makers will naturally be on the developer. This is a very bad choice because developers usually do not have enough information and opinions to make a business decision. In the software project, who will have a uniform answer to the problem of demand for decision-making. Analysts sometimes listen to the greatest demand from the voices or from the highest layers. Even if the user represents this means, you must solve the needs of conflicts from different user classes. Usually, decisions should be made as much as possible in the company's underlying, as they are closely related to the problem and can get extensive information on these issues. If different user classes have inconsistent needs, it is necessary to decision to meet which user needs more important. Understanding the information that may use the customer's type of information and their usage and product business goals will help you decide which user class has the greatest share. When the developer's imagination conflicts with the customer's demand, it is usually made by the customer. However, do not get in the trap of "customers always", to them. In reality, customers are not always right. Customers always hold their own perspectives, developers must understand and respect this view. During the specific demand process, there is a large use case (business case), there is also a small use case. Mainly due to the scope of the use case. The use case is like a black box, which does not include any and some information related or internal. It is easy to be understood by the user (also including developers) (simple predicate phrases). If the use case is not enough to express enough information to support the development of the system, it is necessary to open the use case black box to examine the internal structure, find the actor and use case inside the black box. In this way, through the continuous open black box, analyze the black box, open the new black box. Until the entire system can be clearly understood. Why use this analysis method? In addition to a series of interactions with an external system, there is a series of interactions in the system, there is often a complex interaction. Therefore, in the system modeling, in addition to describing the interaction of the system and the outside, the interaction inside the system is also described. In traditional MIS systems, there are many interactions with the outside world. Typical, such as ATM cash machines: There are a large number of users interact with ATM, ATM and other systems. The system in telecommunications is less interaction with the outside world. For example, the input of the system may be just acquired from the switch and then processed by the system.
The complex logic of the system is included on the process of processing internal processing, not interact with the external system. The main task of modeling is to express interactions inside the system. Use an example to suit the expression interaction, which uses the telecommunications system above because the use case comes earlier from the Ericsson switch system. At that time, Jacobson, or Ericsson, Jacobson, prelimated the concept of the example map, and proposed OOSE methods in 1994, the maximum feature is a use-case, and the concept of external role is introduced in the description of the use case. The concept of use case is an important weapon for accurate description, compares to support business engineering and demand analysis. With the development of the use case, the use case is a large number of descriptions for functions. Each use example represents the interaction of the system and external Actor. The sequence diagram can be taken to express the specific operation procedure of the use case. Actor is used to determine the boundary of the system. Actor, the use case can be described from different levels. The reasons for adopting this principle are: 1. Demand is not clear in the beginning of the project, often with the advancement of the project, gradually refined. 2. The awareness of people often has hierarchical features. From rough to fine, from general to special. Different levels are used to describe the process suitable for cognitive. Using the general process of the use case development system In the initial stage of the development process, the principle of association between various views can be developed and guided according to the specific project characteristics. During development, the organizational principles of the view should be maintained and updated. Identify the actor to identify an entity that interacts with the outside world. Actor has features of specific areas, such as switches (acquisition systems), 97 information systems, and the like. The Actor hierarchically determines the boundary of the system. Identification use case. Like the Actor, the use case has different levels. For more detailed uses, it needs to be refined. Note: The system development requires certain rules to determine, how to break down the use case; may be based on the original system experience, or refer to existing information. When used in detail to the hierarchy that can be understood. It is necessary to carry out the development of the next step based on the case. As mentioned earlier, the use case is mainly used to describe interaction. Therefore, there is an entity and interaction details of an interactive entity. The entity of the interaction uses a class diagram to describe the details of the interaction, and the sequence diagram is described. Class diagrams and sequence diagrams may not be sufficient to describe their complexity when the system is complex to a certain level. In this case, a state diagram is required to assist in explaining. The status map and sequential diagrams are used to join together. The consistency between them, current UML and ROSE have no solutions. The relatively compromised method is to use the naming specification for the event. It can be said that all things mentioned above are to be able to export the use case in the needs. The use case is to look at the system from the user's perspective, not based on programmers. In this way, the use case drive-driven system can truly use the user-centered, any needs of the user can be completely reflected in the system development chain. Users and programmers to communicate with examples to avoid the embarrassing situation of the cattle horses. Once, system developers always acquire demand through plots, asking users to do what they do for him. After Jacobson invented the concept of the use case, the demand acquisition becomes asking if the user needs to use the system. This is the result of the standpoints. Users often don't care about how the system is implemented (there are also a few cute techniques to be exceptional). For them, more important is to achieve his purpose. Conversely, most of the programmers' work habits are how to consider how the computer implements the user's request. Fortunately, the use case method can be adjusted to the contradiction between the two sides, because although the use case is derived from the user, it serves the user, but it can also be used to develop. When the development process of the system is based on the usual case, use case acquisition requirements, use case design, use case code, use case test. This development process is driven by example.
