OOSE_ Developing Requirements Modelling with Classes

Object oriented Software engineering
COURSE CODE :MCA 2005
1
Module3 Developing Requirements And Class-based
Requirements DesignModeling WithClasses(10Hours)

Module 3 Part 1 Developing Requirements Modeling with Classes by Dr MK Jayanthi Kannan

3.1 Developing requirements: Domain analysis
3.2 Types of requirements
3.3 Requirements gathering
3.4 object-based requirements analysis
3.5 Use cases: describing how the user will use the system
3.6 techniques for gathering requirements
3.7 Managing changing requirements,
3.8 class-based requirements design
Module 3 _ Part 2 : Modeling with classes:
3.9 Introduction to UML
3.10 Essentials of UML class diagrams
3.11 Associations and multiplicity
3.12 Generalization
3.14 More advanced features of class diagrams
Module 3 Developing Requirements And Class-based Requirements Design
ModelingWithClasses (10Hours)

3
SYLLABUS
MODULE 1 AND MODULE 2
NO OF HOURS : 11 HOURS

SYLLABUS Module 3
Hours: 10 Sessions
4

SYLLABUS Module 4
Hours: 12 Sessions
5

SYLLABUS Module 5
Hours: 10 Sessions
6

Module 3 Developing Requirements And Class-based Requirements
Design Modeling With Classes
topicsaspersyllabus
=
 3.1 Developing requirements: Domain analysis
 3.2 Types of requirements
 3.3 Requirements gathering
 3.4 object-based requirements analysis
 3.5 Use cases: describing how the user will use the system
 3.6 techniques for gathering requirements
 3.7 Managing changing requirements,
 3.8 class-based requirements design Modeling with classes:
Time : 10 Hours
COURSE OUTCOMES : CO3, CO4, CO5
PROGRAM OUTCOMES : PO1, PO2,PO3,PO4,PO5 and PSO2

10
 3.1 Developing requirements:
Domain analysis

11
 3.1 Domain analysis
• In software engineering, domain analysis, or product line
analysis, is the process of analyzing related software systems in
a domain to find their common and variable parts.
• It is a model of wider business context for the system. The term
was coined in the early 1980s by James Neighbors.
• A domain analysis should be performed very early in the
development process, even as early as the proposal phase.
• The primary purpose of this activity is to identify reusable
hardware and software components, as well as complete
subsystems.

12
• Domain analysis produces domain models using methodologies
such as domain specific languages, feature tables, facet
tables, facet templates, and generic architectures, which
describe all of the systems in a domain.
• The products, or "artifacts", of a domain analysis are
sometimes object-oriented models (e.g. represented with
the Unified Modeling Language (UML)) or data
models represented with entity-relationship diagrams (ERD).
• Software developers can use these models as a basis for the
implementation of software architectures and applications.
• This approach to domain analysis is sometimes called model-
driven engineering.

13

Users, System Engineers, and Program Managers will have to develop
several different types of requirements on an acquisition program
through its life cycle. These requirements range from very high-level
concept-focused to very specific for a part. The four (4) main types of
requirements that you can expect on a program are:
•Functional Requirements
•Performance Requirements
•System Technical Requirements
•Specifications
A requirement is a statement that identifies a product or
process operational, functional, or design characteristic or
constraint, which is unambiguous, testable or measurable,
and necessary for product or process acceptability.

17

Requirements
• Requirements = services the system is expected to
provide + constraints placed on the system.
• Requirements engineering = gathering, negotiating,
analyzing, and documenting requirements.
• The requirements could be expressed at various levels of
abstraction.
• The way requirements are defined has a major impact on
the development of the software product.

REQUIREMENTS ENGINEERING
•The process of establishing the services that the customer
requires from a system and the constraints under which it
operates and is developed.
•The requirements themselves are the descriptions of the
system services and constraints that are generated during the
requirements engineering process.

REQUIREMENT ENGG.
• It may range from a high-level abstract statement of a service or of a
system constraint to a detailed mathematical functional specification
• Types of requirement
• User requirements :Statements in natural language plus
diagrams of the services the system provides and its operational
constraints. Written for customers.
• System requirements : A structured document setting out
detailed - descriptions of the system services. Written as a contract
between client and contractor.
• Software specification : A detailed software description which
can serve as a basis for a design or implementation. Written for
developers.
20

Functional and Non functional Requirements
Functional Requirements:
• These are the requirements that the end user specifically demands as basic facilities
that the system should offer.
• All these functionalities need to be necessarily incorporated into the system as a part of
the contract.
• describe the requested functionality/behaviour of the system: services (functions),
reactions to inputs, exceptions, modes of operations
Non Functional Requirements
• These are basically the quality constraints that the system must satisfy according to the
project contract.
• The priority or extent to which these factors are implemented varies from one project
to other. They are also called non-behavioral requirements.
• represent constraints on the system and its functionality: performance constraints,
compliance with standards, constraints on the development process.
23

FUNCTIONAL REQUIREMENTS NON FUNCTIONAL REQUIREMENTS
1. A functional requirement defines a system or its
component.
A non-functional requirement defines the quality
attribute of a software system.
2. It specifies “What should the software system do?”
It places constraints on “How should the software
system fulfill the functional requirements?”
3. Functional requirement is specified by User.
Non-functional requirement is specified by technical
peoples e.g. Architect, Technical leaders and software
developers.
4. It is mandatory. It is not mandatory.
5. It is captured in use case. It is captured as a quality attribute.
6. Defined at a component level. Applied to a system as a whole.
7. Helps you verify the functionality of the software. Helps you to verify the performance of the software.
8. Functional Testing like System, Integration, End to
End, API testing, etc are done.
Non-Functional Testing like Performance, Stress,
Usability, Security testing, etc are done.
9. Usually easy to define. Usually more difficult to define. 24

Non-functional Requirements
Performance
requirements
Space
requirements
Usability
requirements
Efficiency
requirements
Reliability
requirements
Portability
requirements
Interoperability
requirements
Ethical
requirements
Legislative
requirements
Implementation
requirements
Standards
requirements
Delivery
requirements
Safety
requirements
Privacy
requirements
Product
requirements
Organizational
requirements
External
requirements
Non-functional
requirements

Non-functional Requirements..
• Metrics that can be used to quantitatively specify and verify non-functional
requirements.
Property Measure
Speed Processed transactions/second
User/Event response tim
e
Screen refresh tim
e
Size K Bytes
Number of RAM chips
Ease of use Training time
Number of help frames
Reliability Mean time to failure
Probability of unavailability
Rate of failure occurrence
Availability
Robustness Time to restart after failure
Percentage of events causing failure
Probability of data corruption on failure
Portability Percentage of target dependent statements
Number of target system
s

User Requirements
•User requirements:
•Should be understood by the user, and should not
address design and implementation aspects
•Should focus on the key facilities required
•Problems with requirements written in natural
language:
•Lack of clarity, ambiguity, various interpretations
possible
•Confusion, lack of separation between different types of
requirements
•Mixture of several requirements in the same statement
•Hard to modularize and thus hard to find connections
between requirements

User Requirements
•Guidelines for writing requirements:
•Create and use a standard format for the
entire software requirements specification
•Highlight important parts of the
requirement statements
•Use consistently the language (difference
between “should” and “shall”)
•Avoid computer jargon

The Software Requirements Document
•This document, also called Software Requirements
Specification (SRS), is the official description of the system’s
requirements (includes user and system reqs.)
•Heninger (1980) recommends that an SRS should:
• Specify only external system behaviour
• Specify constraints on implementation
• Be easy to change
• Serve as a reference for maintainers
• Record forethought about the software life cycle
• Describe acceptable responses to undesired events

Software Requirements Document
•SRS structure according IEEE/ANSI 830-1993
standard (overview only, many more details are
given in the standard):
•Introduction
•General description
•Specific requirements
•Appendices
•Index
•This structure needs to be tailored for each
particular organization

Software Requirements Specification
• A software requirements specification (SRS) is a document that is created
when a detailed description of all aspects of the software to be built must be
specified before the project is to commence.
• It is important to note that a formal SRS is not always written
1. Introduction
• 1.1 Purpose
• 1.2 Document Conventions
• 1.3 Intended Audience and Reading Suggestions
• 1.4 Project Scope
• 1.5 References
2. Overall Description
• 2.1 Product Perspective
• 2.2 Product Features
• 2.3 User Classes and Characteristics
• 2.4 Operating Environment
31

• 2.5 Design and Implementation Constraints
• 2.6 User Documentation
• 2.7 Assumptions and Dependencies
3. System Features
• 3.1 System Feature 1
• 3.2 System Feature 2 (and so on)
4. External Interface Requirements
• 4.1 User Interfaces
• 4.2 Hardware Interfaces
• 4.3 Software Interfaces
• 4.4 Communications Interfaces
5. Other Nonfunctional Requirements
• 5.1 Performance Requirements
• 5.2 Safety Requirements
• 5.3 Security Requirements
• 5.4 Software Quality Attributes
6. Other Requirements 32

REQUIREMENTS ENGINEERING PROCESS
33

Validating Requirements
34
 Is each requirement consistent with the overall objective for
the system/product?
 Have all requirements been specified at the proper level of
abstraction? That is, do some requirements provide a level of
technical detail that is inappropriate at this stage?
 Is the requirement really necessary or does it represent an
add-on feature that may not be essential to the objective of
the system?
 Is each requirement bounded and unambiguous?
 Does each requirement have attribution? That is, is a source
(generally, a specific individual) noted for each requirement?
 Do any requirements conflict with other requirements?

Validating Requirements
35
 Is each requirement achievable in the technical environment
that will house the system or product?
 Is each requirement testable, once implemented?
 Does the requirements model properly reflect the information,
function and behavior of the system to be built.
 Has the requirements model been “partitioned” in a way that
exposes progressively more detailed information about the
system.
 Have requirements patterns been used to simplify the
requirements model. Have all patterns been properly
validated? Are all patterns consistent with customer
requirements?

36
 3.4 Object-based requirements analysis
 3.5 Use cases: describing how the user will use
the system

37
 Requirements gathering is the process of
identifying your project's exact requirements from
start to finish.
 This process occurs during the project initiation
phase but you'll continue to manage your project
requirements throughout the entire project timeline.

38

39
 Requirement gathering process
 Requirements gathering is the process of
determining what your projects need to achieve
and what needs to be created to make that happen.
You're probably familiar with the fact that
everybody has their own common project
assumptions about what a project should include

40

41
3.3 Requirements Gathering
 meetings are conducted and attended by both software engineers and
customers
 rules for preparation and participation are established
 an agenda is suggested
 a "facilitator" (can be a customer, a developer, or an outsider) controls
the meeting
 a "definition mechanism" (can be work sheets, flip charts, or wall
stickers or an electronic bulletin board, chat room or virtual forum) is
used
 the goal is
 to identify the problem
 propose elements of the solution
 negotiate different approaches, and
 specify a preliminary set of solution requirements

42

Quality Function Deployment
Normal requirements: Requirements which are stated during
the meeting with the customer
Example:) normal requirements might be requested types of
graphical displays, specific system functions
Expected requirements: Requirements are implicit to the
product or system that are not explicitly stated by the customer.
Exciting requirements: features go beyond the customer’s
expectations and prove to be very satisfying when present.
Example:) software for a new mobile phone comes with
standard features, but is coupled with a set of unexpected
capabilities (e.g., multitouch screen, visual voice mail) that
delight every user of the product.
43

44
System Design Problems
•Requirements partitioning to hardware,
software and human components may involve a lot of negotiation
•Difficult design problems are often assumed to be readily
solved using software
•Hardware platforms may be inappropriate for
software requirements so software must compensate for this

Jain University 45
Understanding the Classification of Requirements
Functional requirements :
• Describe functionality or system services, how the system should react to particular inputs and how the system
should behave in particular situations.
• Depend on the type of software, expected users and the type of system where the software is used
• Functional user requirements may be high-level statements of what the system should do but functional system
requirements should describe the system services in detail.
Non-functional requirements :
• Defines system properties and constraints e.g. reliability, response time and storage requirements. Constraints
are I/O device capability, system representations, etc.
• Can be constraints on the process too
• Use a particular CASE system, programming language or development method
• System maybe unusable if non-functional requirements are not satisfied (Critical)
• Non-functional classifications
Product requirements
• Requirements which specify that the delivered product must behave in a particular way e.g. execution speed,
reliability, etc.
• Organizational requirements
• Requirements which are a consequence of organizational policies and procedures e.g. process standards used,
implementation requirements, etc.
• External requirements
• Requirements which arise from factors which are external to the system and its development process e.g.
interoperability requirements, legislative requirements, etc.

Jain University 46
3.7 Managing changing requirements

Jain University 47
3.7 Managing changing requirements

Objectives of Modular Software Design
• Functional partitioning into discrete scalable , reusable modules.
• Rigorous use of well-defined modular interface.
• Ease of change to achieve technology transparency and to the
extent possible make use of industry standards for key interfaces.
• Modularity is the principle of keeping separate the various unrelated aspects
of a system, so that each aspect can be studied in isolation (also called
separation of concerns).
• If the principle is applied well, each resulting module will have a single
purpose and will be relatively independent of the others.
• Each module will be easy to understand and develop easier to locate faults
(because there are fewer suspect modules per fault).
• Easier to change the system (because a change to one module affects
relatively few other modules)
48

Objectives of Modular Software Design
49

What is Requirement Analysis?
50
 Requirements analysis
 specifies software’s operational characteristics
 indicates software's interface with other system elements
 establishes constraints that software must meet
 Requirements analysis allows the software engineer (called
an analyst or modeler in this role) to:
 elaborate on basic requirements established during earlier
requirement engineering tasks
 build models that depict user scenarios, functional
activities, problem classes and their relationships, system
and class behavior, and the flow of data as it is
transformed.

Elements of Requirement Analysis
51

Scenario-Based Models
52
 “[Use-cases] a“[Use-cases] are simply an aid to defining
what exists outside the system (actors) and what should be
performed by the system (use-cases).” - Ivar Jacobson
 Represented via use cases
1 Creating Preliminary use case
 What to write about? – Inception and elicitation will
provide the information for begin with use cases.
2 Refining Preliminary use case
3 Writing a formal use case

Jain University 53

Use case Notation:
Use case is represented as an eclipse with a name inside it. It may contain additional
responsibilities.
Use case is used to capture high level functionalities of a system.
Actor Notation:
An actor can be defined as some internal or external entity that interacts with the system.
Actor is used in a use case diagram to describe the internal or external entities.

USE CASE DIAGRAM
55
Use Case Diagram of Safe Home System

57

• object-oriented requirements analysis is an object-oriented
approach involves identifying real-world things, defining the
data that will be used to represent those real-world things, and
defining the processing that acts upon the data.
• In object-oriented requirements analysis, you should model
real-world entities using object classes.
• You should not include details of the individual objects
(instantiations of the class) in the system.
• You may create different types of object model, showing how
object classes are related to each other, how objects are
aggregated to form other objects, how objects interact with
other objects and so on.

Class-Based Modeling
59
Class-based Modeling includes:
1. Identifying classes (often from use cases as a starting point)
2. Identifying associations between classes
3. Identifying general attributes and responsibilities of classes
4. Modeling interactions between classes
5. Modeling how individual objects change state -- helps identify
operations
6. Checking the model against requirements, making adjustments,
iterating through the process more than once.

Jain University 60
Class Notation:
UML class is represented by the diagram shown below. The diagram is divided into four
parts.
 The top section is used to name the class.
 The second one is used to show the attributes of the class.
 The third section is used to describe the operations performed by the class.
 The fourth section is optional to show any additional components.
Classes are used to represent objects. Objects can be anything having properties and
responsibility.

Object Notation:
The object is represented in the same way as the class. The only difference is the name
which is underlined as shown below.
As object is the actual implementation of a class which is known as the instance of a
class. So it has the same usage as the class.

63

UML Class Diagram for Hospital Management System

USE CASE DISGRAM for Hospital Management System
UML Use Case Diagram
The use case diagram for the hospital management system shows the actors:
•Doctor
•Patient
and their defined use cases:
•Doctor
• Visit the patient
• Examine the patient
• Add diagnoses
• Prescribe drugs
• Schedule the medical procedure
• Discharge the patient
• Report the patient condition
•Patient
• Register
• Unregister
• Apply for discharge
• Confirm the medical procedure

UML Class Diagram of Hospital Rooms
The diagram describes a class hierarchy of hospital rooms and other associated classes.
These classes are defined in the diagram:

UML Sequence Diagram for Hospital Management System

UML Sequence Diagram Domain Analysis for Hospital Management System
UML Sequence Diagram of Patient Examination
The sequence diagram shows a patient examination by a doctor.
There are these lifelines:
•Doctor
•Patient
•Hospital System
The lifelines communicate with the following messages:
•Start the examination
•Add symptom
•Show recommended diagnoses
•Add the diagnosis
•Prescribe the needed drug
•Show found contraindications
•Propose the medical procedure
•Confirm the medical procedure
•Show possible dates
•Choose a date
•Confirm the schedule

Jain University 71
• Behavioural models are used to describe the overall behaviour
of a system
• Two types of behavioural model are shown here
• Data processing models that show how data is processed as it
moves through the system
• State machine models that show the systems response to
events
• Both of these models are required for a description of the
system’s behaviour
Explanation of Data processing models, State machine models
required.
Behavioural Models

Behavioural Model – State Diagram
72

73
Data models

Data Flow Models
• Data flow diagrams are used to model the system’s data
processing
• These show the processing steps as data flows through a
system
• Intrinsic part of many analysis methods
• Simple and intuitive notation that customers can
understand
• Show end-to-end processing of data.
74

Data Flow Diagrams (DFD)
•DFDs model the system from a functional perspective.
•Tracking and documenting how the data associated with a
process is helpful to develop an overall understanding of the
system
•Data flow diagrams may also be used in showing the data
exchange between a system and other systems in its
environment
75

Elements of a DFD
•Processes
• Change the data. Each process has one or more inputs and
outputs
•Data stores
used by processes to store and retrieve data (files, DBs)
•Data flows
-movement of data among processes and data
stores
•External entities
- outside things which are sources or destinations of
data to the system
76

DFD for Order Processing
77
Complete
order form
Order
details +
blank
order form
Validate
order
Record
order
Sendto
supplier
Adjust
available
budget
Budget
file
Orders
file
Completed
order form
Signed
order form
Signed
order form
Checked and
signed order
+ order
notification
Order
amount
+ account
details
Signed
order form
Order
details

What is Object Oriented Data Modeling?
•Centers around objects and classes
•Involves inheritance
•Encapsulates both data and behavior
•Benefits of Object-Oriented Modeling
• Ability to tackle challenging problems
• Improved communication between users, analysts, designer, and
programmers
• Increased consistency in analysis and design
• Explicit representation of commonality among system components
• System robustness
• Reusability of analysis, design, and programming results
78

OO vs EER Data Modeling
Object Oriented
79
ER
Class Entity type
Object Entity Instance
Association Relationship
Inheritance of attributes Inheritance of attributes
Inheritance of behavior No representation of
behavior
Object-oriented modeling is frequently accomplished using the Unified
Modeling Language (UML)

Classes and Objects
•Class: An entity that has a well-defined role in
the application domain, as well as state,
behavior, and identity
• Tangible: person, place or thing
• Concept or Event: department, performance, marriage,
registration
• Artifact of the Design Process: user interface, controller,
scheduler
•Object: a particular instance of a class
80
Objects exhibit BEHAVIOR as well as attributes
 Different from entities

State, Behavior, Identity
•State: attribute types and values
•Behavior: how an object acts and reacts
•Behavior is expressed through operations that can be
performed on it
•Identity: every object has a unique identity, even if
all of its attribute values are the same
81

82
Class diagram shows the static structure of an object-oriented model:
object classes, internal structure, relationships.
UML class and object diagram
Class diagram showing two classes

83
Object diagram shows instances that are compatible with a given class
diagram.
UML class and object diagram …
Object diagram with two instances

84
Object diagram for customer order

Class Diagram for Library Management System
Library management system provides support for a library,
including book and member management. It logs and processes book lending.
Domain Classes and Enumerations
•Book (Class)
•Genre (Enumeration) - adventure, contemporary, fantasy, horror, mystery,
romance, thriller
•Author (Class)
•BookCopy (Class)
•BookEdition (Class)
•Publisher (Class)
•Member (Class)
•BookLoanLog (Class)
•MemberType (Enumeration) - standard, VIP
•Bookshelf (Class)
•Department (Class)
•Bookcase (Class)
•Reminder (Class)

Class Diagram for Library Management System

STRUCTURED ANALYSIS
1. Source traceability information links the requirements to the stakeholders who proposed
the requirements and to the rationale for these requirements. When a change is proposed,
you use this information to find and consult the stakeholders about the change.
2. Requirements traceability information links dependent requirements within the
requirements document. You use this information to assess how many requirements are
likely to be affected by a proposed change and the extent of consequential requirements
changes that may be necessary.
3. Design traceability information links the requirements to the design modules where these
requirements are implemented. You use this information to assess the impact of proposed
requirements changes on the system design and implementation.
87

Module3 SummaryDeveloping Requirements And Class-based Requirements
DesignModeling WithClasses (10Hours)
So far in this Module, we discussed the following concepts..
88
 3.5 Use cases: describing how the user will use the system
 3.6 techniques for gathering requirements
 3.7 Managing changing requirements,
 3.8 class-based requirements design Modeling with classes:
Module 3 _ Part 2 Introduction to UML
 3.9 Essentials of UML class diagrams
 3.10 Associations and multiplicity
 3.11 Generalization
 3.12 More advanced features of class diagrams 88

OOSE_ Developing Requirements Modelling with Classes

More Related Content

Similar to OOSE_ Developing Requirements Modelling with Classes (20)

Recently uploaded (20)

OOSE_ Developing Requirements Modelling with Classes