object-Oriented Software Engineering Practical Software development using uml and Java Chapter 4: developing Requirements www.oseng.com
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 4: Developing Requirements
4. 1 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 www.oseng.com O Lethbridge/Laganiere 2001 Chapter 4: Developing requirements
© Lethbridge/Laganière 2001 Chapter 4: Developing requirements 2 4.1 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
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 www.oseng.com O Lethbridge/Laganiere 2001 Chapter 4: Developing requirements
© Lethbridge/Laganière 2001 Chapter 4: Developing requirements 3 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
4.2 The starting point for software projects Requrements Clents have produced must be detemined requrements ew development A B green field project Eⅴ olution of existing system www.oseng.com O Lethbridge/Laganiere 2001 Chapter 4: Developing requirements 4
© Lethbridge/Laganière 2001 Chapter 4: Developing requirements 4 Requirements must be determined Clients have produced requirements New development Evolution of existing system A B C D 4.2 The Starting Point for Software Projects green field project
4.3 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 www.oseng.com O Lethbridge/Laganiere 2001 Chapter 4: Developing requirements
© Lethbridge/Laganière 2001 Chapter 4: Developing requirements 5 4.3 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
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 Initial list of problems arrowe Scope of with very broad scope scope another sy stem browsing cours room allocation browsing course room allocation < registering exam scheduling egistenng》 exam scheduling fee payment e payment www.oseng.com O Lethbridge/Laganiere 2001 Chapter 4: Developing requirements 6
© Lethbridge/Laganière 2001 Chapter 4: Developing requirements 6 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 Initial list of problems with very broad scope Narrowed scope Scope of another system exam scheduling room allocation fee payment browsing courses registering exam scheduling room allocation fee payment browsing courses registering
4. 4 What is a Requirement Requirement: A statement about the proposed system that all stakeholders agree must be made true in order for the customers 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 customers problem a collection of requirements is a requirements document. www.oseng.com O Lethbridge/Laganiere 2001 Chapter 4: Developing requirements
© Lethbridge/Laganière 2001 Chapter 4: Developing requirements 7 4.4 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
4.5 Types of requirements Functional requirements Describe what the system should do Non-functional requirements Constraints that must be adhered to during development www.oseng.com O Lethbridge/Laganiere 2001 Chapter 4: Developing requirements 8
© Lethbridge/Laganière 2001 Chapter 4: Developing requirements 8 4.5 Types of Requirements Functional requirements • Describe what the system should do Non-functional requirements • Constraints that must be adhered to during development
Functional requirements What inputs the system should accept What outputs the system should produce What data the system should store that other systems might use What computations the system should perform The timing and synchronization of the above www.oseng.com O Lethbridge/Laganiere 2001 Chapter 4: Developing requirements
© Lethbridge/Laganière 2001 Chapter 4: Developing requirements 9 Functional requirements • What inputs the system should accept • What outputs the system should produce • What data the system should store that other systems might use • What computations the system should perform • The timing and synchronization of the above
Non-functional requirements All must be verifiable Three main types 1. Categories reflecting: usability, efficiency, reliability, maintainability and reusability -Response time Throughput R esource usage -Reliability availability -Recovery from failure Allowances for maintainability and enhancement Allowances for reusability www.oseng.com O Lethbridge/Laganiere 2001 Chapter 4: Developing requirements
© Lethbridge/Laganière 2001 Chapter 4: Developing requirements 10 Non-functional requirements All must be verifiable Three main types 1. Categories reflecting: usability, efficiency, reliability, maintainability and reusability —Response time —Throughput —Resource usage —Reliability —Availability —Recovery from failure —Allowances for maintainability and enhancement —Allowances for reusability