Mastering the demand process (i)

The demand process focuses on the products that are submitted, and we need to get these products to create a testable and traceable requirements specification. These submissions provide an early measure of the management project. We can tailor the process of collecting, extracting, writing, and inspecting requirements so that these processes can be tailored to the technical and cultural environment. Requirements templates and requirements Framework are examples of submissions that we can tailor to our environment and terminology. The general process provides the key to understanding the concept of requirements.

Project initiation is a sudden activity that collects all the information needed to get our project started and identifies the project as viable and well funded. The start-up phase determines the product to be part of the work and determines the exact target to be achieved. Other products provided during the start-up phase are useful for qualifying the product range and will be used as input for subsequent requirements collection activities. The product of the start-up phase provides a basis for the products: The purpose of the product-a brief, measurable statement of the business objectives that the product should meet; the customer-the product is built for, and the customer-who will buy the product for the commercial product, the stakeholder-who has acquired the benefit in the product; --who will operate the product, what their capabilities are, constraints--whether some design must be adopted, how much time and money is available for the project solution, what terminology the project uses, the facts and assumptions that everyone needs to know, the scope of the work--what is the boundaries of the product and the project? ; estimated costs – how much work or money is required to achieve the product; Risk – A brief risk analysis that exposes the major risks to the project, which is put together to provide sufficient information to obtain the final product of the start-up phase, the decision to continue or terminate-whether the project is feasible, Consider getting the cost of the project, whether it is worth it!

By introducing the idea of business events, we can reasonably cut out part of the work for further modeling and research. By understanding the impact of each adjacent system on the work, we understand the limitations of the product range. By modeling work behavior, we get the scope. We do not assume that there will be a user and a computer, or we can get this result by considering the existing technology. By using business events to split the work, we have a guiding approach to discovering all the work pieces. These parts of the work are in the same business for a combination of reasons. Event-driven use cases are part of an incident response (activity and data). These event responses should be performed by the product. Participants are singled out to interact with situations, largely based on their expectations of that part of the job. The use of conditions became the "fault" of demand. In other words, we study each use case and determine their needs. By decomposing the system into these small, convenient units, we can understand the real work expected of the product, and we can build a truly relevant and useful product.

Any inappropriate requirements caught in the net will be filtered by quality. So, if you find something unrelated in the snare, don't worry too much about it. Quality clearance will reduce the quantity of demand, only what is most appropriate to keep. At this stage you should be aware of all the needs and don't miss out on any needs. In practice, this means that it's always better to collect too much demand than to collect too little. Listening is the most important requirement gathering skill.

Functional requirements indicate what the product must do. To achieve the root cause of existence, the product must perform a number of actions, functional requirements related to these actions. They should be able to form a complete product function description that avoids ambiguity as much as possible. The easiest way to do this is to write a scenario that breaks down the condition into a series of steps, examines each step, and exports its functional requirements.

Non-functional requirements are attributes that a product must have. Non-functional requirements do not change the functionality of the product. Non-functional requirements add functionality to the product-he adds some processing to make the product more user-friendly, more secure, or more interactive.

Writing a requirement specification refers to the task of getting a complete description of the product to be built. This is not a separate activity, but rather a part of the task of writing requirements when the requirements are discovered, in the activities of snares and prototypes: in quality, ensuring that every requirement is complete while the rest of the web is completed. Writing a good requirements specification can be rewarded in several times--more accurate construction, less cost of maintenance, and a product that responds to customer needs and ideas.

Mastering the demand process (i)