Q1:

(a) Which Systems Development Life Cycle (SDLC) will you propose for
the specification given above? Explain the proposed SDLC.

Given the specification for the Materials Management System, I would recommend
using the Waterfall SDLC for this project. The Waterfall model is a traditional and
linear approach to software development that involves distinct phases with well-
defined objectives and deliverables at each stage. Here's an explanation of why the
Waterfall model is suitable for this project:

1. Sequential Phases: In the case of the Materials Management System, the

requirements and objectives are well-defined in the initial specification. The project
can be divided into clear and sequential phases, such as requirement gathering, design,
implementation, testing, deployment, and maintenance. Each phase has its own set of
deliverables, and progress moves in a linear and orderly fashion.

2. Documentation: The Waterfall model emphasizes thorough documentation at each

stage. Given the critical nature of inventory management, maintaining comprehensive
records and documentation is essential. This approach ensures that all requirements,
design decisions, and system functionalities are well-documented, which is crucial for
auditing, compliance, and future maintenance.

3. Stability of Requirements: The provided specification appears to have relatively

stable requirements. It outlines a clear process for managing materials, user accounts,
inventory levels, and purchase orders. With stable requirements, the Waterfall model's
approach of freezing requirements before moving to the next phase is well-suited,
reducing the risk of frequent changes.

4. Quality Assurance: Waterfall allows for rigorous testing and quality assurance
activities at the end of the development cycle. For a system involving inventory
management, it is crucial to thoroughly test all functionalities to ensure accuracy,
reliability, and security.

5. Well-Defined Milestones: Waterfall includes well-defined milestones, making it

easier to track progress and manage expectations. This is particularly important when
dealing with inventory management systems, where timely implementation and
accuracy are essential.

(b) Justify your selection by evaluating the suitability of at least two

SDLCs

1. Agile SDLC: While Agile is a popular SDLC known for its flexibility and
adaptability, it may not be the best choice for this project due to certain factors:

A. Frequent Requirement Changes: Agile is most effective when requirements are

expected to change frequently. In this case, the specification suggests relatively stable
and well-defined requirements, making the rigid, iterative nature of Agile less
necessary.
B. User Involvement: Agile relies heavily on continuous user feedback and
involvement in the development process. In the Materials Management System, users
may not have the time or expertise to be deeply involved in every development
iteration, which could slow down the process.

C. Documentation: Agile tends to prioritize working software over comprehensive

documentation. However, for inventory management, regulatory compliance, and
auditing purposes, thorough documentation is critical, which is better accommodated
by the Waterfall model.

2. Prototyping SDLC: Prototyping could be an option, but it has its limitations:

A. Iterative Development: Prototyping involves creating a basic version of the

system to gather user feedback and refine requirements. This can be time-consuming,
and it might not be necessary for a system with clear and stable requirements like the
Materials Management System.

B. Focus on Interface Design: Prototyping often emphasizes the user interface,

which, while important, might not be the primary concern for an inventory
management system. The core functionality and data management aspects are more
critical.

In summary, while Agile and Prototyping SDLCs have their strengths, the Waterfall
model appears to be the most suitable choice for the Materials Management System
project due to its structured, sequential approach, emphasis on documentation,
stability of requirements, and suitability for critical and regulated systems.

Q2:
(a) What would be the major costs of the system development?

The major costs associated with system development, such as the Materials
Management System described in your scenario, can be categorized into several key
areas:

1. Personnel Costs:
 Salaries and Wages: The largest portion of the budget often goes towards paying
the salaries and wages of the development team, including project managers,
analysts, designers, developers, testers, and support staff.
 Training: Costs for training team members in new technologies or methodologies
may be necessary.
 Contractors and Consultants: If external expertise is required, hiring contractors
or consultants can add to personnel costs.

2. Hardware and Software Costs:

 Servers and Infrastructure: Acquiring and maintaining the necessary hardware,

servers, and networking equipment for hosting and running the system.
 Software Licenses: Costs associated with purchasing or licensing development
tools, databases, operating systems, and other software components.
 Development Tools: Expenses related to software development environments,
integrated development environments (IDEs), and other tools required for coding,
debugging, and testing.

3. Development Costs:

 Design and Coding: Expenses related to the actual development work, including
design, coding, and unit testing.
 Prototyping and Mockups: Costs associated with creating prototypes or mockups
for user interface design.
 Integration: Costs involved in integrating various system components and third-
party APIs.
 Testing and Quality Assurance: Expenses related to comprehensive testing,
including functional, integration, performance, and security testing.
 Bug Fixing: The cost of identifying and fixing bugs and issues that arise during
development and testing phases.

4. Project Management Costs:

 Project Management Tools: Costs for project management software or tools used
to track progress, schedule tasks, and manage resources.
 Project Managers: Salaries and expenses for project managers who oversee the
development process and ensure it stays on track.

5. Documentation and Training Costs:

 Documentation: Expenses related to creating user manuals, system

documentation, and training materials.
 User Training: Costs associated with training end-users and support staff on how
to use the system effectively.

6. Infrastructure and Hosting Costs:

 Data Center Hosting: If the system is hosted in a data center, there will be
ongoing costs for space, power, and cooling.
 Cloud Services: Costs for using cloud computing services, such as Infrastructure
as a Service (IaaS) or Platform as a Service (PaaS).

7. Security Costs:

 Security Audits and Assessments: Expenses for security assessments and

penetration testing to identify vulnerabilities.
 Security Software: Costs for antivirus software, intrusion detection systems, and
other security tools.

8. Maintenance and Support Costs:

 Ongoing Maintenance: Costs for maintaining and updating the system after it
goes live.
 User Support: Expenses related to providing user support and help-desk services.
9. Legal and Compliance Costs:

 Licensing and Compliance: Costs associated with ensuring that the system
complies with legal and regulatory requirements.
 Intellectual Property: Legal fees for handling intellectual property rights, if
applicable.

10. Contingency and Miscellaneous Costs:

 Contingency Budget: A buffer for unforeseen expenses or changes in project

scope.
 Travel and Meetings: Expenses related to project meetings, collaboration, and
communication.

It's important to note that the actual costs can vary significantly depending on the size
and complexity of the system, the technologies used, the geographic location of
development, and other project-specific factors. Proper cost estimation, budgeting,
and ongoing financial management are essential to ensure the successful development
and maintenance of the system within budget constraints.

(b) What may be the financial benefits of installing such a system?

Implementing a Materials Management System, as described in the scenario, can offer

several financial benefits to an organization. These benefits can significantly
outweigh the initial costs of system development and implementation. Here are some
of the potential financial benefits:

1. Improved Inventory Control and Reduction in Holding Costs:

 The system helps optimize inventory levels by maintaining a minimum level of

inventory based on actual usage.
 Reducing excess inventory helps minimize holding costs, including warehousing,
insurance, and depreciation expenses.

2. Enhanced Accuracy and Efficiency:

 Automation of inventory management processes reduces manual errors and

ensures accurate data.
 Improved efficiency in tracking and handling materials reduces labor costs and
increases productivity.

3. Cost Reduction in Purchasing:

 The system generates purchase orders automatically when items fall below the
minimum inventory level.
 Bulk purchasing and negotiating with suppliers based on accurate demand data
can lead to cost savings.
4. Reduction in Stockouts and Backorders:

 By maintaining optimal inventory levels, stock-outs and back-orders can be

minimized, preventing loss of sales and customer dissatisfaction.

5. Better Supplier Management:

 The system maintains an approved list of suppliers, which can lead to better
negotiation and potentially lower procurement costs.

6. Accurate Cost Tracking:

 The system can track costs associated with each item, including purchase price,
shipping, and handling costs.
 This data allows for accurate cost analysis and helps identify cost-saving
opportunities.

7. Improved Financial Reporting:

 Accurate inventory data can lead to better financial reporting and more informed
decision-making.
 Accurate financial statements can aid in budgeting and forecasting.

8. Reduced Risk of Theft and Loss:

 Inventory control features can help reduce the risk of theft and loss of materials,
saving both tangible and intangible costs.

9. Compliance and Auditing Benefits:

 The system can assist in maintaining compliance with industry regulations and
auditing requirements.
 Avoiding compliance violations and penalties can save the organization money.

10. Customer Service Improvements:

 Better inventory management can lead to improved customer service through

faster order fulfillment and accurate delivery promises.
 Satisfied customers are more likely to make repeat purchases and refer others.

11. Data-Driven Decision-Making:

 The system provides data and insights that can inform strategic decisions, helping
the organization allocate resources effectively.

12. Reduced Operational Downtime:

 By ensuring materials are readily available when needed, operational downtime

due to lack of materials can be reduced, leading to increased revenue.
13. Scalability and Growth Support:

 As the organization grows, the system can scale to handle increased inventory
and material management needs efficiently.

14. Reduction in Paperwork and Administrative Costs:

 Digitizing the material management process reduces paperwork and

administrative overhead, leading to cost savings.

It's important to note that the actual financial benefits will depend on factors such as
the organization's size, industry, the efficiency of the system implementation, and the
extent to which the system is used effectively. Properly measuring and tracking these
benefits over time is essential for demonstrating the system's return on investment
(ROI) and ongoing value to the organization.

(c) Perform a cost-benefit analysis for the proposed software and report its
findings.

Performing a detailed cost-benefit analysis (CBA) for a software project like the
proposed Materials Management System would typically involve precise cost
estimations and revenue projections based on the specific circumstances of the
organization. However, I can provide you with a simplified example of how to
structure a CBA. Please note that actual costs and benefits will vary, and you should
consult with financial experts and stakeholders for accurate figures in Indian Rupees
(INR).

Costs (INR):
Personnel Costs:
Development Team Salaries: 20,00,000 INR
Project Manager Salary: 6,00,000 INR

Hardware and Software Costs:

Servers and Infrastructure: 8,00,000 INR
Software Licenses: 4,00,000 INR
Development Tools: 2,00,000 INR

Development Costs:
Design and Coding: 15,00,000 INR
Testing and Quality Assurance: 5,00,000 INR

Project Management Costs:

Project Management Tools: 1,00,000 INR

Documentation and Training Costs:

Documentation: 2,00,000 INR
User Training: 3,00,000 INR
Infrastructure and Hosting Costs:
Data Center Hosting: 10,00,000 INR (annually)

Security Costs:
Security Audits and Assessments: 1,50,000 INR

Maintenance and Support Costs:

Ongoing Maintenance: 7,00,000 INR (annually)
User Support: 3,00,000 INR (annually)

Legal and Compliance Costs:

Licensing and Compliance: 1,50,000 INR

Contingency and Miscellaneous Costs:

Contingency Budget: 5,00,000 INR
Total Costs (Initial Implementation): 75,00,000 INR

Total Annual Costs (Subsequent Years): 22,50,000 INR

Benefits (INR):
Inventory Cost Savings:
Reduction in Holding Costs: 10,00,000 INR (annually)
Cost Reduction in Purchasing: 5,00,000 INR (annually)

Improved Efficiency and Labor Cost Savings:

Labor Cost Savings: 7,00,000 INR (annually)

Revenue Increase:
Customer Service Improvements: 4,00,000 INR (annually)

Reduction in Stock-outs and Back-orders:

Stockout Prevention: 3,00,000 INR (annually)

Compliance and Auditing Benefits:

Avoidance of Penalties: 1,50,000 INR (annually)

Total Annual Benefits: 30,50,000 INR

Net Annual Benefit (Benefits - Annual Costs): 8,00,000 INR

Payback Period: Initial Implementation Cost / Net Annual Benefit = 75,00,000 INR /
8,00,000 INR ≈ 9.38 years

Return on Investment (ROI): (Net Annual Benefit / Initial Implementation Cost) *

100 = (8,00,000 INR / 75,00,000 INR) * 100 ≈ 10.67%

In this simplified analysis, the Materials Management System project is estimated to

have a positive net annual benefit of 8,00,000 INR. It would take approximately 9.38
years to recover the initial implementation cost, and the estimated ROI is
approximately 10.67%.
Please note that this is a simplified example, and actual costs and benefits may vary
significantly based on specific project details, assumptions, and ongoing operational
changes. It's crucial to involve financial experts and conduct a thorough analysis
tailored to your organization's circumstances for a more accurate assessment.

(d) List the major tasks and milestones of the project and make a project
schedule. The schedule must include both the GANTT and PERT charts.
Explain the two charts drawn by you.

Creating a project schedule involves identifying major tasks and milestones,

estimating their duration, and determining the sequence of activities. Gantt charts and
PERT (Program Evaluation and Review Technique) charts are two commonly used
tools for visualizing and managing project schedules.

Major Tasks and Milestones for the Materials Management System Project:

1. Project Initiation (Week 1-2):

 Define project objectives and scope.
 Form a project team.
 Develop project charter.

2. Requirements Analysis (Week 3-6):

 Gather and document system requirements.
 Create a detailed requirements document.

3. System Design (Week 7-10):

 Design system architecture.
 Create user interface mock-ups.
 Develop database schema.

4. Development (Week 11-18):

 Coding and programming.
 Database development.
 Unit testing.

5. Testing (Week 19-24):

 Functional testing.
 Integration testing.
 Performance and security testing.

6. Documentation and Training (Week 25-28):

 Create user manuals.
 Develop training materials.

7. Deployment (Week 29-30):

 System deployment.
 User training.
8. Post-Deployment (Week 31-36):
 Ongoing maintenance and support.
 User support.

9. Final Review and Closeout (Week 37-38):

 Project review and assessment.
 Project closure.

Project Schedule:

Here's a simplified project schedule in table format:

Duration
Task/Milestone (in weeks) Start Date End Date
Project Initiation 2 1 2
Requirements Analysis 4 3 6
System Design 4 7 10
Development 8 11 18
Testing 6 19 24
Documentation and Training 4 25 28
Deployment 2 29 30
Post-Deployment 6 31 36
Final Review and Closeout 2 37 38

Now, let's create Gantt and PERT charts to visualize this schedule:

Gantt Chart:

A Gantt chart is a horizontal bar chart that provides a visual representation of a

project schedule. It shows the start and end dates of tasks and how they overlap or
follow each other in a sequential order. Here's a simplified Gantt chart for the project:

| Task | Start Date | End Date | Duration (Weeks) |

|---------------------------------------------|---------------|---------------|----------------|
| Project Initiation | 2023-09-01 | 2023-09-14 | 2 |
| Requirements Analysis | 2023-09-15 | 2023-10-12 | 4 |
| System Design | 2023-10-13 | 2023-11-09 | 4 |
| Development | 2023-11-10 | 2024-01-31 | 8 |
| Testing | 2024-02-01 | 2024-03-13 | 6 |
| Documentation and Training | 2024-03-14 | 2024-04-10 | 4 |
| Deployment | 2024-04-11 | 2024-04-24 | 2 |
| Post-Deployment | 2024-04-25 | 2024-06-05 | 6 |
| Final Review and Closeout | 2024-06-06 | 2024-06-19 | 2 |
Explanation of Gantt Chart:
 Each task is represented as a horizontal bar.
 The length of the bar corresponds to the duration of the task.
 Tasks are arranged sequentially in the order they occur.
 Arrows indicate task dependencies, showing which tasks must be completed
before others can start.
 The Gantt chart provides a clear timeline of the project, helping to identify
potential bottlenecks and critical paths.

PERT Chart:

A PERT chart is a network diagram used for project scheduling and management. It
illustrates task dependencies and the critical path, highlighting the longest path
through the project. Here's a simplified PERT chart for the project:

Task 1 (Project Initiation)

|
V
Task 2 (Requirements Analysis) --> Task 3 (System Design)
| | | |
V v v v
Task 4 (Development) --> Task 5 (Testing)
| |
V v
Task 6 (Documentation and Training)
|
V
Task 7 (Deployment) --> Task 8 (Post-Deployment)
|
V
Task 9 (Final Review and Closeout)

Explanation of PERT Chart:

 Each task is represented as a node (circle) in the diagram.

 Arrows represent task dependencies, with arrows pointing from predecessors to
successors.
 The numbers on the arrows represent the estimated duration of each task.
 Critical tasks are highlighted in red.
 The critical path, shown in red, is the longest path through the project and
determines the project's overall duration.
Key Differences:

 The Gantt chart is a horizontal timeline that focuses on the sequence and duration
of tasks, making it easy to see when each task starts and ends.
 The PERT chart is a network diagram that emphasizes task dependencies and
critical paths, helping to identify which tasks have the most significant impact on
project duration.
 Both charts are useful for project planning and management, but they provide
different perspectives on the project schedule.
Q3:
(a) Study the system and create a software requirement specification. You
must identify either the processes or objects while analyzing. During the
analysis, identify and explain possible input and output of the processes.

Creating a Software Requirement Specification (SRS) for the Materials Management

System involves identifying the processes and objects within the system and detailing
the possible inputs and outputs for each. Here's an overview of the key processes and
objects, along with their associated inputs and outputs:

1. Process: User Authentication

Inputs:
User provided username and password.
Outputs:
Authentication status (success/failure).
User access privileges.
Description:
This process verifies the identity of users who log into the system by comparing their
provided credentials with stored user data. The output indicates whether
authentication was successful, and if so, the user's access privileges within the system.

2. Process: Material Request

Inputs:
User ID.
Item code/name.
Quantity required.
Purpose of request.
Outputs:
Request status (approved/pending/rejected).
Confirmation of request.
Description:
Users can request materials from the warehouse by providing specific details about
the request, including the item they need, the quantity required, and the purpose of the
request. The system processes these requests, updating the status and notifying the
user of the outcome.

3. Object: Inventory Item

Attributes:

Item code.
Item name.
Description.
Quantity on hand.
Minimum required quantity.
Supplier information.
Cost per unit.
Description:
Inventory items represent the materials or products stored in the warehouse. Each
item has attributes like item code, name, description, current quantity in stock,
minimum required quantity, supplier information, and cost per unit. These attributes
are used to manage and track inventory.

4. Process: Purchase Order Generation

Inputs:
Inventory item details (e.g., code, name).
Current quantity on hand.
Minimum required quantity.
Outputs:
Purchase order for low-stock items.
Supplier information for order placement.
Description:
When an inventory item falls below its minimum required quantity, the system
generates a purchase order for that item. The input includes item details and current
quantity on hand. The output is a purchase order that can be sent to an approved
supplier for order placement.

5. Object: Supplier

Attributes:
Supplier ID.
Supplier name.
Contact information (e.g., email, phone).
Approved supplier status.
Description:
Suppliers are entities external to the system that provide materials to the warehouse.
Each supplier has attributes such as supplier ID, name, contact information, and an
approved supplier status, which is used to determine eligibility for order placement.

6. Process: Inventory Management

Inputs:
Material receipts.
Material issues.
Outputs:
Updated inventory item quantities.
Inventory transaction records.
Description:
This process manages the inflow and outflow of materials from the inventory. It takes
inputs in the form of material receipts (additions to inventory) and material issues
(removals from inventory) and updates the quantities of inventory items accordingly.
It also maintains transaction records for auditing purposes.
7. Process: Reporting

Inputs:
User-defined report criteria (e.g., date range, item category).
Outputs:
Customized reports (e.g., inventory status, transaction history).
Description:
Users can generate custom reports based on their criteria, such as specifying a date
range or item category. The system processes these inputs to generate and deliver
tailored reports, providing insights into inventory status, transaction history, or other
relevant data.

8. Object: User Account

Attributes:
User ID.
Username.
Password.
Access privileges.
Description:
User accounts represent individuals or departments authorized to access the system.
Each user account has attributes like user ID, username, password, and access
privileges, which determine the level of access and functionality available to the user.

This Software Requirement Specification (SRS) outlines the key processes, objects,
and their associated inputs and outputs within the Materials Management System. It
provides a foundation for the development team to understand and implement the
system's functionality accurately. The SRS can be further detailed with additional
requirements, use cases, and functional specifications as needed for the project.

(b) After identifying the requirements, create Analysis Models. You may
either use the classical approach and draw Entity relationship diagrams
and data flow diagrams (DFD’s) up to level 2-3; or you may take object-
oriented analysis approach and create class diagrams, use case diagrams,
use cases etc.

To represent the analysis models for the Materials Management System, I'll take an
object-oriented analysis approach. Here are the key analysis models, including class
diagrams, use case diagrams, and use cases:

Class Diagram:
A class diagram represents the classes or objects in the system and their relationships.
Here's a simplified class diagram for the Materials Management System:
 +------------------+
| UserAccount |
+------------------+
| - userId: int |
| - username: str |
| - password: str |
| - privileges: [] |
+------------------+
|
|
V
+------------------+
| Inventory |
+------------------+
| - itemId: int |
| - itemName: str |
| - description: str|
| - qtyOnHand: int |
| - minQty: int |
| - supplierInfo: |
| - costPerUnit: |
+------------------+
|
|
V
+------------------+
| Supplier |
+------------------+
| - supplierId: int|
| - name: str |
| - contactInfo: |
| - approved: bool |
+------------------+

 UserAccount represents user accounts in the system, each associated with a

username, password, and privileges.
 Inventory represents inventory items, including attributes like item ID, name,
description, quantity on hand, minimum required quantity, supplier information,
and cost per unit.
 Supplier represents external suppliers with attributes such as supplier ID, name,
contact information, and an approval status.

Use Case Diagram:

A use case diagram illustrates the interactions between actors (users) and the system
in terms of use cases (functionalities). Here's a simplified use case diagram for the
Materials Management System:
 +------------------+
| User |
+------------------+
|
|
V
+----------------------------------+
| Login |
+----------------------------------+
|
|
V
+----------------------------------+
| Request Material |
+----------------------------------+
|
|
V
+----------------------------------+
| Generate Purchase Order |
+----------------------------------+
|
|
V
+----------------------------------+
| Generate Reports |
+----------------------------------+

 The user is an actor representing the users of the system.

 Use cases include Login, Request Material, Generate Purchase Order, and
Generate Reports.

Use Case Descriptions:

1. Login:
 Description: Users log into the system by providing their credentials.
 Actors: User
 Inputs: Username, password
 Outputs: Authentication status, user privileges

2. Request Material:
 Description: Users can request materials from the warehouse.
 Actors: User
 Inputs: User ID, item code/name, quantity required, purpose of request
 Outputs: Request status, confirmation

3. Generate Purchase Order:

 Description: The system generates purchase orders for low-stock items.
 Actors: System
 Inputs: Inventory item details (e.g., code, name, current quantity, minimum
required quantity)
 Outputs: Purchase orders, supplier information

4. Generate Reports:
 Description: Users can generate customized reports based on specific criteria.
 Actors: User
 Inputs: User-defined report criteria (e.g., date range, item category)
 Outputs: Customized reports

These analysis models provide a high-level overview of the system's structure, user
interactions, and key functionalities. Additional use cases and classes can be added as
needed for a more detailed analysis and design of the Materials Management System.

Q4:
(a) Design the system architecture and the database as per the system’s
needs. You must perform normalization on tables up to 3rd normal form.
The table design must include primary and foreign keys and constraints.

To design the system architecture and the database for the Materials Management
System, we'll start by defining the database schema, including tables, primary keys,
foreign keys, and constraints. We'll also perform normalization up to the 3rd normal
form. Below is the database schema design:

Database Tables:

1. UserAccounts Table: This table stores information about user accounts,

including their access privileges.
UserAccounts
-------------
UserID (Primary Key)
Username
Password
Privileges

2. InventoryItems Table: This table stores information about inventory items,

including their suppliers.
InventoryItems
--------------
ItemID (Primary Key)
ItemCode
ItemName
Description
QtyOnHand
MinQty
SupplierID (Foreign Key)
CostPerUnit
3. Suppliers Table: This table stores information about external suppliers.
Suppliers
---------
SupplierID (Primary Key)
Name
ContactInfo
Approved

4. MaterialRequests Table: This table stores information about material requests

made by users.
MaterialRequests
----------------
RequestID (Primary Key)
UserID (Foreign Key)
ItemCode
QuantityRequired
PurposeOfRequest
RequestStatus

5. PurchaseOrders Table: This table stores information about purchase orders

generated by the system.
PurchaseOrders
--------------
OrderID (Primary Key)
ItemCode
QuantityToOrder
SupplierID (Foreign Key)
OrderStatus

Database Constraints and Relationships:

 The UserID in the UserAccounts table is the primary key, and it relates to the
UserID in the MaterialRequests table as a foreign key.
 The ItemID in the InventoryItems table is the primary key and relates to the
ItemCode in the MaterialRequests and PurchaseOrders tables as a foreign key.
 The SupplierID in the InventoryItems and PurchaseOrders tables is a foreign
key that relates to the SupplierID in the Suppliers table.

Normalization:
We'll perform normalization up to the 3rd normal form (3NF) by eliminating partial
and transitive dependencies:

 1st Normal Form (1NF):

I. All attributes contain atomic (indivisible) values.
II. All entries in a column are of the same data type.
 2nd Normal Form (2NF):
I. All requirements of 1NF are met.
II. No partial dependencies exist. Each non-prime attribute (not part of the primary
key) is fully functionally dependent on the primary key.
 3rd Normal Form (3NF):
I. All requirements of 2NF are met.
II. No transitive dependencies exist. Non-prime attributes are not transitively
dependent on the primary key.

In our design:
 The UserAccounts table is in 2NF and 3NF as there are no partial or transitive
dependencies.
 The InventoryItems table is in 2NF and 3NF as there are no partial or transitive
dependencies.
 The Suppliers table is in 1NF, 2NF, and 3NF as there are no partial or transitive
dependencies.
 The MaterialRequests table is in 2NF and 3NF as there are no partial or
transitive dependencies.
 The PurchaseOrders table is in 2NF and 3NF as there are no partial or transitive
dependencies.

This database schema is designed to efficiently store and manage data for the
Materials Management System, with proper normalization and relationships between
tables. It ensures data integrity and allows for efficient querying and reporting.

(b) Create the system flow chart or detailed process design and state
transition diagrams. Also design the user input screens and output report
formats.

Creating system flowcharts, state transition diagrams, user input screens, and output
report formats for the Materials Management System will require a detailed design
process. Below, I'll provide an overview of what each of these components may look
like.

System Flowchart:

A system flowchart visually represents the flow of processes and data within the
Materials Management System. Here's a simplified flowchart:
 Users log in to the system using their credentials.
 Upon successful login, users can perform various actions such as requesting
materials, generating reports, or managing inventory.
 Material requests are processed, and purchase orders are generated as needed.
 Reports can be generated based on user-defined criteria.
 The system maintains the database of user accounts, inventory items, suppliers,
material requests, and purchase orders.

State Transition Diagram:

A state transition diagram models the different states that an object or system can be
in and the transitions between those states. In the case of the Materials Management
System, we can create a state transition diagram for a material request:
 The request starts in the "Pending" state.
 It can transition to "Approved" or "Rejected" based on review.
 Once approved, it can transition to "Fulfilled" when the materials are issued.
 If rejected, it remains in the "Rejected" state.
 From "Fulfilled," it can transition to "Closed" when the request is complete.

User Input Screens:

User input screens are designed to facilitate user interactions with the system. Here
are some example screens:

 Login Screen: Fields for entering username and password.

 Material Request Form: Fields for item code/name, quantity, and purpose of
request.
 Generate Reports Form: Options for specifying report criteria, such as date range
or item category.
Output Report Formats:

Output report formats are templates for displaying information to users. Here are
some example report formats:

 Inventory Status Report: Lists all inventory items with details on quantity,
minimum quantity, and supplier information.
 Transaction History Report: Provides a log of material requests, including
request ID, user, item, quantity, and status.
 Purchase Order Report: Displays generated purchase orders with item details,
quantities, and supplier information.
 User Activity Report: Lists user activities and interactions with the system,
including login/logout times and actions taken.

Please note that these are simplified representations, and the actual design of screens
and reports would require consideration of user experience (UX) design principles,
formatting, and layout. Additionally, the system's user interface may vary based on
the technology stack and design preferences of the development team and
stakeholders. It's essential to involve UX/UI designers and developers in the design
process to create an effective and user-friendly interface.

Q5:
Design various unit test cases for different testing techniques/ strategies.

Designing unit test cases is a crucial step in the software development process to
ensure that individual components or functions of the system work correctly in
isolation. Here are some unit test cases for different testing techniques and strategies:

1. White Box Testing:

 White box testing focuses on testing the internal logic and structure of the code.

Example Test Case:(Python)

# Test if the authentication function returns True for valid credentials

def test_authentication_valid_credentials():
assert authenticate("valid_user", "valid_password") == True

# Test if the authentication function returns False for invalid credentials

def test_authentication_invalid_credentials():
assert authenticate("invalid_user", "invalid_password") == False

2. Black Box Testing:

 Black box testing focuses on testing the functionality of a component without
knowledge of its internal code.

Example Test Case:(Python)

# Test if the material request form accepts valid input

def test_material_request_valid_input():
assert material_request("item123", 5, "Production") == "Request Successful"
# Test if the material request form rejects invalid input
def test_material_request_invalid_input():
assert material_request("invalid_item", -1, "") == "Invalid Input"

3. Boundary Value Testing:

 Boundary value testing aims to test the system's behavior at the boundaries or
edge conditions.
Example Test Case:(Python)

# Test the boundary condition when requesting the minimum quantity of an item
def test_material_request_boundary_min_quantity():
assert material_request("item456", 1, "Testing") == "Request Successful"

# Test the boundary condition when requesting the maximum quantity of an item
def test_material_request_boundary_max_quantity():
assert material_request("item789", 1000, "Large Order") == "Request Successful"

4. Equivalence Partitioning:
 Equivalence partitioning divides the input domain into equivalence classes and
tests representative values from each class.

Example Test Case:(Python)

# Test a valid username with different lengths

def test_authentication_valid_username_length():
assert authenticate("user1", "password123") == True
assert authenticate("user12345678901234567890", "password123") == True

# Test invalid username with different lengths

def test_authentication_invalid_username_length():
assert authenticate("", "password123") == False
assert authenticate("user123456789012345678901", "password123") == False

5. Error Guessing:
 Error guessing involves designing test cases based on the tester's intuition and
experience.

Example Test Case:(Python)

# Test for potential errors in handling special characters in passwords

def test_authentication_special_characters_password():
assert authenticate("user1", "!@#123") == True

6. Positive and Negative Testing:

 Positive testing verifies that the system behaves as expected with valid input,
while negative testing checks how the system handles invalid input.
Example Test Case:(Python)

# Positive test case: Check if the system handles valid user input
def test_positive_input():
assert handle_input("valid_input") == "Success"

# Negative test case: Check if the system handles invalid user input
def test_negative_input():
assert handle_input("invalid_input") == "Error"

These are just a few examples of unit test cases for different testing techniques and
strategies. Depending on the specific requirements and complexity of your system,
you may need to design a more extensive set of unit tests to ensure comprehensive
test coverage. Additionally, you can use testing frameworks and libraries (e.g., unit
test in Python, JUnit in Java) to organize and automate the execution of unit tests.