tailieunhanh - Lecture Object-oriented software engineering: Chapter 4 - Timothy Lethbridge, Robert Laganiere

In the previous two chapters, you learned about technologies that software engineers need to master before developing applications. Now, we can start thinking about the particular problem we wish to solve. We will first put effort into understanding the background of the problem, a process called domain analysis. Then we will look at the information you have to gather so that you can describe the problem and its proposed solution. Finally, we will discuss some techniques for gathering and analyzing that information. | Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 4: Developing Requirements Domain Analysis The process by which a software engineer learns about the domain to better understand the problem: The domain is the general field of business or technology in which the clients will use the software A domain expert is a person who has a deep knowledge of the domain Benefits of performing domain analysis: Faster development Better system Anticipation of extensions © Lethbridge/Laganière 2001 Domain Analysis document A. Introduction B. Glossary C. General knowledge about the domain D. Customers and users E. The environment F. Tasks and procedures currently performed G. Competing software H. Similarities to other domains © Lethbridge/Laganière 2001 The Starting Point for Software Projects green field project © Lethbridge/Laganière 2001 Defining the Problem and the Scope A problem can be expressed as: A difficulty the users or . | Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 4: Developing Requirements Domain Analysis The process by which a software engineer learns about the domain to better understand the problem: The domain is the general field of business or technology in which the clients will use the software A domain expert is a person who has a deep knowledge of the domain Benefits of performing domain analysis: Faster development Better system Anticipation of extensions © Lethbridge/Laganière 2001 Domain Analysis document A. Introduction B. Glossary C. General knowledge about the domain D. Customers and users E. The environment F. Tasks and procedures currently performed G. Competing software H. Similarities to other domains © Lethbridge/Laganière 2001 The Starting Point for Software Projects green field project © Lethbridge/Laganière 2001 Defining the Problem and the Scope A problem can be expressed as: A difficulty the users or customers are facing, Or as an opportunity that will result in some benefit such as improved productivity or sales. The solution to the problem normally will entail developing software A good problem statement is short and succinct © Lethbridge/Laganière 2001 Defining the Scope Narrow the scope by defining a more precise problem List all the things you might imagine the system doing Exclude some of these things if too broad Determine high-level goals if too narrow Example: A university registration system © Lethbridge/Laganière 2001 What is a Requirement Requirement: A statement about the proposed system that all stakeholders agree must be made true in order for the customer’s problem to be adequately solved. Short and concise piece of information Says something about the system All the stakeholders have agreed that it is valid It helps solve the customer’s problem A collection of requirements is a requirements document. © Lethbridge/Laganière 2001 Types of .