Understanding the Client's Domain in Software Engineering, Slides of Banking and Finance

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
  • 1. 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

1. Choose ‘Open…’ command 2. File open dialog appears
2. Specify filename
3. Confirm selection 5. Dialog disappears