Considerations for it project demand analysis

An error found during the requirements development phase , On average, it only takes 30 Minute repair , If it is found during system test, it is necessary to 5 To 17 Hours to fix . It will cost about more to correct a requirement defect found after the product is put into use than to correct it in the requirement phase 100 Times the cost . Therefore, requirement management is an important part of software project management , Throughout the whole life cycle of project implementation . It is said that ： Everything is difficult at the beginning . Requirements are the first step in software development , Its importance is self-evident . There are many theories and books about demand management on the market , But most of them stay at the theoretical level , Not very practical .

1、 Full communication with users is often , The preparation time before communicating with users is much longer than that of formal meeting and communication . In general , After two hours of talking to you , You lose enthusiasm and patience , That's what most people have in common . So it's very important to prepare well . The preparatory work includes the preparation of getting familiar with the overall environment of the project and the preparation before the investigation of specific business . Familiar with the overall environment of the project needs to understand : The background of the project 、 Purpose of the project 、 Project stakeholders and other information , So as to have a certain understanding of the overall situation of the current project . The preparation work before the specific business research includes : Preparation of demand research questions 、 Design of demand survey template 、 Time arrangement of demand investigation and so on . To fully value the user's time , Try to avoid meeting users repeatedly due to insufficient preparation , Give users the impression of inefficiency . Once such a mistake happens , It may be difficult to meet users later . The core content of requirement acquisition is to master the actual requirements of software projects through investigation , So as to guide the implementation of the whole project . The main methods of requirements acquisition include ： User interviews 、 The questionnaire survey 、 On the spot 、 Brainstorming, etc . During the actual project operation , Relatively clear requirements , We can adopt a relatively fixed demand acquisition method , such as ： Questionnaire survey, etc . And for the relatively vague needs or when users can not clearly express what they need , We can adopt a more flexible way , for example ： User interviews 、 On site observation, etc . The types of requirements mainly include ： Business needs 、 User requirements and functional requirements . In the process of requirements acquisition , Either way , We all need top-down or bottom-up understanding of what users really think . The business requirements are mainly obtained from the top leaders of customers , We all know , Project launch 、 The implementation of 、 The ultimate success or failure depends largely on the senior leadership , We need to interview them , Understand the corporate strategy of senior leaders 、 Direction of development , What is more important is to get their expectation of the software system to be developed , And hope that the system can solve the existing business problems , Expectations for the support of the company's overall strategy . Help us better understand the macro concept of the system . After mastering the business requirements , We need to research middle managers , The core issue is to make clear the level where the macro strategic objectives are implemented , Or the expectations and actual requirements of the middle-level personnel who refine the indicators and are responsible for the implementation of the software system , They may hope that this system will bring convenience to their work , Or hope that this system can achieve fine management , And so on. . But they are all heads of specific business departments , For its own business and the promotion of the system to the business , Have a deep understanding . Last , We need to master the business requirements 、 On the basis of user requirements , Through to IT administrative department 、 Research on the needs of the main operators or according to our understanding of the needs , Refine the functional requirements of the system , This requirement is the lowest level requirement , It is also a process of landing layer by layer .

2、 Actively understand the customer's business and relevant knowledge. We may be very professional in technology , But for the specific user business may not be very clear . Is this project helpful to users 、 Whether a system function is useful 、 Whether a certain process is reasonable , Without understanding the user's business , It will be difficult for us to judge . So only on the basis of understanding the business , We have a common communication language and business understanding with users , In order to really understand what functions the system should have . During the investigation of the dealer management system , Due to limited financial knowledge , In the investigation of the financial department of dealers, some problems are not particularly understood . Ask the user modestly , At the end of the survey, I supplemented my financial knowledge in time . The knowledge in the field of application is boundless , During the investigation of various projects , It is certain that the accuracy of requirement analysis will be affected by the lack of knowledge in a certain field 、 Go ahead smoothly . When you encounter such problems , Requirement analysts should consult users with an open mind , At the same time, we should supplement the knowledge of application field in time . It's better to be well prepared before the research .

3、 Guide users , Enable users to fully express their ideas in conversation with users , How to guide users to express their needs is very critical . Appropriate questions , It will make users talk , Give full expression to your opinions and suggestions . And inappropriate questions , May cause the user to be unable to answer or perfunctorily answer . Questioning can be divided into closed questioning and open questioning . The purpose of closed questioning is clear . Such as : Now is your delivery note filled in manually or printed by computer ? But too much use of closed questions , Can lead to a boring conversation , Make users feel like they're being interrogated . An open question is asking the other person to explain something further , Can make the conversation reach a certain depth and breadth . Such as : What do you think can be improved in your current work ? The disadvantage of open questioning is that it is easy to deviate from the topic . So during the conversation , A combination of closed and open questions should be adopted . Start with a simple question 、 Start with what users are familiar with . Just ask one question at a time 、 Focus on one point , Better ask than guess . And try to avoid using IT Some related terms , So that users can understand our expression well .

4、 The users in the organization are different in many ways , for example : Frequency and degree of use of the system 、 Knowledge of computer systems 、 The business process and personal qualities and preferences . According to the characteristics of users , Users can be classified . Classify users and summarize their characteristics , Describe their personality and task status in detail , It will help to acquire and analyze the requirements . Different questions need to be asked to different people , For operational details , Communicate with the users who are actually responsible for the operation , And when it comes to the big picture , Communicate with the corresponding management users .

5、 Understand the user's workflow and observe the process of the user performing business tasks . Know when users get what data , And how to use this data , Which documents need to be processed during business processing , Which roles of users need to be associated with, etc . This will help to clarify the functional requirements of the product . Experience proves that , There are many limitations and inaccuracies in interviewing people about how they accomplish their tasks , And this is what task observation can solve directly . Especially for the generally accepted rules and methods in some organizations , Users take it for granted that you should know , And when it's not mentioned . After the user requirements have been confirmed , Itemize user requirements , Form each requirement into a requirement development task , With the help of software project management platform , Push it directly to the requirements analyst , The analysis results of requirements analysts can be exported to formatted requirements specifications through this platform . Once the requirements specification writing task is completed , The management platform directly pushes the requirements review task to relevant personnel . Subsequent design 、 code 、 Testing and other tasks are integrated into the process in a similar way .

6、 Analyze the feasibility of demand. We don't do anything that doesn't make money ; Don't do anything that makes money but can't afford to invest ; You can make money and invest money, but there is no reliable candidate , Don't do such a thing . Feasibility analysis is mainly for a certain demand to decide whether to do or not to do . The general feasibility mainly considers two factors : Technology and people . The technical aspect is mainly to analyze whether the required functions can be realized and the quality requirements of products can be met within a given period of time . A lot of times , The user's idea is unrealistic in the actual implementation process . If blindly seeking perfection and blindly following the user's imagination , It will bring great risk to the follow-up work of the project . Therefore, we should try our best to avoid including the function which is difficult to implement in the requirement analysis . In a project I was responsible for , The user requires that the new management system should realize the data interface with the management system , In order to facilitate the data in these systems to guide the new management system . Promise to provide the data interface of the system , It will bring great risk to the successful implementation of the new system . Because it takes time to get familiar with these systems , It also takes time to develop interfaces with them , And there are many different versions of these commercial systems . Therefore, the feasibility of interfacing with external systems is defined as : Is not workable . For complex projects , Economic and environmental considerations should also be taken into account . The economy is mainly from investment 、 earnings 、 short-term 、 Long term interests, etc . In terms of environment, we mainly consider market environment and policy factors . Requirements change to large IT The success or failure of a development project has an important impact , It is not allowed to reject the customer's change request , Nor can we indulge our customers , therefore , Before implementing the requirement change, it must be well controlled . The purpose of requirement change control is not to control the occurrence of changes , It's about managing change , Make sure the changes are in order .

7、 Prioritize requirements when customer expectations are high 、 When the development time is very short and the resources are limited , Setting relative priorities for requirements will help project managers resolve conflicts 、 Arrange periodic delivery and make necessary trade-offs . The importance of establishing each requirement helps to plan the construction of the software , Provide the maximum function of the product at the least cost . Especially for progressive projects , Priority setting is more important , Because in these developments , The project schedule is extremely tight and the delivery date cannot be changed , Some low priority requirements need to be deferred to later versions or cancelled directly . When it is difficult for many users to reach an agreement on the priority setting of certain requirements due to different expectations , The requirements analyst can indicate the cost of each requirement 、 difficulty 、 Technical risks or other specific indicators related to trade-off requirements , To objectively evaluate the priority of each requirement .

8、 It is a tedious and boring job to correctly understand the requirements analysis document and confirm the requirements analysis , Need to discuss with users constantly 、 Confirm and repeat . But most users don't just do it , Especially when he's obsessed with a lot of other things . Sign on the requirement analysis document for confirmation , It is generally considered as a sign of user's agreement with the content of requirement analysis . In practice , The signature confirmation work has not been paid enough attention by users .“ They asked me to sign the requirements document , So I signed , Otherwise, developers don't start coding .” This attitude of users may bring potential risks to the project , Such as constantly changing requirements . For the requirement analysis documents that need to be confirmed by users , It's better to do it before the user confirms , Explain the content of the document to users , To ensure that the user fully understands and approves the content of the document . If the user has modification opinions on the content of the document , Then confirm with the user after modification , Until the user fully approves the content of the document . It's usually a whole project 、 An accurate understanding of , Requirements analysis usually contains more content than the scope of the project .

therefore , Users should understand that the discussion of certain functions does not mean that they will be implemented in the system . The user should understand that the signing of the requirements analysis document is to establish a requirement baseline , Further changes can be made on this baseline through the project defined change process . Requirements validation will put an end to the initial requirements development work by both parties , And it helps to form a continuous and good relationship between users and requirement analysts , Lay a solid foundation for the success of the project . It's not easy to transfer knowledge from one place to another , And the original requirements are usually presented in incomplete form . It may just be in the user's mind of an existing system , Even sometimes users don't realize what they know . At the same time, demand analysts should also strengthen learning in their daily work , Keep summarizing , So that their ability to analyze needs has been continuously improved . Software requirements management is important , This is mainly because the failure of most projects is mainly caused by the inadequate understanding of requirements 、 The change of requirements is not effectively controlled . therefore , This requires us in the software project requirements management , It is necessary to make greater efforts to acquire requirements 、 analysis 、 Change control , Combined with relevant theories of project management , Such as PMBOOK、CMMI etc. , In project practice , Keep learning from experience , Do a good job in demand management .