U1 Notes - Updated (1).pdf

SOFTWARE ENGINEERING NOTES (UE22CS341A) Unit-1 Introduction 1. Software: A collection of executable computer programs, configuration files, associated libraries, and documentation. 2. Software Product: A softwar...

SOFTWARE ENGINEERING NOTES (UE22CS341A) Unit-1 Introduction 1. Software: A collection of executable computer programs, configuration files, associated libraries, and documentation. 2. Software Product: A software solution designed to meet a specific set of requirements. Includes types like generic, custom, system, and application software. 3. Engineering: The application of well-defined scientific principles and systematic methods for developing products with: Economic viability Social responsibility Practical considerations 4. Software Engineering (SE): A systematic, disciplined, and quantifiable approach to software development, operation, and maintenance. Software products developed using SE principles are more likely to be reliable. Emphasizes the use of appropriate tools and techniques. Focuses primarily on techniques for software development and maintenance. Fundamental Drivers of SE 1. Industrial-Strength Software Requirements: Operational: Ensures functionality, usability, and correctness. Portability & Interoperability: Capable of being moved across different platforms. Maintainability: Focuses on modularity, scalability, and ease of maintenance. Comprehensive Documentation: Detailed and thorough documentation is essential. Minimal Bugs: Strives for the absence or minimal presence of bugs. Business Impact: Critical for quality, resilience, and overall business operations. High Cost: Software development and maintenance are labor-intensive and expensive. 1 TAs: Yashaswini Ippili & Ria Kulkarni  SOFTWARE ENGINEERING NOTES (UE22CS341A) 2. Software Maintenance & Rework: Involves corrective actions, adaptive updates, or rework. Maintenance costs are significant for both hardware and software. Many projects face delays and reliability issues. Around 35% of projects are considered "runaway" (over budget or off-schedule). In defense systems, 70% of equipment failures are attributed to software issues. Software can directly affect life-or-death situations. 3. Challenges in Modern Software: Heterogeneity: Systems often operate as distributed networks. Diversity: Various software systems require different techniques and methods. Rapid Business & Social Change: Constantly adapting existing software and developing new solutions. Security & Trust: Ensuring systems are secure and trustworthy. Scalability: ○ Maintain quality and productivity. ○ Ensure consistency and repeatability across systems. 2 TAs: Yashaswini Ippili & Ria Kulkarni  SOFTWARE ENGINEERING NOTES (UE22CS341A) Software Lifecycle Software Process/Lifecycle/Process Model/Lifecycle Model: A structured set of activities designed to produce intermediate and final products. Each phase is guided by principles that define its goals and objectives. Products: Outcomes generated from executing each phase of the process. Characteristics of Each Phase: Entry Criteria: Conditions that must be met to begin the phase. Tasks & Deliverables: Specific activities to be completed and the resulting outputs. Exit Criteria: Conditions that must be satisfied to move to the next phase. Responsibility: Clear assignment of who is accountable for each phase. Dependencies: Relationships and linkages between phases or tasks. Constraints: Limitations and restrictions impacting the process. Software Development Life Cycle (SDLC) : Systematic process for building software that ensures quality and correctness that meets customers business requirements. 3 TAs: Yashaswini Ippili & Ria Kulkarni  SOFTWARE ENGINEERING NOTES (UE22CS341A) Stages of the Software Lifecycle: 1. Requirement Analysis: ○ Entry Criteria: Identifying the need for a solution to an existing problem. ○ Tasks & Deliverables: Define the project scope and anticipate issues and opportunities. Gather detailed requirements to create a project timeline. ○ Exit Criteria: Completion of the Software Requirements Specification (SRS) document. ○ Responsibility: Senior team members, stakeholders, and domain experts. ○ Feasibility Study: Evaluates economic, legal, operational, technical, and scheduling factors. 2. Design: ○ Entry Criteria: Availability of the Software Requirements Specification (SRS) document. ○ Tasks & Deliverables: Develop system and software design documents. Define overall architecture. ○ Exit Criteria: Creation of two design documents: High-Level Design (HLD): Brief description and names of modules, functionality, interface relationships, and dependencies. Low-Level Design (LLD): Detailed logic for each module, interface specifications, dependencies, error handling, and input/output considerations. 3. Implementation/Coding: ○ Entry Criteria: Availability of system design documents. ○ Tasks & Deliverables: Develop the software modules using the chosen programming language. ○ Exit Criteria: Completed software. ○ Responsibility: Developers. 4 TAs: Yashaswini Ippili & Ria Kulkarni  SOFTWARE ENGINEERING NOTES (UE22CS341A) 4. Testing: ○ Entry Criteria: Developed software. ○ Tasks & Deliverables: Validate system functionality against requirements and resolve any bugs. ○ Exit Criteria: Stable, bug-free, and fully functional software. ○ Responsibility: Quality Assurance and Testing Team. 5. Maintenance: ○ Involves three primary activities: Bug Fixing: Address issues from scenarios that were not previously tested. Upgrades: Update to newer versions. Enhancements: Add new features and capabilities. Product Development Lifecycle (PDLC) : Specific set of steps to take a project from first spark to release. 5 TAs: Yashaswini Ippili & Ria Kulkarni  SOFTWARE ENGINEERING NOTES (UE22CS341A) Stages of PDLC: Brainstorm: ○ Ideate a product that addresses specific user problems. ○ Research competitors and analyze existing products. ○ Ensure the new product either fills a gap or offers improvements over current options. Define: ○ Map out detailed specifications for the product. ○ Identify the target customers, their needs, and key product features. ○ Narrow down the product’s focus to meet specific goals. Design: ○ Develop design concepts and ideas for the product. ○ Create prototypes and wireframes to define components and structure. Test: ○ Build functional prototypes and conduct testing in three phases: Internal testing. Stakeholder reviews. External tests with potential users. ○ Gather feedback from each phase and make necessary improvements. Launch: ○ Finalize the product and make it accessible to the public. 6 TAs: Yashaswini Ippili & Ria Kulkarni  SOFTWARE ENGINEERING NOTES (UE22CS341A) Software Maintenance Life Cycle The Software Maintenance Life Cycle encompasses the activities involved in managing and updating software after its initial release. The key stages include: 1. Identification of Maintenance Needs: Issues or enhancement requests are identified, either through user feedback, system monitoring, or performance reviews. 2. Analysis: The impact and feasibility of changes are analyzed to determine if and how they should be implemented. 3. Design and Planning: The necessary changes or updates are designed, and a plan is developed to integrate them into the existing system without disrupting functionality. 4. Implementation: The changes are coded, tested, and integrated into the software. This may involve bug fixes, performance improvements, or new feature additions. 5. Testing: Rigorous testing is conducted to ensure that the changes work as intended and that no new issues are introduced. 6. Deployment: The updated software is deployed to users, and any necessary documentation is updated. 7. Review and Monitoring: The performance of the updated software is monitored, and user feedback is collected to inform future maintenance cycles. 7 TAs: Yashaswini Ippili & Ria Kulkarni  SOFTWARE ENGINEERING NOTES (UE22CS341A) Product Life Cycle Dictated by factors such as Market Capitalisation, Sales, Investment and so on. The Product Life Cycle refers to the stages a product goes through from its inception to its decline. Stages of Product Life Cycle : Introduction: The product is launched and enters the market, but may have limited popularity initially. Growth: Customers begin adopting the product widely; additional features may be introduced to stay competitive. Maturity: Growth slows as product adoption reaches its peak and stabilizes. Discontinuance: The product is no longer sold but continues to receive maintenance. Obsolescence: The product is no longer maintained and is phased out. 8 TAs: Yashaswini Ippili & Ria Kulkarni  SOFTWARE ENGINEERING NOTES (UE22CS341A) Legacy SDLCs 1. Waterfall model : A linear software development approach where each phase is completed sequentially before moving on to the next. It involves distinct stages like requirement analysis, design, implementation, testing, and maintenance, with no overlap between phases. Progress flows in one direction, like a waterfall, making it best suited for projects with well-defined requirements. Pros & Cons: Advantages Disadvantages Simple Assumes frozen requirements Clear Identified Phases (departmentalised) Sequential and Big Bang Approach Easy to Manage High Risk and Uncertainty Specific Deliverables and Review at each phase Usage: Suitable for short projects with clear and well-understood requirements. Applicable in large projects as high-level variants. Ideal when the product definition is stable and the technology is well-understood. Often used in large, globally developed projects in combination with other lifecycle models. 9 TAs: Yashaswini Ippili & Ria Kulkarni  SOFTWARE ENGINEERING NOTES (UE22CS341A) 2. V Model: Also known as the Verification and Validation model, is a software development methodology that emphasizes the importance of testing throughout the development process. It is characterized by its V-shaped diagram, where each development stage corresponds to a testing phase. Pros & Cons: Advantages Disadvantages Similar to Waterfall Similar to Waterfall Test Activities before Coding No early prototypes Higher Probability of success Change in process = Change in documentation Usage of the V-Model: Projects with Well-Defined Requirements: Ideal for projects where requirements are clear and stable from the outset. Regulated Industries: Commonly used in industries such as aerospace, automotive, and healthcare, where rigorous validation and verification are critical. High Assurance Software: Suitable for systems where safety, reliability, and compliance are paramount, such as in critical systems or safety-critical applications. Clear Project Phases: Best for projects where each phase can be distinctly defined and where early and continuous testing is beneficial. 10 TAs: Yashaswini Ippili & Ria Kulkarni  SOFTWARE ENGINEERING NOTES (UE22CS341A) 3. Prototyping Model: A software development approach that emphasizes the creation of prototypes to explore and refine requirements before finalizing the software product. It involves building preliminary versions of the system to gather user feedback and make iterative improvements. Relatively a CHEAPER process. Pros & Cons: Advantages Disadvantages Active user involvement Increased Complexity Better Risk mitigation May not be Optimal Earlier detection of problems and missing functions More Stable Usage of the Prototyping Model: Unclear or Evolving Requirements: Ideal for projects where requirements are not well-defined from the start or are expected to change. User-Centric Applications: Useful for projects that require close user involvement to ensure the final product aligns with user needs and expectations. Complex Systems: Effective for complex systems where visualizing and interacting with a prototype helps in understanding and refining the design. Early Feedback Needed: Suitable when early feedback from users is crucial for shaping the system and ensuring it meets their needs. Innovative Projects: Beneficial for projects involving new or innovative features where exploration and iterative testing are required to define the final solution. 11 TAs: Yashaswini Ippili & Ria Kulkarni  SOFTWARE ENGINEERING NOTES (UE22CS341A) 4. Incremental Model: A software development approach where the system is built and delivered in small, manageable segments or increments. Each increment adds additional functionality to the existing system, allowing for gradual development and delivery. Pros & Cons: Advantages Disadvantages Earlier versions Needs good planning and design More flexible Clear and complete definition Easier to test Higher cost than waterfall Reduces over-functionality Usage: Defined Major Requirements: Suitable for projects where the core requirements are clearly established. Early Market Entry: Ideal for scenarios where it's important to deliver a product to the market quickly. New Technology: Effective when implementing new or emerging technologies. Skill Availability: Useful when the required skills for the project are limited or unavailable, allowing for incremental development and integration. 12 TAs: Yashaswini Ippili & Ria Kulkarni  SOFTWARE ENGINEERING NOTES (UE22CS341A) 5. Iterative Model: A software development approach where the system is developed through repeated cycles, or iterations, each of which refines and improves upon the previous version. Pros & Cons: Advantages Disadvantages Identify requirements Rigid with overlaps Risk mitigation Costly system Redesign and Rework Usage of the Iterative Model: Evolving Requirements: Suitable for projects where requirements may change or develop over time, allowing for adjustments and refinements. User Feedback Integration: Ideal when regular user feedback is needed to guide and improve the development process. Complex Projects: Effective for complex projects where early versions can be tested and improved in cycles. Risk Management: Useful for managing risks by identifying and addressing issues early through iterative cycles. Continuous Improvement: Beneficial when the project demands ongoing enhancement and fine-tuning to meet evolving needs and expectations. 13 TAs: Yashaswini Ippili & Ria Kulkarni  SOFTWARE ENGINEERING NOTES (UE22CS341A) 6. Spiral Model : A risk-driven software development methodology that combines iterative development with elements of the Waterfall Model. It is designed to address and manage risks through repeated cycles of planning, development, and evaluation. Pros & Cons: Advantages Disadvantages Risk Management: Early risk handling. Complexity: Difficult to manage. Flexibility: Adapts to changes. Cost: Potentially high expenses. User Feedback: Continuous input integration. Time-Consuming: Requires lengthy iterations. Usage of the Spiral Model: Complex Projects: Suitable for large, complex systems. Unclear Requirements: Effective when requirements are evolving or not fully defined. High Risk: Ideal for projects with significant risk factors. Frequent Feedback: Useful for projects needing regular user feedback and adjustments. 14 TAs: Yashaswini Ippili & Ria Kulkarni  SOFTWARE ENGINEERING NOTES (UE22CS341A) Drawbacks of Legacy SDLCs: - Predictive Approach: Based on rigid, predictive planning rather than adaptive development. - Extensive Upfront Planning: Requires extensive planning before development begins. - Limited Customer Interaction: Lacks mechanisms for regular customer feedback and interaction. - Complex Projects Only: More suited for large projects with intricate dependencies, but less flexible for smaller or evolving projects. 4Ps - Process, Product, People, Project The 4Ps—Process, Product, People, and Project—are key components in the context of software development and project management. Each element plays a critical role in ensuring the success and effectiveness of a project. 1. Process Definition: The Process refers to the structured set of activities, methodologies, and procedures used to develop and manage software or projects. It encompasses the workflow and stages involved in achieving project goals. Key Aspects: Methodology: The approach used, such as Agile, Waterfall, or Spiral. Phases: The different stages of development, including planning, design, implementation, testing, and maintenance. Best Practices: Standard practices and guidelines that ensure efficiency, quality, and consistency throughout the project lifecycle. Continuous Improvement: The process should be adaptable and allow for refinements based on feedback and evolving needs. 15 TAs: Yashaswini Ippili & Ria Kulkarni  SOFTWARE ENGINEERING NOTES (UE22CS341A) Importance: Ensures structured and systematic development. Helps manage project complexity and risks. Provides a clear roadmap and accountability. 2. Product Definition: The Product refers to the final software or system delivered to the user, encompassing all its features, functionalities, and attributes. Key Aspects: Requirements: The specific needs and expectations that the product must fulfill. Design and Architecture: The overall design and technical structure of the product. Quality: The product’s reliability, performance, and adherence to standards and requirements. User Experience: The usability and satisfaction of the end-users interacting with the product. Importance: Represents the tangible outcome of the development process. Directly impacts user satisfaction and business value. Requires careful planning and execution to meet user needs and expectations. 3. People Definition: People refer to the individuals and teams involved in the project, including stakeholders, developers, designers, managers, and end-users. Key Aspects: Roles and Responsibilities: The specific functions and tasks assigned to each team member. Skills and Expertise: The knowledge and capabilities required to complete the project successfully. Collaboration and Communication: The interactions and coordination between team members and stakeholders. Motivation and Engagement: Ensuring team members are motivated and committed to the project’s success. 16 TAs: Yashaswini Ippili & Ria Kulkarni  SOFTWARE ENGINEERING NOTES (UE22CS341A) Importance: Drives the execution and management of the project. Influences the quality of the process and product. Essential for effective collaboration and achieving project goals. 4. Project Definition: The Project encompasses the entire endeavor from initiation to completion, including its scope, timeline, budget, and objectives. Key Aspects: Scope: The defined boundaries and deliverables of the project. Timeline: The schedule and milestones for completing project tasks and phases. Budget: The financial resources allocated and managed throughout the project. Risk Management: Identifying, assessing, and mitigating risks that may affect project success. Importance: Provides a framework for planning and managing resources. Ensures alignment of objectives with organizational goals. Helps in tracking progress, managing risks, and delivering the final product on time and within budget. Agile : Agile is a flexible, iterative approach that emphasizes continuous delivery, collaboration, and adaptation to change. Ongoing Adjustment: Agile methodologies promote continuously adjusting development goals to meet customer needs and expectations. Reduced Planning Overhead: Aims to minimize extensive planning by facilitating rapid responses to changes. Flexibility: Agile is a flexible approach to software development and project management. Iterative Process: Emphasizes iterative development with frequent cycles or sprints. 17 TAs: Yashaswini Ippili & Ria Kulkarni  SOFTWARE ENGINEERING NOTES (UE22CS341A) Adaptability: Focuses on adapting to evolving requirements and changes. Collaboration: Encourages strong collaboration and communication among team members. Customer Feedback: Prioritizes incorporating customer feedback regularly. Incremental Delivery: Delivers functional software quickly and continuously through smaller, manageable increments. Agile Manifesto Principles: Individuals and Interactions Over Processes and Tools: Emphasizes the importance of people and their collaboration rather than relying solely on processes and tools. Working Software Over Comprehensive Documentation: Prioritizes delivering functional software over creating extensive documentation. Customer Collaboration Over Contract Negotiation: Values ongoing collaboration with customers more than adhering strictly to contract terms. Responding to Change Over Following a Plan: Focuses on adapting to changes rather than rigidly following a set plan. Simplicity in Product and Process: Advocates for simplicity in both the product and development process. Pros and Cons: Advantages Disadvantages Realistic approach to development Not suitable for complex dependencies Teamwork and Cross training Risk of sustainability and maintainability Rapid Development and Demonstration Depends on customer interaction Minimum and Flexible requirements High individual dependency Minimal rules and easy documentation Little to no planning Easy to Manage and Flexible 18 TAs: Yashaswini Ippili & Ria Kulkarni  SOFTWARE ENGINEERING NOTES (UE22CS341A) Scrum Basics: Agile Methodology/Framework: A framework within Agile methodologies. Iterative Approach: Uses iterative development to enhance software projects. Application of Agile Practices: Provides a structured way to implement Agile practices. Lightweight Framework: A flexible and lightweight framework suited for managing and controlling iterative and incremental projects. 1. Roles: Scrum Team: Consists of cross-functional, self-organizing members responsible for delivering shippable increments. Scrum Master: Acts as a facilitator, not a manager. Removes impediments, facilitates meetings, and ensures adherence to Scrum practices. Product Owner: Represents the stakeholder or team, manages the product backlog, and prioritizes features. 2. Events: Sprint: A fixed-length iteration (2-4 weeks) that produces potentially shippable code. Multiple sprints can be part of a single release. Sprint Planning Meeting: Defines which product backlog items will be worked on during the sprint, sets goals, and outlines how to achieve them. 19 TAs: Yashaswini Ippili & Ria Kulkarni  SOFTWARE ENGINEERING NOTES (UE22CS341A) ○ Attendees: Product Owner: Prioritizes backlog items and proposes the sprint goal. Development Team: Decides which backlog items can be completed and how. Scrum Master: Facilitates the meeting, ensuring agreement on goals and scope. ○ Inputs: Product backlog Team capacity Past performance ○ Activities: Set sprint goal Select stories Plan capacity Daily Scrum Meeting: Brief daily meeting to discuss: ○ What was done yesterday? ○ What will be done today? ○ Any obstacles? ○ Update status on Scrum board/burndown chart. Sprint Review: Demonstrates completed features, evaluates against preset criteria, and gathers feedback from clients and stakeholders to ensure the increment meets business needs and helps reprioritize the product backlog. Sprint Retrospective: Final team meeting to review the past sprint, discuss improvements, and plan for the future. Led by the Scrum Master. 3. Artifacts: Product Backlog: A prioritized list of project/product features, including new features, changes, bug fixes, and infrastructure setup. Features are described as user stories, estimated, and ranked. 20 TAs: Yashaswini Ippili & Ria Kulkarni  SOFTWARE ENGINEERING NOTES (UE22CS341A) Sprint Backlog: Features and stories planned for the current sprint, derived from the product backlog. 4. Alignment with Agile Manifesto: Individuals and Interactions Over Processes and Tools: Emphasizes cross-functional teams, Scrum meetings, and sprint reviews. Working Software Over Comprehensive Documentation: Delivers periodic customer-ready increments for review and experience. Customer Collaboration Over Contract Negotiation: Involves customers in reviewing sprint outcomes and participating in sprint reviews. Responding to Change Over Following a Plan: Accommodates requirement changes through user stories and iterative planning. Focus on Simplicity: Short-term planning and straightforward processes keep the approach simple and effective. Extreme Programming (XP): 1. Overview: XP focuses on delivering high-priority user stories as tested software in frequent iterations. It emphasizes working software, continuous feedback, and adaptability to changes. 2. Key Practices: Planning Game: Defines the scope of the next release. Small Releases: Delivers a simple, functional system in small increments. Communication: Ensures clear communication of requirements within a small, cohesive team. Simple Design: Keeps design focused only on the current user story. Customer Involvement: Involves the customer on-site and continuously throughout development. Feedback: Gathers feedback through unit testing, customer acceptance, and team discussions. Pair Programming: Two developers collaborate on a single task. Refactoring: Updates or discards outdated solutions to improve code. Continuous Integration: Integrates code multiple times a day. 21 TAs: Yashaswini Ippili & Ria Kulkarni  SOFTWARE ENGINEERING NOTES (UE22CS341A) Collective Code Ownership: Allows any team member to modify the codebase. Coding Standards: Adheres to standards for better communication and consistency. Metaphor: Uses a shared vision and common terminology to address issues. Sustainable Pace: Maintains a standard work schedule to avoid burnout. 3. Usage: When requirements are unclear. For smaller systems. When the customer is available on-site. Lean Agile: Lean Agile builds on Agile principles but emphasizes faster delivery and sustainable results by focusing on efficiency and continuous improvement. Value Stream Mapping: Identifies and eliminates activities that do not add value from the customer's perspective. Kaizen: Embraces continuous inspection and incremental improvement to enhance performance. Active Learning: Encourages ongoing learning and adaptation. Delayed Decisions: Advocates making decisions as late as possible to keep options open and adapt to evolving requirements. 22 TAs: Yashaswini Ippili & Ria Kulkarni  SOFTWARE ENGINEERING NOTES (UE22CS341A) Component-Based Software Engineering (CBSE): CBSE is a reuse-oriented approach focused on defining, implementing, or selecting off-the-shelf components and integrating loosely coupled, independent components into a complete system. Components are more abstract than object classes and can be considered to be stand-alone service providers. They can exist as stand-alone entities. Motivation: ○ Complexity Management: Addresses the increasing complexity of systems. ○ Faster Turnaround: Aims to reduce development time by reusing existing components rather than creating new ones from scratch. ○ Efficiency: Promotes efficient system development and maintenance through component reuse. Pros & Cons: Advantages Disadvantages Black-Box component reduces complexity Trustworthiness of components Reduced development time Component certification Increased quality and productivity Emergent property prediction Requirement trade off Essentials for Successful Component-Based Software Engineering (CBSE): Independent Components: Components must be fully defined by their public interfaces, allowing for clear, standalone functionality. Component Standards: Adherence to standards that simplify the integration of various components. Middleware: Utilizes middleware to support and facilitate the integration of components. Development Process: The development process should be aligned with CBSE practices to ensure effective component utilization. Software Component: Functionality: Implements specific functionality regardless of execution environment or programming language. Independence: Operates as a standalone executable entity, which may consist of one or more executable objects. 23 TAs: Yashaswini Ippili & Ria Kulkarni  SOFTWARE ENGINEERING NOTES (UE22CS341A) Interface: The component interface is publicly available, with all interactions occurring through this defined interface. Component Interaction: Explicit Dependencies: Dependencies are specified through "required" interfaces, which detail the component’s interaction needs. Component Lifecycle: ○ Identification: Identifying potential software components. ○ Search and Selection: Searching for and selecting the appropriate components. ○ Composition: If no suitable component exists, composite components are created from existing ones, which may involve sequential composition or the use of adapters or “glue” to reconcile differing interfaces. ○ Validation: Ensuring the selected or composed component meets the required specifications. Component Development Stages: Forms of Component: ○ During Development: Represented using UML diagrams. ○ Packaging: Delivered as.zip files or similar packages. ○ Execution: Consists of code and data blocks ready for execution. Elements of a Component Model: Interfaces: Defines how the component interacts, including operation names, parameters, and exceptions, all detailed in the interface definition. Usage: Each component has a globally unique name and handle for identification and access. Deployment: Specifies how the component should be packaged and deployed for use in various environments. 24 TAs: Yashaswini Ippili & Ria Kulkarni  SOFTWARE ENGINEERING NOTES (UE22CS341A) Software Product Lines: These are engineering techniques for creating a portfolio of similar software systems from a shared set of software assets where Reuse is imperative Represent a family of manufactured product Product Line Architecture: This captures commonality and variability of product line components and compositions. Advantages 1) Create software for different products 2) User variability to customise software to each product Key Drivers for Reuse: Predictive software reuse Software artifacts created when reuse is predicted in one or more products Artifacts could be built as components or design patterns Engineering Framework: 25 TAs: Yashaswini Ippili & Ria Kulkarni  SOFTWARE ENGINEERING NOTES (UE22CS341A) Requirements Engineering: 1) First step in any software intensive development lifecycle 2) Difficult, error prone and costly 3) Errors introduced in this phase may propagate to downstream phases and this makes it expensive to fix 4) Critical for successful development of all downstream activities What is a requirement? A software product/project requirement is defined as a property which must be exhibited by software developed/adapted to solve a particular problem. It should specify externally visible behaviour of what the product does and not how the behaviour is achieved. This can be individual or set of requirements. Properties of Requirements: 1) Clear: precise and simple language; must use active present tense; constant terminology; avoid combining 2) Concise: describe a single property with as few words as possible 3) Consistent: no requirements should contradict each other 4) Unambiguous: should only have one interpretation 5) Feasible: realizable in specified time frame 6) Traceable: backwards to stakeholder request and forwards to software components 7) Verifiable: clear, testable criterion and cost-effective process to check it has been realised 8) Prioritized: this helps in achieving ordered workflow 9) Quantifiable: aids in testing and verifying Feasibility Study: It is defined as a short, low cost study conducted before the beginning of the project to assess its practicality. Activities conducted during a feasibility study: 1) Figure out Client/sponsor/user would have a stake in project 2) Current solution to the problem? 3) Target customers and future market space? 4) Potential benefits? 5) Scope on a high-level 6) High block level understanding of solution 7) Considerations in tech 8) Marketing strategy 9) Financial projections 26 TAs: Yashaswini Ippili & Ria Kulkarni  SOFTWARE ENGINEERING NOTES (UE22CS341A) 10)Schedule and high level planning; budget requirements 11) Issues, assumptions, risks and constraints 12)Alternatives and their consideration 13)Potential project organisation Requirements Engineering Process: 1) Step 1: Requirements Elicitation This phase involves working with all stakeholders to gather their needs, articulate the problem, identify and negotiate conflicts and establish a clear scope and boundary for the project. In this phase, 1) Stakeholder has been given an opportunity to explain their problem and needs 2) Involves understanding problem, domain, needs and constraints; identifying clear objectives and writing business objectives for the project. Elicitation Techniques: Based on the nature of the system being developed and the background experience of stakeholders, techniques are divided into two types: 1) Active Ongoing interaction b/w stakeholders and users Interviews; facilitated meeting Role-playing; prototyping Ethnography and scenarios 2) Passive Infrequent interaction Use cases; business process analysis and modelling Workflows and questionnaires Checklist and documentation 27 TAs: Yashaswini Ippili & Ria Kulkarni  SOFTWARE ENGINEERING NOTES (UE22CS341A) 2) Step 2: Requirements Analysis This phase involves understanding requirements from both a product and process perspective. It also involves classifying and organising requirements into coherent clusters. Requirements are classified into: 1) Functional, non-functional and domain: - Functional: functionality or services the system should provide with different inputs and expression on how the system should behave - Non-functional: constraints on service or functions offered by the system (timing, dev process, etc) Often applied to the system as a whole Specify the criteria that is used to judge the operation - Domain: constraints on system from domain of the operation 2) System and user: - User: statements in natural language + informal context diagrams system/subsystem and their interconnections and operational constraints - System: structured document; detailed desc of systems functions, services and operational constraints. This phase also involves modelling the requirements using Unified Modelling Language which is used to visualize, construct, specify and design code. Primary goals of modelling: 1) provide an understanding of the system 2) analyze and validate requirements 3) communicate the requirements in terms of who, what and interpreting it the same way Types of UML models: 1) Structural Static aspects of the system Entities in the system How are they related 28 TAs: Yashaswini Ippili & Ria Kulkarni  SOFTWARE ENGINEERING NOTES (UE22CS341A) 2) Behavioural Dynamic aspects of the system How do entities respond to stimulus In the analysis phase, use the fishbone diagram to visualize requirements w.r.t causes and effects. Activities conducted during analysis phase: - Recognise and resolve conflicts (functionality vs time vs cost) - Negotiate requirements - Prioritise requirements (MoSCoW - Must have, Should have, Could have, Won’t have) - Identify risks if any - Decide on build or buy and refine requirements Commercial Off The Shelf 3) Step 3: Requirements Specification This step involves the documentation of a set of requirements that is reviewed and approved by the customer and provides direction for software construction activities. This is usually achieved through a document called the Software Requirements Specification (SRS) which serves as: basis for customers and contractors/suppliers agreeing on what they will and will not do; specification for functional and non-functional requirements 29 TAs: Yashaswini Ippili & Ria Kulkarni  SOFTWARE ENGINEERING NOTES (UE22CS341A) Why do we document? 1) Visibility 2) Formalisation leads to better clarity 3) User support 4) Team communication 5) Maintenance and evolution Characteristics of Documentation: 1) Accurate and current 2) Appropriate for audience 3) Maintained online 4) Simple but professional What should be included in documentation: 1) Functionality: what is the software supposed to do 2) External interface: how does it interact with people, hardware and software 3) Non functionality: quality criteria for functionality 4) Performance: speed, response time, recovery time, etc 5) Other attributes: availability, portability, correctness, maintainability 6) Design constraints imposed Required standards in effect Implementation language Policies for DataBase integrity Resource limit Security Operating environment 4) Step 4: Requirements Validation & Verification When there is an error in requirements engineering, repairing it downstream can be expensive. Hence, we must perform rigorous validation and verification of the requirements gathered. Validation: Checking whether the software requirements if implemented will solve the right problem and satisfy the user's need. Verification: Checking whether requirements have been specified correctly. Review whether the requirement follows these properties: Consistency Completeness 30 TAs: Yashaswini Ippili & Ria Kulkarni  SOFTWARE ENGINEERING NOTES (UE22CS341A) Verifiability Comprehensibility Traceability Adaptability Prototyping: Facilitates user involvement and ensures users and engineers have same interpretation Most beneficial in systems with many user interactions Model validation: Model represents all essential functional requirements (Use case model) Demonstrating each model is consistent (flow diagrams) Fishbone analysis to validate if requirements addresses the reasons for needing a solution to the problem Acceptance criteria: See if any requirements match the acceptance criteria NOTE: First 4 steps are iterative. 5) Step 5: Requirements Management Sometimes, due to some shift in plans, requirements may change. Developers should be prepared to incorporate these changes and have a plan ready. This is known as requirements management. Potential reasons for requirement change: Better understanding of the problem Customer internalizing Evolving environment and technology Management involves two facets Ensure requirement changes are addressed in all phases of the life cycle Ensure changes in requirements are handled appropriately 31 TAs: Yashaswini Ippili & Ria Kulkarni  SOFTWARE ENGINEERING NOTES (UE22CS341A) Requirements Traceability Matrix (RTM): It is a document that demonstrates the relationship between requirements and other artifacts. It's used to prove that requirements have been fulfilled. And it typically documents requirements, tests, test results, and issues Each phase in the life cycle progressively fills RTM Requirements traced along SDLC using the RTM Types of Requirements Tracing: 1) Forward tracing: Forward tracing involves tracking the progression of requirements from their origin through the various stages of development, such as design, implementation, and testing. It ensures that each requirement is addressed in the final product by verifying that all necessary design elements, code, and tests are in place. This helps to confirm that the project is on track to meet all specified requirements. 2) Backward tracing: Backward tracing is the process of verifying that each component of the final product, such as code, design, and test cases, can be traced back to specific original requirements. This ensures that every element in the project is justified by a requirement, preventing unnecessary or out-of-scope features from being included. Backward tracing also helps in validating that the product fully satisfies the initial requirements set by stakeholders. 32 TAs: Yashaswini Ippili & Ria Kulkarni  SOFTWARE ENGINEERING NOTES (UE22CS341A) Requirements Change Management: Change in requirements will impact plans, work products, etc Uncontrolled changes can have huge, adverse impact (cost, schedule, quality and expectation) Ensure only controlled changes by using a formal change management process as below: 1) Log the request for change and assign change request ID 2) Info to log: who is requesting? Why is the request coming in? What is being requested? 3) Perform impact analysis on work products and items 4) Estimate impact on scope, effort and schedule 5) Review impact with stakeholders 6) Solicit formal approval 7) Rework the work products/items 8) Log the following - When was it changed - Who all made changes? Reviewed changes? Tested changes? - Which release stream is it a part of? STUDENTS TO NOTE: This should not be your only source of preparation. Refer lecture slides, textbooks, reference books, etc. Below are some sources for better information: 1) https://qarea.com/blog/software-development-life-cycle-guide 2) https://xebrio.com/requirements-engineering/ 3) https://asana.com/resources/agile-methodology 33 TAs: Yashaswini Ippili & Ria Kulkarni