We know, a project, if you are from the development side (ie, the contractor) and the user (ie, the construction party), it can be roughly divided into the following four: developer and user know the project needs, The developer is unclear that the project needs but the user is clear, the developer and the subscriber are unclear, and the development side knows the project needs but the user is unclear.
In response to these four types of projects, I summarize four corresponding needs acquisition methods: questionnaire survey, conference discussion, interface prototype law and can operate the prototype system method.
The following is parsed one by one.
First, questionnaire survey
The so-called "Questionnaire Research Law" means that the development side needs further clear demand (or issues) on the needs of user needs, and achieves a thorough understanding of project needs by adopting a questionnaire to the user. Market demand acquisition method.
This approach is suitable for the developer and user parties to clear the needs of the project. Because developer and construction party know the demand of the project, it is necessary to further communicate with the needs of the two parties (or problems), and the problem can be better solved by using this simple questionnaire survey method.
The general operating step of this method is:
Step 1, the developer first, according to the experience of the contract and the previous similar project, organize the "Questionnaire Survey Form" submitted to the "User Demand Manual" and the demand (or problem);
Step 2, the user reads the "User Demand Manual" and answers the question raised in the Questionnaire Survey, if the "User Demand Manual" is incorrect or not included, the user can modify or supplement;
Step. Third, the developer gets the "User Demand Manual" and "Questionnaire Survet Table" returned by the user. If there is still a problem, repeat steps two, otherwise step four;
Step 4, the developer organizes the "User Demand Manual" and submits to the user to confirm the signature.
Since this method is relatively simple, the focus is clear, so it can greatly reduce the time of demand acquisition, reduce the cost of demand acquisition, and submit productivity.
Second, the meeting discussion method
The so-called "conference discussion" refers to a demand acquisition method that developer and users convene a number of demand discussions to meet the needs of project needs.
This method is suitable for the developer's unclear project requirements (the general development side is the project project that is just the type of business) but the user knows the needs of the project. Because users know the demand of the project, users can accurately express their needs, and the developer has professional software development experience, which is generally accurately described and grasped for users.
The general operating step of this method is:
Step 1, the developer's "demand research scheme" established by the two parties will convene relevant needs theme communication;
Step II. After the meeting, the developer organizes the "Demand Research Record" to the user to confirm;
Step 3, if there is no clear problem in this topic, it will be communicated again, otherwise the next topic will be started;
Step 4, after all the needs are communicated, the developer is submitted to the user party to confirm the signature based on the "Demand Research Record" in the last "demand research record".
Due to the unclear project needs, it takes more time and energy to invest more time and energy to conduct demand and demand finishing work.
Third, interface prototype
The so-called "interface prototype" refers to the development partner to communicate and communicate with the user after the function interface of the application system, through the "interface prototype", and reach the project demand. A method for demand acquisition.
This method is more suitable for the developer and the user unclear item demand. Because developer and users do not know the project needs, at this time, it is more necessary to accelerate the excavation of demand and the demand for demand by means of a certain "carrier". In this case, it is preferred to use "visualization" interface prototyping.
The general operating step of this method is:
Step 1, the developer uses the functional interface of the application system based on the needs of the application (such as through the contract or communication with the user); Step II, submit the function interface of the application system to the user and communicate with the user , Excavate new needs or agree on demand;
Step 3, the developer will increase the incremental integration of the continuous acquisition, rich in new demand and refine the main type;
Step four, the two sides have passed the interaction of the main type of interface, and the developer finally sorted out the "User Demand Manual" and submitted to the user to confirm the signature.
Since the developer and the user do not know the project needs, the demand acquisition work will be more difficult, and the risk that may result in is relatively large. This "interface prototype" is used to accelerate the "emergence" and both parties to demand for the demand, thereby reducing the risk of demand may give the project.
For this type of project, we can also use the "Rightful Prototype System Law" that will be introduced below, but due to the development of demand (prove the development experience and product accumulation of similar projects before), if it is developed The prototype system, almost need to write code from scratch, and the previous investment will be large.
Fourth, the prototype system method can be operated
The so-called "operational prototype system law" means that the development side has a small number of modifications to a small number of modifications to the previous similar project application system according to the contract, and can operate the vector. , A method of thorough excavating the demand for project requirements.
This method is more suitable for the development side to clear the project requirements but the user is unclear. This type of project, developer generally has a similar project's construction experience, so it can quickly "build" on the basis of the previous project, and then use this "carrier" to speed up the excavation of requirements. And between the two sides (especially the user). In this case, it is preferred to operate the operating prototype system method using "see".
The general operating step of this method is:
Step 1, the developer quickly "constructs" out a running system on the basis of the previous similar items based on the needs (such as through contract or communication with users);
Step 2, by demonstrating "running prototype systems" to the user, gradually dig and allow users to confirm the project requirements;
Step 3, the development partner is increasingly organized by increasing demand, and rich in the new demand;
Step four, the two sides have been running the interaction of prototype systems, and the development party finally sorted out the "User Demand Manual" and submitted to the user to confirm the signature.
Due to the development of the user's needs (proven to have similar project development experience and product accumulation), the user is unclear, so I develop a "running prototype system", the development side's investment will not be large, but It is very advantageous for user understanding and confirmation project requirements, so projects for this type of projects are a more ideal demand acquisition.
Another benefit of this method is that official systems can generally evolve on the "canable prototype system", saving a lot of work and costs for subsequent development efforts.
It is worth noting that these four demand acquisition methods that have been summarized above are not mutually exclusive, and we can apply or combine applications based on the actual features of the project.
"Busy, does not represent efficiency; method, far better". I hope that our friends developed by software projects can master the right way, and they can get the effect of "halving".
