Software

15 September 2024 19:13

What is Software Engineering? 7. Evolution of Software Engineering Benefits of a Systematic Process:

• Improved quality and reliability: Reduced bugs and errors.
• Definition: Software engineering is the systematic, disciplined, and quantifiable approach to developing, operating, and • Early Computer Programming (1950s): • Reduced cost and schedule overruns: Improved planning and execution.
maintaining software products that meets user needs and adapts to a constantly evolving environment. It applies ○ Programs were written in assembly language and • Enhanced maintainability: Easier to fix bugs and add features.
engineering principles to software creation. • Increased productivity: More efficient use of resources.
○ limited to a few hundred lines of code.
• Improved communication: Better collaboration between developers and stakeholders.
• Key Components: • High-Level Language Programming (Early 1960s):
○ Software: More than just code, software encompasses executable code, libraries, and documentation. A software ○ FORTRAN, ALGOL, and COBOL reduced development efforts significantly.
product is developed for a specific purpose.
• Control Flow-Based Design (Late 1960s):
5. Programs vs. Software Products
○ Exploratory programming became inadequate for larger, more complex programs.
○ Difficulty in writing cost-effective and correct code Products, Custom Solutions, Services, Domains, Technologies
Feature Program Software Product Software Products:
○ Difficulty in understanding and maintaining programs • Off-the-shelf (OTS): Pre-packaged software designed for general use (e.g., Microsoft Office, Adobe
Size Usually small Large
○ Emphasis on designing control structures using flow charts. Photoshop).
Users Single developer Large number of users • Structured Programming (Late 1960s): • Customized Software: Tailored to meet the specific needs of a particular organization or individual
Development Single developer Team of developers (e.g., enterprise resource planning (ERP) systems, website development).
○ Restricting the use of GO TO statements to create more structured and maintainable code.
Software Services:
Interface Lacks proper user interface Well-designed interface ○ Three basic constructs: sequence, selection, iteration • Software as a Service (SaaS): Software delivered over the internet (e.g., Gmail, Dropbox).
Documentation Lacks proper documentation Well documented and user-manuals provided ○ Easier to read, understand, and maintain • Cloud Computing: Accessing computing resources (servers, storage, software) over the internet.
• Software Development Services: Outsourced services for software development (e.g., consulting,
Development process Ad hoc Systematic ○ Reduced development time and effort
coding, testing).
• Data Structure-Oriented Design (Early 1970s): Software Domains:
○ Focus shifted to designing data structures, influencing program structure. • Web Development: Creating websites and web applications.
○ Engineering: Applying scientific principles and methods to create products.
○ Techniques like Jackson's Structured Programming (JSP) emphasize aligning code structure • Mobile Development: Building apps for smartphones and tablets.
• Goal: To produce efficient, reliable, and high-quality software products that meet user requirements. • Data Science: Analyzing and extracting insights from data.
with data structure.
• Artificial Intelligence (AI): Developing intelligent systems that mimic human behavior.
• Data Flow-Oriented Design (Late 1970s): Software Technologies:
○ Software Development Paradigm: The overarching approach encompassing requirement gathering, design, coding,
○ Identifies data items and processing steps, representing the system's flow of data. • Programming Languages: C++, Java, Python, JavaScript.
testing, and maintenance.
○ Simple and generic technique applicable to various systems. • Development Frameworks: React, Angular, Spring, Django.
○ Software Design Paradigm: Focuses on the design process, including design, maintenance, and programming. • Databases: MySQL, PostgreSQL, MongoDB.
• Object-Oriented Design (1980s): • Cloud Platforms: AWS, Azure, Google Cloud.
○ Programming Paradigm: Deals with the specific coding and testing phases of development.
○ Modeling real-world objects and their relationships, promoting simplicity, reuse, and
robustness.
Need for Software Engineering
13. Summary
• Large Software Systems: Building complex software requires engineering principles to manage scale and complexity.
• Software engineering is a systematic approach leveraging experience and innovation for successful
• Scalability: Engineering principles are crucial to ensure software can adapt and grow alongside evolving user needs.
software development.
• Cost Management: Well-defined processes lead to better resource management and reduced development costs.
• Adopting a life cycle model is essential for managing large projects and ensuring a structured
• Dynamic Environments: Software engineering helps manage the constant changes and updates required by dynamic user development process.
environments.
• Adhering to a life cycle model promotes disciplined development practices, improves project
• Quality Management: Systematic development leads to higher quality software, reducing bugs and improving user management, and enhances overall project success.
satisfaction.
Characteristics of Good Software

• Operational:
○ Budget: Developed within a reasonable budget.
○ Usability: Easy for users to learn and operate.
○ Efficiency: Performs tasks effectively and efficiently.
○ Correctness: Functions as intended, with minimal errors.
○ Functionality: Meets all specified user requirements.
○ Dependability: Reliable and trustworthy, even in challenging situations.
○ Security: Protects user data and system integrity.
○ Safety: Does not pose safety risks to users or the system.
• Transitional:
○ Portability: Can be easily adapted to different platforms.
○ Interoperability: Works well with other systems and technologies.
○ Reusability: Components can be reused in other projects.
○ Adaptability: Can be easily modified to accommodate changing needs.
• Maintenance:
○ Modularity: Code is well-organized into manageable modules.
○ Maintainability: Easy to understand, modify, and update.
○ Flexibility: Can be easily adapted to new features and functionalities.
○ Scalability: Can handle increasing workloads and data volumes.

Software development phases and processes

2.1 Software development and processes – Waterfall, Iterative: Spiral, The Waterfall Model: A Linear, Sequential Approach to Software The Iterative Model: A Cyclical Approach to Software Development The Spiral Model: A Risk-Driven Approach to Software
RAD, RUP, Agile: Scrum, Prototyping Development Key Concepts: Development
Key Concepts: Key Concepts:
Software Development Life Cycle (SDLC) • Cyclic Development: The software development process is broken down into smaller cycles, each
producing a working version of the software with increasing functionality.
Development phases of Software • Linear & Sequential: Phases progress in a strict order, one after the other, with no overlapping. • Iterative & Risk-Focused: Combines iterative development with a strong emphasis on
• Incremental Build: Each cycle adds new features and capabilities to the previous version. risk analysis and management.
• Completed Before Proceeding: Each phase must be fully completed before moving to the next.
aims to produce a high-quality software that meets or exceeds customer expectations, • Continuous Feedback: Each cycle provides an opportunity to gather user feedback and adjust future • Spiral Path: Development progresses through a series of cycles (spirals), each addressing
• No Backtracking: Once a phase is finalized, there's limited ability to go back and change previous
reaches completion within times and cost estimates. iterations. specific risks and refining the software incrementally.
decisions.
Strengths: • Incremental Release: Each spiral produces a working version of the software with
Strengths:
increasing functionality.
• Early Delivery of Functionality: Working software is delivered early in the development process, allowing
• Simplicity: Easy to understand and manage due to its structured nature. Strengths:
for user feedback and validation.
• Clear Deliverables: Each phase has well-defined outputs and review processes.
• Adaptable to Change: Easier to accommodate changing requirements as feedback is incorporated into • Early Risk Identification: Risks are assessed and mitigated throughout the development
• Suitable for Small, Well-Defined Projects: Effective when requirements are stable and understood.
each iteration. process.
Weaknesses:
• Risk Mitigation: Risks are identified and addressed early in the development cycle. • Flexibility & Adaptability: Evolving requirements and changing priorities can be
• Lack of Flexibility: Adapting to changing requirements can be difficult and costly. Weaknesses: incorporated into each spiral.
• Delayed Feedback: Working software is not available until the final stages, making it difficult to identify • User Involvement: Frequent user feedback and evaluation are integrated into the
• Resource Intensive: Each iteration requires resources for planning, design, development, and testing, development cycle.
issues early on.
making it potentially more resource-intensive than linear models.
Stage 1: Planning and Requirement Analysis • High Risk & Uncertainty: Limited opportunity to assess and mitigate risks throughout the development Weaknesses:
• Complex Management: Managing multiple iterations and ensuring consistency across versions can be
cycle.
challenging. • Complexity: Managing multiple spirals and coordinating risk assessments can be
• Goal: Define project scope, gather requirements, and assess feasibility. • No parallelism
• Potential for Architecture Issues: Not all requirements are fully defined at the beginning, which may lead challenging.
• Activities: When to Use: to architectural challenges later in the development cycle. • Potential for Scope Creep: Continuously changing requirements can lead to project
○ Gather input from stakeholders (customers, sales, experts).
When to Use: scope expansion.
○ Conduct market surveys and research. • Stable Requirements: When requirements are well-defined and unlikely to change significantly.
• Known Technology: When the technology stack is well-understood and mature. • Costly for Smaller Projects: The overhead of risk analysis and multiple iterations might
○ Define project approach and scope. • Large & Complex Projects: Effective for projects with extensive functionality or evolving requirements. be excessive for simpler projects.
○ Perform feasibility studies (economic, operational, technical). • Short Projects: When the project is short and timeframes are tight. • Time-to-Market Constraints: When delivering working software quickly is important. When to Use:
○ Plan for quality assurance and risk management. Phases: • Uncertain Requirements: When initial requirements are not fully defined or may evolve over time.
Stage 2: Defining Requirements Phases: • High-Risk Projects: Effective for complex or critical systems where risks need careful
1. Requirement Gathering & Analysis: Define and document all system requirements.
management.
• Goal: Document detailed product requirements and get customer approval. 2. System Design: Develop the system architecture based on requirements. 1. Initial Iteration: Develop a basic, core version of the software with essential features. • Evolving Requirements: Ideal for projects where requirements are likely to change
• Activities: 3. Implementation: Develop the software in units, testing each unit independently. 2. Subsequent Iterations: Add new features, enhancements, and bug fixes to each subsequent iteration. throughout development.
○ Create a Software Requirement Specification (SRS) document. 4. Integration & Testing: Combine all units into a complete system and test for functionality. 3. User Feedback: Gather feedback from users after each iteration to inform future development. • Large-Scale Systems: Suitable for projects with significant complexity and multiple
○ Define all product functionalities, features, and specifications. 5. Deployment: Release the software into the target environment. 4. Continuous Refinement: Continue iterating and refining the software until it meets all requirements. development teams.
○ Ensure clear communication and alignment with stakeholders. 6. Maintenance: Provide ongoing support, bug fixes, and enhancements. Example: Phases:
Stage 3: Designing the Product Architecture Example:
Imagine developing a social media platform. An Iterative Model might involve these steps: 1. Identification: Define system requirements and identify key risks.
• Goal: Create the product architecture based on the SRS. Imagine building a house. The Waterfall Model would be like following these steps in order: 2. Design: Develop the system architecture, including risk mitigation strategies.
1. Iteration 1: Build the core functionality – user registration, profile creation, basic messaging. 3. Construction: Build and test the software, incorporating risk-driven adjustments.
• Activities:
1. Planning (requirements): Design the blueprint and gather materials. 2. Iteration 2: Add features – group creation, content sharing, friend requests.
○ Design multiple architecture approaches. 4. Evaluation: Assess the software, gather user feedback, and plan for the next spiral.
2. Construction (design): Lay the foundation, build the walls, install plumbing and wiring. 3. Iteration 3: Enhance the platform – add features for video sharing, real-time chat, and user analytics.
○ Document the design in a Design Document Specification (DDS). Example:
3. Finishing (implementation): Paint the walls, install flooring, and add fixtures. Note: The Iterative Model is often favored for modern software development due to its flexibility and ability to
○ Review and select the optimal design considering factors like:
4. Inspection (testing): Ensure the house meets building codes and safety standards. adapt to changing user needs and technological advancements. Imagine developing a new operating system. A Spiral Model might involve these steps:
 Risk assessment 5. Move-in (deployment): Start living in the house.
 Robustness 6. Maintenance (maintenance): Repair any damage or make updates as needed. 1. Spiral 1: Define core system requirements and identify key security risks. Develop a basic
 Modularity Note: The Waterfall Model is often considered outdated and less suitable for complex projects with evolving kernel and test its stability.
 Budget requirements. Modern software development often embraces more agile methodologies that allow for greater 2. Spiral 2: Design a user interface and incorporate security features to address the initial
 Time constraints flexibility and adaptability risks. Build a basic user interface and test its usability.
○ Define communication and data flow between modules. 3. Spiral 3: Add advanced features like networking and file management. Incorporate user
○ Detail internal designs for all modules. Classic waterfall model feedback and improve system security.

Stage 4: Building or Developing the Product 4. Spiral 4: Release the operating system with a set of core features. Continue to iterate on
subsequent spirals to add new features, address user needs, and improve system
• Goal: Code the product based on the approved design. security.
• Activities: Note: The Spiral Model is often used for large, mission-critical projects where careful risk
management is essential. It provides a framework for managing complexity and uncertainty,
○ Generate code using programming languages (e.g., C, C++, Java, PHP).
ensuring the software is developed in a controlled and iterative manner.
○ Adhere to organization's coding guidelines.
○ Utilize development tools (compilers, interpreters, debuggers).
○ Ensure code quality and maintainability.
Stage 5: Testing the Product

• Goal: evaluating and verifying that software does what it is supposed to do.
○ Identify and fix defects to ensure quality standards are met.
• Activities: Iterative
○ Conduct various tests (unit testing, integration testing, system testing, user
acceptance testing).
Unit Testing

• Individual units (smallest testable parts) of code, like functions or classes.

• Verify each unit works correctly in isolation.
• Benefits:
○ Early bug detection.
○ Easier to pinpoint and fix errors.
○ Simplifies testing for large systems.
• How it works:
○ Write tests for individual functions/classes.
○ Execute tests to see if they pass or fail.
○ Refactor code based on test results.
Integration Testing

• How different units/modules work together.

• Ensure modules interact properly and produce the expected outcome.
• Benefits:
○ Catch errors in communication between components.
○ Verify system behavior as a whole.
• How it works:
○ Combine multiple units into a larger system.
○ Test their interactions (e.g., data flow between modules).
○ Examples:
 Checking if data is correctly transferred between modules.
 Testing if user authentication works as expected.

○ Report, track, and fix defects.

○ Retest until the product reaches the quality level defined in the SRS.

Stage 6: Deployment in the Market and Maintenance

• Goal: Release the product to the market and provide ongoing support.
• Activities:
○ Deploy the product in stages (phased rollout or limited release).
○ Monitor product performance in the real-world environment (UAT).
○ Implement user feedback and enhancements.
○ Provide ongoing maintenance and support to existing customers.
The Agile Model: A Customer-Centric, Adaptive Approach to Software
Development 2.3 Across the versions development
Key Concepts: "Across the versions" in software development generally refers to the management of
changes and features across different releases of a software product. It encompasses
• Iterative & Incremental: Development occurs in short cycles (iterations), each delivering a working various aspects of the development process, such as:
increment of the software.
• Customer Collaboration: Frequent interaction and feedback from customers are crucial for guiding 1. Version Control:
development.
• Adaptive & Flexible: The approach readily adapts to changing requirements and priorities. • Tracking changes: Using tools like Git to track all modifications made to the
• Teamwork & Self-Organization: Cross-functional teams work collaboratively with a high degree of codebase.
autonomy. • Branching and merging: Creating separate branches for different features or bug
Strengths: fixes and merging them back into the main codebase.
• Fast Delivery of Value: Working software is delivered frequently, enabling early user feedback and
• Versioning: Assigning specific numbers or tags to different versions of the software.
rapid iteration. 2. Feature Management:
• Responds to Change: Agile teams can quickly adapt to changing requirements and market conditions.
• Improved Quality: Frequent testing and customer feedback help identify and address issues early on.
• Planning and prioritizing features: Deciding which features will be included in each
• Increased Customer Satisfaction: Continuous engagement and collaboration ensure that the final
release based on user needs and business goals.
product meets customer needs. • Feature toggling: Using mechanisms to enable or disable features selectively during
Weaknesses: development and deployment.
• Backwards compatibility: Ensuring that older versions of the software can still
• Requires Strong Teams: Agile methods demand highly skilled, self-organizing teams with effective
function with newer versions.
communication.
• Documentation Challenges: Agile teams often focus on working software over extensive
3. Release Management:
documentation, which can lead to difficulties in knowledge transfer and maintainability.
• Release cycles: Defining the frequency and schedule of software releases.
• Potential for Scope Creep: Close customer collaboration can sometimes lead to requests for
additional features that expand the project scope. • Testing and quality assurance: Ensuring that each release is thoroughly tested
• Not Suitable for All Projects: Agile might not be the best fit for projects with strict regulatory before being deployed.
requirements, complex dependencies, or unclear requirements. • Deployment strategies: Choosing the best way to deliver the software to users, such
Key Principles of the Agile Manifesto: as rolling updates or staged releases.
4. Documentation and Communication:
• Individuals and interactions over processes and tools: Collaboration and communication are valued
above rigid processes.
• Release notes: Providing detailed information about changes and improvements in
• Working software over comprehensive documentation: Delivering a working product is prioritized
each release.
over extensive documentation.
• Customer collaboration over contract negotiation: Continuous customer engagement is emphasized.
• Change logs: Recording all changes made to the codebase, including bug fixes,
• Responding to change over following a plan: Adapting to change is encouraged over strict adherence
feature additions, and performance enhancements.
to a pre-defined plan. • Version-specific documentation: Maintaining documentation that is relevant to
When to Use: each specific version of the software.
Challenges of Working Across Versions:
• Projects with Evolving Requirements: Agile works well when customer needs are not fully
understood upfront. • Code conflicts: Merging changes from different branches can introduce conflicts.
• Rapid Prototyping and Development: Agile excels in delivering working software quickly.
• Deprecation and compatibility issues: Removing or changing features can break
• Small to Medium-Sized Teams: Agile teams typically work best with smaller, tightly knit groups.
compatibility with older versions.
Example:
• Maintaining consistency: Ensuring that the user experience is consistent across all
Imagine developing a mobile app for an online marketplace. An Agile approach might involve these steps: versions.
Strategies for Effective Version Management:
1. Iteration 1: Create a basic version of the app with core features like user registration, product
browsing, and search. • Clear communication: Regularly communicate about release plans and version-
2. Iteration 2: Add features for user reviews, product comparison, and shopping cart functionality. specific details.
3. Iteration 3: Incorporate customer feedback and refine the user interface based on their usage • Automated testing: Use automated tests to catch regressions and ensure backwards
patterns.
compatibility.
4. Iteration 4: Release the app with additional features and improvements based on ongoing feedback.
• Versioning conventions: Follow established versioning practices to avoid confusion.
Note: Agile is a popular and effective approach for modern software development. It empowers teams to
deliver high-quality software quickly and adapt to evolving requirements, leading to increased customer In summary, "Across the versions" in software development refers to the complex
satisfaction. process of managing software releases, from planning and development to deployment
and maintenance, across multiple versions of the product. This involves careful
coordination, version control, testing, and communication to ensure that all versions are
stable, functional, and meet user expectations

What are Software Requirements? TheSimple…

• Software requirements are a detailed description of the

• features, functionalities, and behaviors of a software system.
• They define what the software should do. Software Design: From Requirements to Implementation
• Importance: foundation of the entire software development process. They ensure that the final product meets the needs of Requirement Prioritization and Classification What is Software Design?
users and stakeholders.
• Types of Requirements: • Prioritization: Categorizing requirements by importance and urgency. • Definition: Software design is the process of transforming user requirements (captured in the SRS document) into
○ Functional Requirements: • Classification: Grouping requirements into categories: a detailed blueprint that guides programmers in building the software. It translates abstract concepts into a
 Describe the specific actions the system must perform. ○ Must Have: Essential for system functionality. concrete, technical design. (tells how to do)
 Each functional requirement is detailed in terms of its input, output, and processing steps. ○ Should Have: Desirable but not essential. • Goal: To create a design that meets the requirements, is efficient, maintainable, and adaptable. It bridges the gap
○ Could Have: Nice to have but can be implemented later. between user needs and the code implementation.
□ Business Rules: Rules that govern how the software should behave.
○ Wish List: Ideas for future enhancements. • First Step in SDLC: Software design is the first step in the Software Development Life Cycle (SDLC), shifting the
□ User Actions: Specific actions that users can perform within the system.
focus from the problem domain (user requirements) to the solution domain (technical implementation).
□ Data Processing: How the software processes data.
Software Design Levels: A Multi-Layered Approach
□ System Responses: How the software reacts to user actions.
Software System Analyst
• Architectural Design:
○ Non-Functional Requirements: • Role: A system analyst analyzes the requirements of a proposed system, ensuring that ○ Abstraction: The highest level of abstraction, viewing the software as a system of interconnected
 Define quality attributes and constraints that are crucial for the user experience, they are documented accurately and comprehensively. components.
 such as performance, security, usability, and reliability. They define how the software should perform. • Responsibilities: ○ Focus: Defines the overall structure of the system, major components, and their interactions.
□ Performance: Response time, throughput, and resource utilization. ○ Requirement Analysis: Understanding and clarifying stakeholder needs. ○ Example: Deciding on a client-server architecture for a web application.
□ Security: Access control, data encryption, and security measures. ○ Requirement Documentation: Creating detailed SRS documents. • High-Level Design:
□ Usability: Ease of use and intuitive user interface. ○ Requirement Validation: Verifying the accuracy and completeness of requirements. ○ Less Abstraction: Breaks down the architectural design into subsystems and modules, detailing their
□ Reliability: Fault tolerance, recovery mechanisms, and system stability. ○ Requirement Management: Managing changes to requirements. interactions.
□ Maintainability: Ease of modification and updates. ○ Communication with Stakeholders: Facilitating communication and resolving ○ Focus: Defines the modular structure, data flow, and communication mechanisms.
□ Portability: Ability to run on different platforms and environments. conflicts. ○ Example: Designing the user interface module, database module, and business logic module.
□ Interoperability: Ability to interact with other systems. • Detailed Design:
□ Accessibility: Accessibility for users with disabilities. ○ Implementation Focus: Provides specific instructions for implementing each module and their interfaces.
Software Metrics and Measures
□ Cost: Budget constraints and cost-effectiveness. ○ Focus: Defines data structures, algorithms, and detailed logic for each component.
• Definition: Quantifiable measures that assess different aspects of software development ○ Example: Specifying the specific algorithms for searching and sorting data within the database module.
Requirement Engineering: The Process of Gathering and Defining Requirements and the final product. Modularization: Dividing and Conquering Software
• Types of Metrics:
• Goal: To create a complete and accurate System Requirements Specification (SRS) document, which serves as the blueprint • Concept: Breaking down a software system into smaller, independent modules with well-defined functionalities.
○ Size Metrics: Measure the size of the software, such as lines of code (LOC) and
for development. function points. • Advantages:
• Steps: ○ Complexity Metrics: Measure the complexity of the software, such as McCabe's ○ Maintainability: Easier to understand, debug, and modify individual modules.
○ Feasibility Study: Cyclomatic Complexity. ○ Reusability: Modules can be reused in other projects.
 Purpose: To assess the technical, economic, and organizational viability of developing the software. ○ Quality Metrics: Measure the quality of the software, such as defects, bugs, and user ○ Abstraction: Hides complexity, allowing developers to focus on specific parts.
 Process: Analyze the client's requirements, determine the project's scope, estimate costs and resources, and satisfaction. ○ Parallel Development: Modules can be developed independently, speeding up development.
evaluate risks. ○ Process Metrics: Measure the efficiency and effectiveness of the development ○ Concurrent Execution: Some modules can be executed concurrently, improving performance.
 Output: A feasibility study report with recommendations for proceeding or not. process. ○ Security: Improves security by isolating critical components.
○ Requirement Gathering: ○ Resource Metrics: Measure the resources used in the development process, such as Concurrency: Enabling Parallel Execution
 Purpose: To collect information from stakeholders about their needs and expectations for the software. effort, time, and cost.
 observing existing systems and procedures, and • Concept: Allowing multiple parts of the software to execute concurrently, like threads running in parallel.
 conducting interviews and discussions with customers and end-users • Benefits:
 to grasp the current process and identify any pain points or areas for improvement. ○ Increased Performance: Faster execution by utilizing multiple processing units.
○ Requirements Analysis: ○ Responsiveness: Keeps the user interface responsive even during intensive tasks.
 Clarifying Ambiguities: The analyst identify inconsistencies, ambiguities, and incompleteness. ○ Improved Resource Utilization: Better use of system resources.
□ Example of Inconsistency: • Example: Word processing software with a spell checker running concurrently in the background.
 One customer might say Coupling and Cohesion: Evaluating Module Relationships
"Turn off the heater and open the water shower when the temperature is above 100 degrees Celsius,"
• Cohesion: The degree to which elements within a module are related and focused on a single task. Higher
 while another customer says, cohesion is better.
"Turn off the heater and turn on the cooler when the temperature is above 100 degrees Celsius." • Coupling: The degree of interdependence between modules. Lower coupling is better.
 This conflict needs to be addressed. Types of Cohesion (from lowest to highest):
□ Example of Incompleteness:
 The analyst may have missed documenting what happens when the 1. Coincidental Cohesion: Unrelated elements grouped together randomly (undesirable).
 temperature falls below 90 degrees Celsius (e.g., should the heater turn back on? Should the water 2. Logical Cohesion: Elements related by function but not necessarily working together (weak).
shower turn off?). 3. Temporal Cohesion: Elements executed at similar times (weak).
○ Software Requirement Specification (SRS): 4. Procedural Cohesion: Elements executed sequentially (medium).
 Contractual Agreement: 5. Communicational Cohesion: Elements operating on the same data (strong).
□ The SRS becomes a crucial document that acts as a contract between the development team and the 6. Sequential Cohesion: Output of one element is input for the next (stronger).
customer. 7. Functional Cohesion: All elements contribute to a single, well-defined function (ideal).
□ The customer approves the SRS, ensuring that the final software product meets their exact needs. Types of Coupling (from highest to lowest):
 A Foundation for Development: The SRS provides a clear blueprint for the development team, guiding them in all
stages, from design and coding to testing and implementation. 1. Content Coupling: One module directly accesses or modifies the content of another (undesirable).
 Essential Characteristics: A good SRS document should be: 2. Common Coupling: Modules share access to global data (weak).
□ Concise and Unambiguous: It should be straightforward and easy to understand, avoiding vague or unclear 3. Control Coupling: One module controls the flow of execution in another (weak).
wording. 4. Stamp Coupling: Modules share a common data structure but use different parts (medium).
□ Focus on What, Not How: It specifies what the system should do (its functionality) but avoids dictating how it 5. Data Coupling: Modules interact through passing data as parameters (ideal).
should be implemented (the design choices). Design Verification: Ensuring Quality and Accuracy
□ Changeable: It should be well-structured and organized to allow for easy modification as requirements
evolve. • Purpose: To ensure that the design meets requirements and is free from errors before implementation.
□ Consistent: All parts of the SRS should align with each other, avoiding contradictions. • Methods:
□ Complete: It should cover all aspects of the system, including functional and nonfunctional requirements. ○ Design Reviews: Formal reviews by experts to identify potential issues.
□ Traceable: It should be clear which part of the specification corresponds to which part of the design, code, ○ Design Inspections: Detailed examination of design documents for completeness and consistency.
and other project artifacts. ○ Formal Verification: Using automated tools to verify design correctness.
□ Verifiable:Can be tested and validated to ensure that the software meets them. Conclusion
□ Prioritized: Classified by importance and urgency.
Software design is a critical phase in software development, laying the foundation for successful implementation. By
applying principles of modularization, concurrency, and cohesion, and by carefully verifying the design, you ensure that
○ Software Requirement Validation: your software is efficient, maintainable, and meets user expectations.
 Purpose: To ensure that the SRS document is complete, consistent, and accurate.
 Process: Review the SRS document for completeness, consistency, ambiguity, and feasibility. From <https://aistudio.google.com/app/prompts/1K3xjhUPgjEJ66WQSjeLGi0B4AmKzWCO3?pli=1>
 Output: A validated SRS document that is ready for use by the development team.

Requirement Elicitation: Uncovering Hidden Requirements

• Definition: The process of discovering and documenting hidden requirements that may not be explicitly stated by
stakeholders.
• Techniques:
○ Interviews: Structured and open-ended interviews to gather in-depth information.
○ Surveys: Questionnaires to collect data from a large number of stakeholders.
○ Task Analysis: Observing and analyzing users performing tasks to identify their needs.
○ Domain Analysis: Consulting experts in the relevant domain to understand specific requirements.
○ Brainstorming: Group sessions to generate ideas and explore potential requirements.
○ Prototyping: Creating a prototype of the system to gain user feedback and refine requirements.
○ Observation: Observing users in their natural environment to understand their workflows and challenges.