Chapter 1: intro.

Software engineering.
• The process of taking an idea and turning it into a program.
• OR an organized, analytical approach to the design, development, use, and
maintenance of software.

Advantages of following SWE techniques:

• Programmers understand what the user needs & wants.
• The app has less bugs.
• Apps can be enhanced over time.
• The app is effective, usable, and maintainable.
• Helps in scheduling & producing the product.
• Gives more flexibility.

SWE steps:
1) Requirement gathering.
• Finding out what the customer wants & needs.

2) High level design (HLD).

Includes decisions about:
• What platform to use.
• What data design to use.
• How it interfaces with other systems.

Project should be broken into:

• Database.
• Classes.
• User interface.
• External interfaces.
3) Low level design (LLD).
It includes:
• How pieces of the project should work.
• doesn’t need to include implementation details.

4) Development.
• Programmers refine LLDs until they know how to implement them.
• They should also work on the previous steps (req gathering, HLD, LLD).
• They should test code as they write it.

5) Testing.
• Pieces might not work properly together.
• Programmers should test their own code.
• Testers should write code tests.
• Pieces that pass those tests can be integrated into the project.
• Testing should be done after each step of the development.
o Because ” The longer a bug stays undetected, the harder it’s fixed”.

Testing techniques:
• Exhaustive testing.
o Testing with every possible input.

• Black-box testing.
o You know what a method does, but not how.

• White-box testing.
o You know how a method works and you pick difficult test cases.
o Some people skip some important test cases.

• Gray-box testing.
o Combination of both (black & white).
6) Deployment.
Difficult, time-consuming, and expensive.
May involve:
• New computers for backend database.
• New network.
• New computers for the users.
• User training.
• Parallel use (using new & old system).
• Special data maintenance.
o To synchronize between old & new database.
• Massive bug fixing.

7) Maintenance.
• Fixing user discovered bugs.
• Adding user suggestions (enhancements).

8) Wrap-up.
• Evaluate the project.
o Figure what went wrong & right.
o Figure how to prevent the things that went wrong.
o Figure how to increase the occurrence of the things that went right.

9) Everything all at once.

• Working on as much of the project as use can at any given moment.
Project Documentation.
• There is a lot of different documentations in software projects.
• Some projects allow requirement changes.
o This makes finding recent versions harder.
• Simultaneous editing may occur (race condition problem).
o The last edit request will overwrite the other requests.

• To solve these problems, you need a good documentation system.

o They must support one of the following:
▪ Allow document sharing.
▪ Allow only one user to edit at a time.
▪ Allow to only fetch the most recent version.
▪ Allow to fetch a specific version.
▪ Allow to search documents (by tags, keywords, etc.).
▪ Allow to compare two versions.

E-mails:
• Create an email for your project.
• Every message should be copied to the email.
• Prefix your email about your project to make it easier to find.
• Add different classes to the email subject.

Project management.
Ensures the goals are set, tracked, and met.
Project management roles:
1) Executive support || sponsor (champion).
The Lack of a champion is one of the top reasons why software projects fail.
• Provides necessary resources (budgets, hardware, personnel).
• Makes “go/no-go” decisions.
• Decides when to cancel the project.
• Helps in navigating administrative obstacles.
• Defines the business case (evaluates benefits, cost, risk, etc.).
• Works with users & other stakeholders to persuade them to buy-in.
 • Isolating the project from external distractions.
• Provides feedback to devs about finished features.
• Chooses between managers, users, devs, and others interested in the
project.
• Gives guidance on high-level issues.

2) Project manager.
• The highest-ranking member of the project team.
• Works on all stages of development.
• Doesn’t need to be an expert in the users’ field || in programming.
• Their duties:
o Helps define the project requirements.
o Tracks/monitors project tasks.
o Keeps users & champion up to date on the progress.
o Provides an interface between customers & devs.
o Manages resources (time, people, budget, hardware, software).
o Manages delivery of services/products.
o Responds to unexpected problems.
o Manages risk.

Project management tools:

These tools help study the project’s duration, look for potential bottlenecks, and
schedule tasks.
1) PERT Charts.
• Stands for (Program Evaluation and Review Technique).
• A graph that uses nodes & links to show priority relationships among the
project tasks.
• Types of PERT charts:
o Activity on arrow (AOA): arrows represent tasks and nodes
represent milestones.
o Activity on node (AON): nodes represent tasks and arrows represent
priority relationships (easier to build and understand).
AON steps:
1- List the tasks, predecessor tasks, and expected time for each task.
a. You may add best & worst cases.
b. Doesn’t need to include every predecessor combination.
c. Unnecessary relationships don’t have to be removed.

2- Make rearranging tasks easy.

a. Make an index card for each task (name, predecessor, expected
time).
3- Place the start task in the Ready pile.
4- Place tasks in the Ready pile right to previous task.
5- Look through the tasks in the Pending pile and cross out the
predecessors you added to the Ready pile.
6- Cards that have all their predecessors crossed out gets moved to the
Ready pile.
7- Repeat steps 4-6 until you place the final task.
8- Draw arrows representing the predecessor relationships.

• You can add the start & finish tasks as a predecessor for any task (that
doesn’t have predecessors).
 Critical path methods.
PERT charts are used to find the critical paths through the network.
Critical path: the longest possible paths through the network.
• moving through every node and finding the longest path.
• There can be multiple paths with the same length.

2) Gantt Charts.
• a horizontal bar chart.
o Bars represent task activities.
o Bars’ lengths indicate tasks duration.
o Bars are placed on a horizontally on a calendar to show their start &
stop times.
• Shows a schedule for a collection of related tasks.
• Arrows show the relationships between tasks & their predecessors.
• Weekends extend the project’s total duration.

Steps:
1- List the tasks, their duration, and predecessors (on the left).

2- Cut out a thin rectangle for each task.

a. rectangle width represents the duration.
b. Write the tasks’ names on their rectangles.

3- Move from left to right placing each rectangle.

a. Make sure the left edge lines up with the right edge of its
predecessor.

4- Add arrows to show the predecessor relationships.

3) Scheduling software.
• Some tasks take longer than expected and re-drawing the whole
schedule each time would be problematic.
o Project scheduling tools can re-draw schedules.
o These tools enable you to click & drag to connect two tasks.
o You can change tasks’ duration.
o Enable you to define other kinds of relationships.

4) Predicting times.
• Other methods depend on time estimated being accurate.
• Hardest part is predicting how long each task takes.
• Tasks are either:
o Short & well known.
o Long & highly uncertain.

• Steps to Minimize risk:

o Get experience (find someone with experience).
o Break tasks into simpler pieces (smaller = more predictable).
o Look for similarities (between unknown & already performed tasks).
o Expect the unexpected (expand each task estimate by an amount).
o Track progress.
▪ Act if a task isn’t going as planned.
▪ Don’t ignore problems & don’t hope to make up for lost time.
▪ Don’t pile extra devs on a delayed task (it will be delayed more).
Risk management.
• Identifying possible risks, determining their potential impact & finding
possible solutions.
• You should determine (for each task):
o Likelihood.
▪ How much do you know about this task.

o Importance.
▪ Can users live without this feature.
▪ Can you cancel this feature or add it later (update).

o Consequences.
▪ Will problems with this task affect other tasks.

o Solutions.
For each solution consider:
▪ Difficulty.
▪ Impact (does it affect usability || extra work for the users).
▪ Pros (advantages).
▪ Cons (disadvantages).
 Chapter 2: requirement gathering.
Requirements: features that your app must provide.
• Used to verify that the finished app does what it’s supposed to.

Requirement properties.
• Clear.
o Needs to be clear, brief, easy to understand.
o Common abbreviations & terms are okay.

• Unambiguous.
o Avoid requirements that have more than one meaning.
• Consistent.
o Requirements can’t contradict each other.
o Requirement shouldn’t provide a lot of constraints.
o “Fast, good, cheap. Pick two”.
▪ Quick app with high quality & high cost (Fast & good & !cheap).
▪ Quick app with low quality & low cost (Fast & !good & cheap).
▪ High quality & low cost but takes long time ( !Fast & good & cheap).
o Rewrite older requirements if needed.

• Prioritized.
o Prioritize requirements with high cost as low priority.
o “Must” & “Should” features should be assigned costs.
MOSCOW method:
o Required features (M-Must).
▪ Could you remove the requirement?
▪ Will the app be usable without that feature?
▪ Will the users give bad reviews (0 || 1 stars)?

o Important features (S-Should).

▪ Does the feature enhance the product?
▪ If it was removed, will users ask for it?
▪ Is it common in similar apps? Will reviews be bad (2 || 3 stars)?
 o Desirable features (C-Could).
▪ Is the feature useful to the users?
▪ Is it special (other apps don’t have it)?
▪ Will it increase reviews (4 || 5 stars)?

o Optional features (W-Won’t).

▪ Is it unnecessary, confusing, stupid?
▪ Is it rarely used?
▪ Does it add nothing to the app?

• Verifiable.
o Requirements must be limited & precisely defined to be verifiable.
o Requirements can’t be open ended.
o Words to avoid:
▪ Comparatives (faster, better, more, etc.) replaced with quantities.
▪ Imprecise adjectives (fast, robust, user-friendly, etc.).
▪ Vague commands (minimize, improve, etc.) replaced with numbers.

Requirement Categories.
Audience-oriented requirements.
• Focus on audiences & their different POVs.
Audiences:
• Business requirements.
o Lays the project’s high-level goals.
o Explains the customers’ hopes.
o Hopes might be too far-fetched.

• User (stakeholders) requirements.

o How end users will use the project.
o Requirements are very detailed.
o Specify what users want but not how.
o Sometimes it’s too detailed and it makes the designers have no choice.
 • Functional requirements.
o Detailed statements that include things the user won’t see directly.

• Non-functional requirements.
o Focuses on the quality of the app’s behavior.
o OR constraints on how it produces results.
o Specify:
▪ Application’s performance.
▪ Reliability.
▪ Security characteristics.

• Implementation requirements.
o Temporary features.
o Needed to transition to a new system (how to move from one system to
another).
o Hiring new people || training users.

FURPS.
• Functionality.
o What the application should do.
o Describe the system’s general features (What is does, how it interfaces
with other systems, Security).

• Usability.
o What the program should look like.
o Describe user-oriented features (app’s general appearance, ease of use,
navigation, responsiveness).

• Reliability.
o How reliable the system should be.
o Indicate when system is available, how often it can fail, how accurate is
the system.
 • Performance.
o How efficient the system should be.
o Describe app speed, memory usage, disk usage, database capacity.

• Supportability.
o How easy it is to support the app.
o Include how easy it is to maintain, how easy to test the code, how
flexible is the app.
FURPS+.
An extended version of FURPS.
• Design constraints.
o Hardware platform.
o Software platform.
o Network characteristics.
o Database.

• Interface requirements.
o Constraints on the system’s interfaces (with other systems).
o Identify which other systems will exchange data with our system.
o Describe (interaction kinds, when interactions occur, data format).

• Physical requirements.
o Constraints on the hardware & physical devices.
Common requirements.
• Screens (what type is needed).
• Menus.
• Navigation (how the user navigates through different parts).
• Workflow (how does data move through the system).
• Login (how login info is stored & validated, password rules).
• User types (different privileges).
• Audit tracking & history (does the sys track who changed data).
• Archiving (archiving old data, moving data for analysis).
• Configuration/settings (config screens for admins).
 Gathering requirements.
How to extract the requirements from the customers.
Techniques:
• Listen to customers (& users).
• Use Five Ws & H.
o Who will use the software.
o What the customer needs the app to do.
o When is the app needed.
o Where is the app used.
o Why the customers need the app.
o How does the customer want the app to function/look.

• Study cases.
o Studying users as they work to learn about their needs & how they
currently deal with those needs.
o Better than interviewing because the users will often leave/forget
important details.

• Copy existing systems.

o Use existing behaviors as requirements for the new system.

Refining requirements using brainstorming.

• Brainstorm exercises are recommended for converting collected goals into
innovative requirements.
• Never judge/critique/review someone’s idea (they may stop participating).
• Steps:
o Gather as many ideas as possible.
o Assemble a large list of possible ideas.
o Examine the list more closely to see which deserves further work.
o Get a diverse group of participants who have interest in the project
(programmers, users, customers, designers, etc.).
o Get as many viewpoints as possible.
o Brainstorming becomes less effective if the group is larger than 10 || 12.
 • Brainstorming Rules:
o Focus on quantity.
▪ More ideas = higher chance of finding creative solution.

o Withhold criticism.
▪ Criticism can make people stop contributing & bad ideas can lead to
better ideas.

o Encourage unusual ideas.

▪ You can tone down unusual ideas but it’s harder to do the opposite.

o Combine & improve.

▪ Form new ideas by combining other ideas || using an idea to modify
other ideas.

Recording requirements.
• Requirements should be written as a sequence of English instructions.

Unified Modeling Language (UML).

• Uses several kinds of diagrams to represent different pieces of the system.
o Can represent program items, behaviors, and data flows.
• Specifies how parts of the system should work.

User Stories.
• A short story explaining how the system will let the user do something.

Use Cases.
• A description of a series of interactions between actors.
• Actors can be users || application parts.
• Has a larger scope than a user story.
• Follow a template more than user stories.
 • Use case template:
o Title: name of the goal (includes action name + main actor).
o Main success scenario: a sequence of steps describing the most normal
scenario to achieve goal.
o Extensions: sequence of steps describing other scenarios.

Prototypes.
• A mockup of some or all of the application.
• Gives the customer a feel of how the app will look like & how it will behave.
• Used to get text descriptions from the user (user stories || use cases).
• Different prototypes:
o Non-functional prototype.
▪ Elements (buttons, menus, etc.) don’t do anything.

o Functional prototype.
▪ Looks & acts close to how the finished app will.

o Throwaway prototype.
▪ Any prototype that starts from scratch.

o Evolutionary prototype.
▪ A prototype that starts with simple code & fake data that then get
replaced by quality code & real data.
▪ Eventually becomes the finished application.

Validation & Verification.

Validation: are we doing the right things?
Verification: are we doing the things right?
 Chapter 3: High-Level Design (HLD).
• HLD provides a view of the system (abstract level).
• Divides the system into small pieces (pieces are given to different teams).
• They don’t focus on how things will work.
• Shows how pieces will fit & interact with each other.
• They specify assumptions about the environment (hardware & software).
What HLD specifies:

Security:
• HLD should sketch all security needs.
• All forms of security interact with each other.
• Security needs:
o Operating system security.
▪ Login procedure type (password, pin, …).
▪ Password expiration policies.
▪ Password standards.

o Application security.
▪ Users should have the right access level.
▪ Some apps rely on the OS’s security.

o Data security.
▪ Make sure data doesn’t reach hackers (ex. credit card info).

o Network security.
▪ Protect data against cyber hackers.

o Physical security.
▪ Protect devices in case they are stolen.
Hardware.
• HLD specifies what hardware will be used.
• Hardware specifications:
o Printers.
o Network components.
o Servers.
o Specialized hardware (scales, microscopes, …).
o Audio & video hardware.

User interface (users & app).

• Indicate the navigation styles.
• Specify the forms used & verify if they do the required tasks.
• Include all the needed forms (from user stories & use cases).
• May include:
o Special features (clickable maps, important tables).
o Methods for specifying system settings (sliders, scroll bars).
o Appearance (Color schemes, Logo placement, Form templates).

Internal interfaces (among app modules).

• After dividing the system, specify how pieces/modules will interact.
o Specifications must be clear & unambiguous.
o Allows teams to work independently.

External interfaces.
• Easier to specify than internal interfaces.
o You don’t control both ends (you must meet the other end’s
requirements).
 Architecture.
• The architecture describes how modules fit together.
• Some architectures attempt to simplify development.
Architecture types:
1) Monolithic.
• A single program does everything.
• Disadvantages:
o System pieces are tied closely together.
o Not flexible.
• Advantages:
o Doesn’t need complicated communication.

2) Client/server (multi-tier architecture).

• Separates parts that provide functions (servers) from the ones that
need them (clients).
• Doesn’t allow multiple users to use the app (Dis-adv).
• Two-tier architecture: solves the disadvantage of the
client/server archt.
o Clients are separated from the server.
o Clients & servers communicate through a network.
• Three-tier architecture: a middle tier is inserted between both tiers.
o Can run on the same device as the server.
o Can be used to secure the database.

3) Component-based (CB).
• Used in component-based software engineering (CBSE).
• The system is a collection of loosely coupled components.
• Separates pieces of code (same as multi-tier client/server).
o All pieces are in the same program.

4) Service oriented (SO).

• Close to CB but pieces are implemented as services.
• Service: a self-contained program that provides a service for clients.
 5) Data-centric (DC).
• Uses data in some central way.
• Data-centric designs:
o Store data in relational database systems.
o Using procedures to perform calculations & implement business
logic.

6) Event-driven (ED).
• Pieces respond to events as they occur.

7) Rule-based (RB).
• Uses a collection of rules to decide what to do next.
• Sometimes referred to as expert systems || knowledge-based systems.
• Needs the programmer to identify the necessary rules for each job.
• Has trouble handling unexpected situations.

8) Distributed.
• Pieces run on different processors & can run concurrently.
• Processors are on different computers on the same network.
o Processors can be different cores on a single computer.
• SO, CB, & multi-tier are often distributed.
• Disadvantages:
o Extremely confusing.
o Hard to debug.
o Processor competition (Race condition).

9) Mix & match.

• Using different architectures in the same system.

Reports.
• business apps might include reports (about costumers, products, users, …).
Other outputs.
• include:
o printouts.
o Webpages.
o Data files.
o Image files, Audio, Video.
o Output to special devices.
o Email or text messages.
Database.
• Decide what kind of database is needed & how data is going to be stored.
• Sketch out the tables for relational databases.
Database normalization:
• The process of decomposition (breaking tables into small tables & linking
them).
• Advantages:
o Avoids redundant data in tables.
o Ensures that separate tables data can be maintained & updated
separately.
o Facilitates a distributed database.
• Steps:
o Remove multiple value cells.
o Move repeating values into different tables.
o Create new tables to reduce redundancy.
Relationship types:
• One-to-one relationship:
o one record (table 1) is related to one record (table 2).
• One-to-many relationship:
o One record (table 1) is related to many records (table 2).
• Many-to-one relationship:
o Many records (table 1) are related to one record (table 2).
• Many-to-many relationship:
o Many records (table 1) are related to many records (table 2).
Database issues:
• Audit trails.
o Audit trail: keeps track of each user who modifies a record.
o Not needed in every application.
o Simple version:
▪ Create history table.
▪ Containing user’s name, link to the record, and the data.
o Advanced version:
▪ Stores copies of the original data in the original table.
▪ Might have notes section (to explain the changes).
• User access.
o Providing users with different access levels (to the data).
o Simple version:
▪ Create an access level table.
▪ List the users & their access levels.
o Some databases have it built in.
• Database maintenance.
o Removing old data (increases responsiveness).
o Re-indexing key tables (restores peak performance).
o Designing a database backup & recovery scheme.
o Move older data into a secondary database (improves responsiveness &
the data can be used for analysis).

Configuration data.
• Provide configuration screens to users.
• Reduces the need to write new code.
• Provide different access levels to these configurations.

Data flows & states.

• Specify the data flow between different processes.
• Events might make the data take different paths.
Training.
• Describe how training should be (online, using manuals, with instructors).
 Unified Modeling Language (UML):
• A general-purpose modeling language.
• Used to represent different system pieces.

Structure diagrams:
• Describes things/objects that will be in the system.
Types:
• Class diagram:
o Most basic structure diagram.
o Describes things/objects that make the system using classes, attributes,
methods, and relationships.
o Class: a collection of related properties.
▪ Class name is a noun.
o Objects: an instance of a class.
o Method: a routine that makes an object do something.
o Access modifiers symbols: a symbol that is used to represent access
modifiers.
o Relationships are represented using a line, an arrow, and a label.
▪ Label is a verb.
o Multiplicity: a number placed at both ends of a relationship
that indicates now many objects are involved in the
relationship.
o Can get complicated and devs separate it into different diagrams.

• Object diagram:
o Shows how objects interact with each other and what values they
contain at specific times.
• component diagram:
o Shows how components form larger parts of the system.
o Each component provides at least one interface.
▪ Used by other interfaces to interact with it.
o Complex components: components that include other
components.
o Components/symbols (go to page 76 for a full list):
▪ Structured classifier: represents a class.
▪ Part: represents a role played at runtime by one or more instances.
▪ Port: an interaction point used to connect classifiers with parts &
the environment.
▪ Connector: binds two or more entities together.
▪ Collaboration: more abstract than a classifier.

• composite diagram:
o Shows the class’s internal structure & the collabs that the
class allows.

• package diagram:
o Describes relationships among the system packages.

• deployment diagram:
o Describes the deployment of artifacts on nodes that can execute those
artifacts.
▪ Application artifacts (files, scripts, exe files, …).
▪ Framework artifacts.

• profile diagram:
o allows the designer to extend the basic UML notations
(adding labels & comments).
 Behavior diagrams.
Activity diagram.
• Represents workflows for activities/tasks.
• Uses symbols & arrows to show the workflow.

Use case diagram.

• Represents user interactions with the system.
• Represents users with stick figures.
• <<include>> indicates that a task includes subtasks.
• <<extend>> a subtask that might occur based on the main task.
• Use dashed lines with <<include>> & <<extend>>.

State machine diagram.

• Shows the state of an object after each event.
• Representation:
o States = rounded rectangles.
o Transitions = arrows.
▪ Labels are used to show the cause of the transition.
o Starting state = black circle.
o Stopping state = circled black circle.

Interaction diagrams.
• A subset of activity diagrams.
• Include:
o Sequence diagrams.
o Communication diagrams.
o Timing diagrams.
o Interaction overview diagrams.
Sequence diagram.
• Shows how objects/actors collab in a specific scenario.
o Includes the interactions & their order.
• Represents the collab as a series of messages.
• Focuses on the message sequence.
• Representation:
o Objects = rectangles.
o Actors = stick figures (with class name and/or actor name).
o Execution = white || gray rectangle on top of lifeline.
o Synchronous messages = arrows with solid heads.
o asynchronous messages = arrows with open heads.
o Return messages = dashed arrows with open heads.
• Lifeline: a vertical dashed line that shows the active time of objects.
• execution: represents the actor/object doing something.

Communication diagram.
• Shows the communications between objects during a collab.
• Focuses on the objects.
• Representation:
o Lines to connect objects.
o Messages = labeled arrows.
▪ Messages are numbered.

Timing diagram.
• Shows state changes of multiple objects over time.
• Looks Like the sequence diagram (rotate the sequence 45
degree).
• Gives a sense of how long objects in a scenario will take.
• Advanced versions show multiple objects stacked over each
other.
Interaction overview diagram.
• An activity diagram where nodes can
contain other diagrams.
• Shows more details for nodes with
complicated tasks.
 Chapter 4: Low-Level Design (LLD).
• LLD focuses on how to implement what HLD specified.
• Provides more details to start implementation.

Object-oriented design.
• HLD specified the major classes, LLD identifies specific extra classes.
• New classes include properties, methods, and events (that they provide).
Defining new classes:
• Identifying classes.
o Look for nouns in feature descriptions.
o For each class think about:
▪ What info it needs (properties).
▪ What will it do (methods).
▪ Does it notify the system (events).

o Change useless classes to variables (don’t provide methods/events &

have a single variable).
o Don’t add classes/attributes that objects won’t use.

• Building inheritance hierarchies.

o Use inheritance to differentiate between related classes (increases
code reuse).
o Use polymorphism to treat related objects as if they were from the
same class (common superclass).
o Refinement:
▪ Breaking parent classes into multiple sub-classes.
▪ Captures some differences between objects.
▪ Over refinement: making too many subclasses that make
implementation more complicated & confusing.
▪ Focus on behavioral differences instead of looking at different
properties to avoid problems.
 o Generalization:
▪ Looks at a group of classes and creates a parent class to represent
common features (opposite of refinement).

o Hierarchy warning signs:

▪ The hierarchy is tall and thin || short and wide.
• Get rid of some classes to balance it.
▪ contains a large number of classes.
• See if you can replace some with attributes.
▪ Having a class that has one subclass.
• Move them together.
▪ Having classes that are never instantiated (remove them).
▪ Having classes that don’t make sense in the current hierarchy.
• Rename or move them.

• Object composition.
o Using existing classes to build more complex classes.
▪ existing classes are attributes in the complex classes.
▪ Increases code reuse.
 Database design.
• The most popular type is the relational database.
• Bad DB problems/anomalies:
o Duplicate data (waste space & slows updating).
o May be unable to delete some data without deleting another data
that’s unrelated.
o Some data require other data to be usable.
o DB may not allow multiple values when you need them.
• DB normalization: process of re-arranging a DB & using a standard form.
o Prevents anomalies.

• Normalization levels:
o First Normal Form (1NF) rules:
▪ Relational DBMS enforce them automatically.
▪ Each column must have a unique name & a single datatype.
▪ Each record must be unique.
▪ Each column must have a single value.
▪ Each table cell shouldn’t be null.

o Second Normal Form (2NF) rules:

▪ Apply 1NF first.
▪ All non-key columns should depend on key columns (reduces
redundancy).

o Third Normal Form (3NF) rules:

▪ Apply 2NF first.
▪ Remove transitive functional dependencies (reduces redundancy).
• changing a non-key column might change other non-key
columns.