Object oriented Software engineering

COURSE CODE :MCA 2005

Module 3 Developing Requirements And Class-based

Requirements Design Modeling With Classes ( 10 Hours)

1
 Module 3 Developing Requirements And Class-based Requirements
Design Modeling With Classes ( 10 Hours)
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 Part 1 Developing Requirements Modeling with Classes by Dr MK Jayanthi Kannan
 SYLLABUS
MODULE 1 AND MODULE 2
NO OF HOURS : 11 HOURS

3
SYLLABUS Module 3
Hours: 10 Sessions

4
SYLLABUS Module 4
Hours: 12 Sessions

5
SYLLABUS Module 5
Hours: 10 Sessions

6
Text Books:

7
Reference Books:

8
Module 3 Developing Requirements And Class-based Requirements
Design Modeling With Classes
topics as per syllabus
=
 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
 3.1 Developing requirements:
Domain analysis
 3.2 Types of requirements

10
 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 11

subsystems.
 3.1 Developing requirements: Domain analysis

• 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-
12
driven engineering.
 3.1 Developing requirements: Domain analysis

13
Module 3 Part 1 Developing Requirements Modeling with Classes by Dr MK Jayanthi Kannan
Module 3 Part 1 Developing Requirements Modeling with Classes by Dr MK Jayanthi Kannan
  3.2 Types of requirements
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.
Module 3 Part 1 Developing Requirements Modeling with Classes by Dr MK Jayanthi Kannan
 17
Module 3 Part 1 Developing Requirements Modeling with Classes by Dr MK Jayanthi Kannan
 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.

Module 3 Part 1 Developing Requirements Modeling with Classes by Dr MK Jayanthi Kannan

 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
21
22
 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 A non-functional requirement defines the quality
component. attribute of a software system.

It places constraints on “How should the software

2. It specifies “What should the software system do?”
system fulfill the functional requirements?”

Non-functional requirement is specified by technical

3. Functional requirement is specified by User. 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 Non-Functional Testing like Performance, Stress,
End, API testing, etc are done. Usability, Security testing, etc are done.

9. Usually easy to define. Usually more difficult to define. 24

 Non-functional Requirements
Non-functional
requirements

Product Organizational External

requirements requirements requirements

Ef ficiency Reliability Portability Interoperability Ethical

requir ements requirements requirements requirements requirements

Usability Delivery Implementation Standards Legislative

requirements requirements requirements requirements requirements

Performance Space Privacy Safety

requirements requir ements requirements requirements

Module 3 Part 1 Developing Requirements Modeling with Classes by Dr MK Jayanthi Kannan

 Non-functional Requirements..
• Metrics that can be used to quantitatively specify and verify non-functional
requirements.
Property Meas ure
Speed Processed transactions /second
User/Event res ponse time
Screen refresh time
Size K By tes
Number of RAM chips
Ease of use Training time
Number of help frames
Reliability Mean time to failure
Probability o f unav ailability
Rate of failure occurrence
Availability
Robustness Time to res tart after failu re
Percentage of events cau sing failure
Probability o f data corruption on failure
Portability Percentage of target dependent s tatements
Number of target s ystems
Module 3 Part 1 Developing Requirements Modeling with Classes by Dr MK Jayanthi Kannan
 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
 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?
34
 Validating Requirements
 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?
35
 3.3 Requirements gathering
 3.4 Object-based requirements analysis

 3.5 Use cases: describing how the user will use

the system

36
Module 3 Part 1 Developing Requirements Modeling with Classes by Dr MK Jayanthi Kannan
 3.3 Requirements gathering

 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.

37
Module 3 Part 1 Developing Requirements Modeling with Classes by Dr MK Jayanthi Kannan
 38
Module 3 Part 1 Developing Requirements Modeling with Classes by Dr MK Jayanthi Kannan
 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

39
Module 3 Part 1 Developing Requirements Modeling with Classes by Dr MK Jayanthi Kannan
 40
Module 3 Part 1 Developing Requirements Modeling with Classes by Dr MK Jayanthi Kannan
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
41
 42
Module 3 Part 1 Developing Requirements Modeling with Classes by Dr MK Jayanthi Kannan
 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
 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

44
Module 3 Part 1 Developing Requirements Modeling with Classes by Dr MK Jayanthi Kannan
 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 45
Module 3 Part 1 Developing Requirements Modeling with Classes by Dr MK Jayanthi Kannan
 3.7 Managing changing requirements

Jain University 46
Module 3 Part 1 Developing Requirements Modeling with Classes by Dr MK Jayanthi Kannan
 3.7 Managing changing requirements

Jain University 47
Module 3 Part 1 Developing Requirements Modeling with Classes by Dr MK Jayanthi Kannan
 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?
 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.
50
Elements of Requirement Analysis

51
 Scenario-Based Models

 “[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

52
 Jain University 53
Module 3 Part 1 Developing Requirements Modeling with Classes by Dr MK Jayanthi Kannan
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.
Module 3 Part 1 Developing Requirements Modeling with Classes by Dr MK Jayanthi Kannan
 USE CASE DIAGRAM

Use Case Diagram of Safe Home System 55

56
 57
Module 3 Part 1 Developing Requirements Modeling with Classes by Dr MK Jayanthi Kannan
  3.4 object-based requirements analysis
• 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.

Module 3 Part 1 Developing Requirements Modeling with Classes by Dr MK Jayanthi Kannan

 Class-Based Modeling
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.

59
 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.

Jain University 60
Module 3 Part 1 Developing Requirements Modeling with Classes by Dr MK Jayanthi Kannan
 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.

Module 3 Part 1 Developing Requirements Modeling with Classes by Dr MK Jayanthi Kannan

62
 63
Module 3 Part 1 Developing Requirements Modeling with Classes by Dr MK Jayanthi Kannan
Module 3 Part 1 Developing Requirements Modeling with Classes by Dr MK Jayanthi Kannan
UML Class Diagram for Hospital Management System

Module 3 Part 1 Developing Requirements Modeling with Classes by Dr MK Jayanthi Kannan

 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
Module 3 Part 1 Developing Requirements Modeling with Classes by Dr MK Jayanthi Kannan
 USE CASE DISGRAM for Hospital Management System

Module 3 Part 1 Developing Requirements Modeling with Classes by Dr MK Jayanthi Kannan

 USE CASE DISGRAM for Hospital Management System

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:

Module 3 Part 1 Developing Requirements Modeling with Classes by Dr MK Jayanthi Kannan

 UML Sequence Diagram for Hospital Management System

Module 3 Part 1 Developing Requirements Modeling with Classes by Dr MK Jayanthi Kannan

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
Module 3 Part 1 Developing Requirements Modeling with Classes by Dr MK Jayanthi Kannan
 Behavioural Models
• 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. Jain University 71
Module 3 Part 1 Developing Requirements Modeling with Classes by Dr MK Jayanthi Kannan
Behavioural Model – State Diagram

72
 Data models

73
Module 3 Part 1 Developing Requirements Modeling with Classes by Dr MK Jayanthi Kannan
 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
Checked and
Completed Signed Signed Send to signed order
order form order form order form supplier + order
Order
notification
details + Complete Validate Record
blank order form order order
order form Adjust
Order available
Signed budget
details order form
Order
amount
+ account
details
Orders Budget
file file

77
 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 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)
79
 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

Objects exhibit BEHAVIOR as well as attributes

80
 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
 UML class and object diagram
Class diagram showing two classes

Class diagram shows the static structure of an object-oriented model:

82
object classes, internal structure, relationships.
Module 3 Part 1 Developing Requirements Modeling with Classes by Dr MK Jayanthi Kannan
 UML class and object diagram …
Object diagram with two instances

Object diagram shows instances that are compatible with a given class
83
diagram.
Module 3 Part 1 Developing Requirements Modeling with Classes by Dr MK Jayanthi Kannan
 Object diagram for customer order

84
Module 3 Part 1 Developing Requirements Modeling with Classes by Dr MK Jayanthi Kannan
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)

Module 3 Part 1 Developing Requirements Modeling with Classes by Dr MK Jayanthi Kannan

Class Diagram for Library Management System

Module 3 Part 1 Developing Requirements Modeling with Classes by Dr MK Jayanthi Kannan

 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
 Module 3 Summary Developing Requirements And Class-based Requirements
Design Modeling With Classes ( 10 Hours)
So far in this Module, we discussed the following concepts..
 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:
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
88
Module 3 Part 1 Developing Requirements Modeling with Classes by Dr MK Jayanthi Kannan