Requirement analysis and feasibility study notes — Unit 2

Once the problem is identified, requirement analysis determines exactly what the software must do to solve that problem. This is formalizing the 'What' before designing the 'How'.

⇒1.1 Software Requirements Specification (SRS)

The SRS is a formal document (often following IEEE standards) that acts as an agreement between the developers and the stakeholders. It provides a blueprint for the entire project.

⇒2.1 Functional Requirements

These describe the core behavior of the system. What inputs the system should accept, and what outputs it should produce. Examples: 'The system must allow a user to reset their password via email', 'The algorithm must classify an image into 10 categories'.

⇒2.2 Non-Functional Requirements (NFRs)

These define system attributes such as performance, security, usability, and reliability. Examples: 'The API must respond in under 200 milliseconds', 'Passwords must be hashed using bcrypt', 'The UI must be responsive on mobile devices'.

System design takes the SRS (the 'What') and translates it into a technical architecture (the 'How').

⇒3.1 High-Level Design (HLD)

Defines the overall system architecture. It identifies the major modules, their responsibilities, and how they interact. It includes the choice of technology stack (e.g., React frontend, Node.js backend, MongoDB database) and deployment architecture.

⇒3.2 Low-Level Design (LLD)

Details the internal logic of each module. This includes class diagrams, database schemas, API endpoint specifications, and specific algorithms.

UML is the standard visual language for software design. Project reports must include appropriate UML diagrams to illustrate the architecture.

⇒4.1 Structural Diagrams

• Class Diagram: Shows the static structure of the system (classes, attributes, methods, and relationships like inheritance or aggregation). Crucial for object-oriented systems.
• Component Diagram: Shows how higher-level software components are wired together.
• Deployment Diagram: Maps the software architecture onto the physical hardware/cloud infrastructure.

⇒5.1 Modeling System Behavior

• Use Case Diagram: Shows the interactions between external actors (users, other systems) and the system's use cases. Excellent for visualizing functional requirements.
• Sequence Diagram: Shows how objects interact in a particular scenario, arranged in time sequence. Crucial for designing API flows or complex algorithms.
• Activity Diagram: Similar to a flowchart, it shows the flow of control or data from activity to activity. Useful for modeling complex business logic.
• State Machine Diagram: Shows the different states an object can be in and the transitions between them.

If the project involves persistent data, the database design must be explicitly documented.

⇒6.1 ER Modeling

Entity-Relationship (ER) diagrams map out the entities (tables), attributes (columns), and relationships (1-to-1, 1-to-N, M-to-N) in the system. The design must be normalized (typically to 3NF) to prevent data anomalies, unless using a NoSQL architecture where denormalization is intentional.

• SRS: The formal contract detailing Functional (behavior) and Non-Functional (performance/security) requirements.
• Design Phases: High-Level Design maps the architecture; Low-Level Design maps the classes and logic.
• UML: The industry standard for visualization. Structural diagrams (Class) show static architecture; Behavioral diagrams (Sequence, Use Case) show dynamic interactions.
• Database Design: Formalized via ER diagrams to ensure data integrity and query efficiency.