Một khi bạn có một danh sách đồng ý của các bên liên quan, bạn cần phải đánh giá tính chất và quy mô của nhiệm vụ thu thập yêu cầu. Sau đó, bạn cần phải lựa chọn kỹ thuật thích hợp để thu thập các yêu cầu từ các nguồn mà bạn đã xác định. | Writing Better Requirement 19 Chapter 3 Gathering requirements from stakeholders Once you have an agreed list of stakeholders you need to assess the nature and scale of the requirements-gathering task. Then you need to select appropriate techniques for gathering the requirements from the sources you have identified. In this chapter we focus on how to get requirements directly from stakeholders whether through interviews or workshops. In the next chapter we examine a wide range of other possible sources of requirements and consider some of the pitfalls in extracting requirements from documents. Possible techniques Ultimately requirements express human needs. A business finds that its customers and internal users start to send in problem reports about an existing product complain about how difficult and slow some process is or change a device or a piece of software to work the way they want. Users may not be able to imagine a new system or how they would use it but they know what their problem is and why they would like it fixed. They are the experts in their own problem. You need a range of techniques to get the requirements for their project. Techniques for capturing requirements include interviewing users and other stakeholders holding workshops observing users at work searching likely documents and seeing the changes that users have made to existing systems. Problem reports and suggestions from existing systems can be valuable sources of requirements provided you find out and record how important each proposed requirement is to its users. New technologies suggest opportunities rather than requirements as such but the pressure of competition can quickly turn a possible new approach into a definite business requirement - when the technologies appear in rival products for instance. Sources of requirements interviews Workshops Experiencing life as a user Observing users at work Acting out what needs to happen Prototypes Problem reports Helpdesk and support team .
