Download Understanding the Client's Domain in Software Engineering and more Slides Banking and Finance in PDF only on Docsity!
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
4.2 The Starting Point for Software
Projects
Requirements must be determined
Clients have produced requirements
New development
Evolution of existing system
A B
C D
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
4.4 What is a Requirement?
- It is a statement describing either
- an aspect of what the proposed system must do,
- or 2) a constraint on the system’s development.
- In either case it must contribute in some way towards adequately solving the customer’s problem;
- the set of requirements as a whole represents a negotiated agreement among the stakeholders.
- A collection of requirements is a requirements
document.
4.5 Types of Requirements
- Functional requirements
- Describe what the system should do
- Quality requirements
- C onstraints on the design to meet specified levels of quality
- Platform requirements
- C onstraints on the environment and technology of the system
- Process requirements
- C onstraints on the project plan and development methods
Quality Requirementts
- All must be verifiable
- Examples: Constraints on
- Response time
- Throughput
- Resource usage
- Reliability
- Availability
- Recovery from failure
- Allowances for maintainability and enhancement
- Allowances for reusability
4.6 Use-Cases: describing how the user
will use the system
- A use case is a typical sequence of actions that a
user performs in order to complete a given task
- The objective of use case analysis is to model the system from the point of view of … how users interact with this system … when trying to achieve their objectives. It is one of the key activities in requirements analysis
- A use case model consists of
- a set of use cases
- an optional description or diagram indicating how they are related
Scenarios
• A scenario is an instance of a use case
- A specific occurrence of the use case
- a specific actor ...
- at a specific time ...
- with specific data.
How to describe a single use case
• A. Name: Give a short, descriptive name to
the use case.
• B. Actors: List the actors who can perform
this use case.
• C. Goals: Explain what the actor or actors are
trying to achieve.
• D. Preconditions: State of the system before
the use case.
• E. Summary: Give a short informal
description. Docsity.com
Extensions
- Used to make optional interactions explicit or to
handle exceptional cases.
- Keep the description of the basic use case simple.
Generalizations
- Much like superclasses in a class diagram.
- A generalized use case represents several similar use cases.
- One or more specializations provides details of the similar use cases.
Example of generalization,
extension and inclusion
Example description of a use
case
Use case : Open file
Related use cases: Generalization of:
- Open file by typing name
- Open file by browsing
Steps : Actor actions System responses
- Choose ‘Open…’ command 2. File open dialog appears
- Specify filename
- Confirm selection 5. Dialog disappears