Core Concepts in Software Development and Analysis

Posted on Dec 26, 2025 in Business and Technology

Data Dictionary

A data dictionary is a centralized repository that defines the structure, relationships, and attributes of data elements used in a system. It includes names, types, sizes, allowable values, and descriptions of each data element. Used in databases and software development, it ensures consistency, clarity, and data integrity. It serves as a reference for developers, analysts, and stakeholders, improving communication and system documentation.

Function Point vs. Lines of Code (LOC)

• 1. Definition: FP measures software size by functionality, while LOC measures size by counting code lines.
• 2. Language Dependency: FP is independent of the programming language; LOC is dependent on the programming language.
• 3. When Used: FP is used early in the project; LOC is used after coding is completed.
• 4. Focus: FP focuses on what the user needs; LOC focuses on how much code is written.
• 5. Accuracy: FP gives consistent size estimates; LOC varies with coding style.
• 6. Use Case: FP is good for estimating effort; LOC is good for measuring productivity.

The Spiral Model

• 1. The Spiral Model is a risk-driven software process model combining iterative development and systematic steps.
• 2. It has four phases: Planning, Risk Analysis, Engineering, and Evaluation.
• 3. Each cycle represents a software development phase, improving through each spiral loop.
• 4. Ideal for large, complex, and high-risk projects with changing requirements.
• 5. Combines features of waterfall and prototyping models for flexibility and control.
• 6. Emphasizes early risk identification and reduction to avoid future issues.
• 7. Customer involvement is continuous, ensuring satisfaction and feedback at each stage.
• 8. Disadvantage: It is expensive and not suitable for small projects.

Data Flow Diagrams (DFD) up to Level 1

• 1. A DFD shows data flow in a system, focusing on how data moves through processes.
• 2. Level 0 DFD is the context diagram with one main process and external entities.
• 3. It provides a high-level view of the system’s input and output.
• 4. Level 1 DFD breaks the main process into sub-processes for more details.
• 5. It shows data stores, flows, and external entities interacting with sub-processes.
• 6. Helps in understanding system functionality without focusing on technical details.
• 7. Uses symbols: circles (processes), arrows (data flows), and rectangles (external entities).
• 8. Essential for requirement analysis and communication between users and developers.

Software Requirements Specification (SRS)

An SRS (Software Requirements Specification) is a detailed document that explains what a software system should do. It describes all the features, functions, and rules that the software must follow. The main goal of an SRS is to clearly communicate the client’s needs to the developers, testers, and designers so that everyone understands what needs to be built. It acts like an agreement between the client and the software development team.

The SRS document usually includes several important sections. First is the Introduction, which explains the purpose of the software, its scope, and basic definitions. The Overall Description section gives a general idea of the software, who will use it, and what limitations it has. Then comes the Specific Requirements, where all the features are listed in detail — for example, user login, search options, or report generation. The SRS also contains Non-functional Requirements, such as how fast the software should run, how secure it should be, and how reliable it must be. Some SRS documents also include user interface descriptions and diagrams to help visualize how the system will work.

The SRS is very important in the Software Development Life Cycle (SDLC). It helps in avoiding misunderstandings, reduces development time and cost, and makes it easier to test the final product. Without an SRS, there is a high chance of missing features or developing the wrong system.

For example, if we are building a Library Management System, the SRS would mention that users should be able to search and borrow books, librarians should manage book records, and the system should be fast and secure. By preparing a proper SRS before development, we make sure that the final software meets the user’s expectations.

Software Metrics: Types and Needs

• 1. Metrics are standards to measure software processes, products, or projects.
• 2. Software metrics help in understanding, managing, and improving software quality and performance.
• 3. Types: Product metrics measure code, Process metrics assess development steps, and Project metrics track progress.
• 4. Product Metrics: LOC, complexity, size, maintainability, and modularity indicators.
• 5. Process Metrics: Defect rates, testing coverage, and change request frequency.
• 6. Project Metrics: Cost, schedule, resources, effort, and productivity measures.
• 7. Metrics are needed for estimating effort, controlling cost, improving quality, and tracking project status.
• 8. Metrics support decision-making, continuous improvement, and ensure alignment with customer needs.

Black Box vs. White Box Testing

• 1. Knowledge of Code: Black box requires no knowledge of code; White box requires knowledge of the code.
• 2. Focus Area: Black box tests functionality; White box tests internal logic.
• 3. Tester Role: Black box can be done by anyone; White box is done by developers or skilled testers.
• 4. Test Type: Black box is input-output based; White box is code path based.
• 5. Examples: Black box includes login tests with valid/invalid data; White box includes testing loops, conditions, and statements.
• 6. Use Together: They are complementary and used together for full coverage.

ERD vs. DFD Comparison

• 1. Focus Area: ERD shows what data exists; DFD shows how data moves.
• 2. Purpose: ERD is for database design; DFD is for system process modeling.
• 3. Components: ERD has entities, attributes, and relationships; DFD has processes, data stores, and data flows.
• 4. Level of Detail: ERD is detailed in data design; DFD is broad in showing data movement.
• 5. User: ERD is mainly used by database designers; DFD is used by system analysts.
• 6. Diagram Style: ERD looks like a relational diagram; DFD looks like a flowchart.

Basic vs. Intermediate COCOMO Models