REQUIREMEN

TS ANALYSIS
Modelling
Requirements
• Flowchart
• DFD
• Use Case
• ERD
• Class Diagram
Conceptual Data
Modeling
• A detailed model that
captures the overall
structure of data in an
organization
• Independent of any database
management system or
other implementation
considerations
Conceptual Data
Modeling
• Two perspectives
• Top-down
• Data model is derived
from an intimate
understanding of the
business.
• Bottom-up
• Data model is derived by
reviewing specifications
and business documents.
Process of Conceptual
Data Modeling
• Develop a data model for the
current system
• Develop a new conceptual data
model that includes all
requirements of the new system
• In the design stage, the conceptual
data model is translated into a
physical design
• Project repository links all design
and data modeling steps
performed during SDLC
 Deliverables and Outcome

Primary deliverable is an entity-relationship (E-R) Second deliverable is a set of entries about data
diagram or class diagram objects to be stored in repository or project dictionary.

Repository links data, process, and logic models of an information system.

Data elements included in the DFD must appear in the data model and vice
versa.
Each data store in a process model must relate to business objects
represented in the data model.
Requirements Determination
for Data Modeling
• What are subjects/objects of the business?
 Data entities and descriptions

• What unique characteristics distinguish

between subjects/objects of the same type?
 Primary keys

• What characteristics describe each

subject/object?
 Attributes and secondary keys

• How do you use the data?

 Security controls and user access
privileges
Requirements Determination
for Data Modeling
• Are all instances of each object the same?
 Supertypes, subtypes, and aggregations

• Over what period are you interested in the

data?
 Cardinality and ordinality dimensions

• What events occur that imply associations

between objects?
 Relationships and cardinalities

• Are there special circumstances that affect the

way events are handled?
 Integrity rules and cardinalities
Entity-Relationship (E-
R) Modeling
• Entity-Relationship (E-R) Diagram
• A detailed, logical
representation of the entities,
associations and data
elements for an organization
or business
• Notation uses three main
constructs
• Data entities
• Relationships
• Attributes
Person, place, object, Association between named property or
event or concept about the instances of one characteristic of an
which data is to be or more entity types entity
maintained
Identifier Attributes
• Candidate key
• Attribute (or combination of attributes) that uniquely identifies each instance
of an entity type
• Identifier
• A candidate key that has been selected as the unique identifying
characteristic for an entity type
• Selection rules for an identifier
1. Choose a candidate key that will not change its value.
2. Choose a candidate key that will never be null.
3. Consider substituting single value surrogate keys for large composite keys.
Multivalued Attributes
• An attribute that may take on more than one value for each entity
instance
• Represented on E-R Diagram :
• double-lined ellipse
• weak entity
Entity and Attribute Example

Simple attributes

Identifier attribute… Multivalued attribute… an

each employee has a employee may have more
unique ID. than one skill.
Degree of Relationship
• Degree: number of entity types that participate in a
relationship
• Three cases
• Unary: between two instances of one entity type
• Binary: between the instances of two entity types
• Ternary: among the instances of three entity types
Degree of Relationship
Cardinality
• The number of instances of entity B that can or must
be associated with each instance of entity A
• Minimum Cardinality
• The minimum number of instances of entity B
that may be associated with each instance of
entity A
• Maximum Cardinality
• The maximum number of instances of entity B
that may be associated with each instance of
entity A
• Mandatory vs. Optional Cardinalities
• Specifies whether an instance must exist or can
be absent in the relationship
Cardinality
Supertypes and Subtypes

• Subtype: a subgrouping of the entities in an

entity type that shares common attributes or
relationships distinct from other subtypes
• Supertype: a generic entity type that has a
relationship with one or more subtype
Context: College Database
• A college contains many departments
• Each department can offer any number of
courses
• A department has unique name and location
• Many instructors can work in a department
• An instructor can work only in one department
ER Modeling • For each department, there is a Head
• An instructor can be head of only one
department
• Each instructor can take any number of courses
• A course can be taken by only one instructor
• A student can enroll for any number of courses
• Each course can have any number of students
Step 1 : Identify
the Entities
What are the entities
here?
From the statements
given, the entities are
1.Department
2.Course
3.Instructor
4.Student
• Step 2 : Identify the relationships
1. One department offers many courses. But one particular
course can be offered by only one department. hence the
cardinality between department and course is One to Many
(1:N)
2. One department has multiple instructors . But instructor
belongs to only one department. Hence the cardinality
between department and instructor is One to Many (1:N)
3. One department has only one head and one head can be the
head of only one department. Hence the cardinality is one to
one. (1:1)
4. One course can be enrolled by many students and one student
can enroll for many courses. Hence the cardinality between
course and student is Many to Many (M:N)
5. One course is taught by only one instructor. But one instructor
teaches many courses. Hence the cardinality between course
and instructor is Many to One (N :1)
• Step 3: Identify the key attributes
• "Department_ID" can identify a
department uniquely. Hence
Department_ID is the key attribute for the
Entity "Department".
• Course_ID is the key attribute for "Course"
Entity.
• Student_ID is the key attribute for
"Student" Entity.
• Instructor_ID is the key attribute for
"Instructor" Entity.
• Step 4: Identify other relevant
attributes
• For the department entity, other attributes
are deptt_name and location
• For course entity, other attributes are
course_name,duration
• For instructor entity, other attributes are
first_name, last_name, phone
• For student entity, first_name, last_name,
phone
Home Assignment: Description of COMPANY Database
• The company is organized into departments.
• Each department has a unique name, a unique number, and a particular employee who
manages the department.
• We keep track of the start date when that employee began managing the department.
• A department may have several locations.
• A department controls a number of projects, each of which has a unique name, a unique
number, and a single location.
• We store each employee’s name, social security number, address, salary, sex and
birthdate.
• An employee is assigned to one department but may work on several projects, which are
not necessarily controlled by the same department.
• We keep track of the number of hours per week that an employee works on each
project.
• We also keep track of the direct supervisor of each employee.
• We want to keep track of the dependents of each employee for insurance purposes.
• We keep each dependent’s name, sex, birthdate, and relationship to the employee.
Business Rules

• Specifications that preserve the integrity of the logical data model

• Four types
• Entity integrity: unique, non-null identifiers
• Referential integrity constraints: rules governing relationships
• Domains: valid values for attributes
• Triggering operations: other business rules regarding attribute values
Domains

• The set of all data types and ranges of values that an attribute can assume
• Several advantages
1. Verify that the values for an attribute are valid
2. Ensure that various data manipulation operations are logical
3. Help conserve effort in describing attribute characteristics
Triggering Operations

• An assertion or rule that governs the validity of data manipulation operations such as insert, update
and delete
• Components:
• User rule: statement of the business rule to be enforced by the trigger
• Event: data manipulation operation that initiates the operation
• Entity Name: name of entity being accessed or modified
• Condition: condition that causes the operation to be triggered
• Action: action taken when the operation is triggered
Examples of Business Rules: Typical Domain Definitions
Name Account_Number Amount
Meaning Customer Bank Account Number Amount of transaction
Data Type Character Numeric
Format XXX-XXXXX-XX .XX (2 decimal places)
Range 0-100000
Unique? Y N
Not Null? Y Y

Example of Business Rules: Typical Triggering Operation

User rule: WITHDRAWAL Amount may not exceed ACCOUNT Balance
Event: Insert
Entity Name: WITHDRAWAL
Condition: WITHDRAWAL Amount > ACCOUNT Balance
Action: Reject the insert transaction
Object Modeling Using Class Diagrams

• Object-oriented approach
• Based on Unified Modeling Language (UML)
• Features
• Objects and classes
• Encapsulation of attributes and operations
• Polymorphism
• Inheritance
Classes

• Class: a logical grouping of objects with similar attributes and behaviors

• Operation: a function or service provided by all instances of a class
• Encapsulation: the technique of hiding internal implementation details of an object from external
view
• Object: an entity with a well-defined role in an application
• Each object has:
• State: encompasses the attributes, their values, and relationships of an object
• Behavior: represents how an object acts and reacts
• Identity: uniqueness, no two objects are the same
Class Diagram

• A class diagram is a type of static

diagram that describes the
structure of a system by showing
the system’s elements, their
attributes, operations (or
methods), and the relationships
among the elements
• Class Diagram Illustrates data
models for even complex
information systems and is helpful
for developers and other
stakeholders.
Relationships: Dependency
• Exists between two classes if the changes to the definition of one may
cause changes to the other (but not the other way around).
• Class1 depends on Class2
• Student has a dependency on College
Relationships: Generalization or Inheritance

• Superclass-subclass relationships
• Subclass inherits attributes, operations,
and associations of the superclass
• Represents an "is-a" relationship
Relationships: Generalization
or Inheritance

• SubClass1 and SubClass2 are

specializations of Super Class.
• A solid line with a hollow arrowhead
that points from the child to the parent
class
Relationships: Association
• A structural link between two peer classes
• A relationship among instances of object classes
• There is an association between Class1 and Class2
• A solid line connecting two classes
• Multiplicity: indicates how many objects participate in a give
relationship
Relationships: Association
Relationships: Aggregation and Composition

• Aggregation
• A part-of relationship between a component and an aggregate object
• Composition
• An aggregation in which the part object belongs to only one aggregate object and lives and dies
with the aggregate object
Relationships:
Aggregation
and
Composition
 Polymorphic Operations
The same operation may apply to two or more classes in different ways
UML Class Diagram
SRS Document

• A software (systems) requirements specification (SRS) is a document that describes

what the software (system) will do and how it will be expected to perform. It
also describes the functionality the product needs to fulfill all stakeholders (business,
users) needs
• A typical SRS includes: a purpose, an overall description and specific requirements

http://web.cse.ohio-state.edu/~bair.41/616/Project/Example_Document/Req_Doc_Example.html