Docsity
Docsity

Prepare for your exams
Prepare for your exams

Study with the several resources on Docsity


Earn points to download
Earn points to download

Earn points by helping other students or get them with a premium plan


Guidelines and tips
Guidelines and tips

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

An in-depth analysis of domain analysis in software engineering. It covers the importance of domain analysis, the role of a domain expert, benefits, and the starting point for software projects. The document also discusses requirements, types of requirements, and gathering and analyzing requirements using use cases.

Typology: Slides

2012/2013

Uploaded on 07/29/2013

sathyanarayana
sathyanarayana 🇮🇳

4.4

(21)

140 documents

1 / 38

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
Object-Oriented Software Engineering
Practical Software Development using UML and Java
Chapter 4:
Developing Requirements
Docsity.com
pf3
pf4
pf5
pf8
pf9
pfa
pfd
pfe
pff
pf12
pf13
pf14
pf15
pf16
pf17
pf18
pf19
pf1a
pf1b
pf1c
pf1d
pf1e
pf1f
pf20
pf21
pf22
pf23
pf24
pf25
pf26

Partial preview of the text

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