1]Page @ Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act. Unit - Il Software Requirements Engineering and Analysis 1. Modeling Modeling in software engineering is the process of creating abstract represemtatiofislof a software system to understand, analyze, design, and communicate its structtie and behavior before actual development. These models help in visualizing the System from, different perspectives and ensure that all stakeholders have a clear undersfaneling of th system. 1.1 Requirements Engineering Requirements Engineering (RE) is the process.of gathering, analyzing, documenting, and ‘managing the requirements of a software or system to ehsure it meets stakeholders’ needs. It is a crucial phase in software development that helps avoid project failures due to unclear or incomplete requirements. Requirement ‘A requirement is a docuntented need, condition, or capability that a system, software, or product must meet to fulfill stakelioldeF€xpectations. It serves as a guideline for development, ensuring that the final product works &s intended. ‘Typesof Requirements A. Functional Requirements ~ Define specitic functions or features the system must have (e., user authentication, data processing), 2. Non-Funetional Requirements — Specify system qualities like performance, security, usability, and scalability 3. Business Requirements — Describe high-level needs and goals from a business perspective. 4, User Requirements ~ Define what users need from the system in terms of interaction and experienee.2 Page © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act. System Requirements ~ Detail the technical specifications for hardware, software, and infrastructure, 6, Performance Requirements ~ Set benchmarks for speed, responsiveness, and efficiency. 7, Security Requirements ~ Outline data protection, authentication, and access control measures. 8, Regulatory & Compliance Requirements ~ Ensure adherence to legal_and industry standards Importance of Requirement Engineering 1. Clear Understanding: Ensures a clear and shared understanding of project goals among stakeholders, Reduces Risks: Identifies potential issues eafly, mitiitizing project risks and failures. 3. Cost Efficiency: Prevents costly changes and rework, by defining requirements upfront Improves Quality: Ensures the final product meets user'eeds and expectations. 5. Enhances Communication: Bridges the gap between stakeholders and development teams. 6. Guides Developmes : Provides @ roadinap for design, development, and testing. 7. Ensures Complisinee: Helps teet regulatory and business standards. 8, Facilitates Sealability: Allows for future growth and adaptability of the system, 9. Boosts User Satisfaction: Delivers a product that aligns with user needs and expectations. 10, Supports Decision-Making: Provides a basis for prioritizing features and resources. 1.2 Requirements Engineering Tasks 1. Inception: This is the initial phase where the need for a software system is identified, and key stakeholders (clients, users, developers) are recognized. Key A ‘+ Identifying project stakeholders (who will use or be affected by the system), + Understanding the problem domain.31 Page @ Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act. + Discussing the high-level goals and objectives of the software, + Defining preliminary system boundaries, + Assessing the feasibility of the project. Example: A company wants to develop an e-learning app. In this stage, they identify teachers, students, and administrators as stakeholders and define the goal of creating an interactive earning platform. 2. Elicitation: The process of gathering requirements from stakeholders using! Vatious techniques. Key Activities: + Conducting interviews with users, clients, and domain experts. ‘+ Using questionnaires and surveys to colleet feedback) ‘+ Observing current systems and workflows. + Conducting brainstorming sessions, + Reviewing similar existing systems, + Performing Joint Application Development (JAD) sessions. Example: Developers ifferview teachers to understand what features they need in the e- learning app, such as quizzes, live séssions, and progress tracking. 3. Elaboration: This phase refines and expands the gathered requirements to make them more detailed and structired. Key Activities: + Developing models (Use Case Diagrams, Data Flow Diagrams, ete). + Identifying functional and non-functional requirements, ‘+ Creating detailed descriptions of system behavior, + Establishing relationships between different requirements. Example: Afer discussing with teachers, developers create detailed use case diagrams for user roles like "Student," "Teacher," and "Admin," showing how they interact with the system.alPace @ Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act. 4, Negotiation Since different stakeholders may have conflicting requirements, this phase ensures a balanced and mutually agreeable solution. Key Activities: ‘+ Identifying conflicting requirements. ‘+ Prioritizing critical features based on business value and feasibility + Resolving disagreements through discussions and trade-offs. + Documenting accepted requirements. Example: Teachers want real-time video streaming, but developers sty increases server costs. They negotiate and agree to include pre-recorded video lectures as cost-effective alternative. 5. Specification The process of formally documenting the agreed-upon requirements in a structured manner. Key Activities: ‘+ Writing a Software Requiréiitent Specification (SRS) document. + Using structured formats (te diagrams, models), + Defining funeti¢nal, non-functiéial, and business requirements. Example: Developers create an SRS document specifying that the system should support "student login, course) enrollment, and progress tracking" with detailed functionality descriptiohs, 6. Validation Ensures (that the documented requirements are correct, complete, and feasible before development begins. Key Acti + Conducting requirement reviews with stakeholders. ‘+ Using prototyping to validate requirements. + Performing test case generation to check requirement elarityS[Page @ Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act. + Identifying inconsistencies, ambiguities, or missing requirements Example: Developers create a prototype of the e-learning app’s login and course dashboard. ‘Teachers and students test it and suggest improvements before finalizing the requirements. 7, Requirements Management ‘This phase deals with tracking, controlling, and updating requirements throughout the project lifecycle Key Activities: ‘+ Maintaining a requirements database or repository + Handling changes in requirements systematically. ‘+ Ensuring traceability (linking requirements to design and testing). ‘+ Version control for requirements documentation, Example: After launching the app, users request a "datk mode” feature, This change is evaluated, documented, and integrated into futurepupdates while keeping track of modifications, 1.3 Establishing the Groundwork Establi ing the Groundwork in Software Engineering refers to the initial phase of a project where the foundations laid for Successful development. This phase involves defining the project's scopessobjectives, and constraints, as well as identifying stakeholders and understanding their needs. It Sets the stage for all subsequent activities and ensures that the tcam has clear dircetion and shared understanding of what needs to be achieved. ‘Example Scenari A compliny wants to develop a mobile app for online food delivery. During the "Establishing the Groundwork" phase: ‘+ The problem statement is defined: "Create an app to connect customers with local restaurants for food delivery.” + Stakeholders include customers, restaurant owners, delivery personnel, and the development team,6| ge © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act. + Objectives are set: "Provide a user-friendly interface, real-time order tracking, and secure payment options." ‘+ The scope is determined: "The app will handle order placement and tracking but will not manage restaurant inventory.” Feasibility studies confirm the project is viable within the budget and timeline ‘+ A vision document is created to guide the team and stakeholders. 1.4 Identifying Stakeholders Identifying stakeholders in sofiware engineering is the process of recognizing alhindividuals ‘groups, or entities that have an interest in or are affected by the software development project. Stakeholders play a crucial role in defining requirements, settig expectations, and influencing project decisions. ‘Types of Stakcholders in Software Enginesting Primary Stakeholders (Directly afféeted by the system) © Clients ~The organization or indi iddals funding the project. © End-Users ~ The people'who will use the software (customers, employees, students, ete,). Project Managers — Oversee prdject timelines, budgets, and deliverables. Secondary Stakeholders (Indirectly affected by the system) ©. (Software Déveldpers ~ Design, implement, and test the software, © UWUX Designers ~ Ensure the system is user-friendly. © Quality Assurance (QA) Testers — Validate that the software meets requirements. © System Administrators ~ Manage deployment, maintenance, and security, Regulatory & Compliance Stakeholders © Legal and Compliance Teams ~ Ensure adherence to laws, security standards, and industry regulations o Government or Industry Regulators ~ Provide guidelines for software development, in regulated industries (e.g., healthcare, finance)71Pege @ Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act. 4, External Stakeholders © Suppliers & Vendors ~ Provide third-party services, tools, or software integrations. Investors — Fund the project and expect business returns. How to Identify Stakeholders? Brainstorming Sessions — Discuss potential stakeholders with the project team, + Interviews & Surveys — Gather insights from business owners, end-usefs, and domain experts, + Stakeholder Analysis Matrix — Classify stakeholders based on their level Of influence and interest. + Reviewing Documentation — Analyze contracts, business/plans)or previous project reports. 1.5 Recognizing Multiple Viewpoints Recognizing Multiple Viewpoints in Software Engineering refers to the process of understanding and addressing the diverse perspectives, needs, and expectations of different stakeholders involved in.a project! Since stakeholders often have varying roles, interests, and priorities, their viewpoints, on thesis¥Stem's requirements and functionality may differ. Recognizing and recongiling these multiple viewpoints is essential for creating a system that satisfies all stakeholdéts and avoids\conflicts. Steps to Recognize and Manage Multiple Viewpoints: 1. Identify Stakeholders? ©. List all individuals or groups with an interest in the project (e.g., end users, clients, developers, regulators). 2. Gather Viewpoints: fo Use techniques like interviews, surveys, workshops, or focus groups to collect stakeholder perspectives. © Example: Ask users about their pain points and ask developers about technical constraints.alP @ Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act. 3, Analyze Viewpoints: © Compare and contrast the different viewpoints to identify commonalities and conflicts. co Example: Users may want a feature that developers consider technically challenging. 4, Categorize Viewpoints: © Group similar viewpoints to simplify analysis and prioritization. © Example: Group all usability-related requirements from different user roles. 5, Reconcile Conflicts: © Facilitate discussions to resolve conflicts and find compromises. © Example: Balance user demands for features with development constraints by prioritizing must-have features. 6. Document Viewpoints: © Record all viewpoints and deci jons in a structured format (c.g., requirements document). © Ensure transparency and trag@ability ate Viewpoints: © Confirm with stakeholders\that their viewpoints have been accurately understood and addressed, o @Use prototypes Onmocktips to demonstrate how their needs will be met. 1.6 Working Toward Collaboration Working toward)collaboration in software engineering refers to the process of fostering teamwork,and effective communication among all stakeholders—developers, designers, testers, clients, and end-users—to ensure the successful development of a software project. Since software development is a complex and iterative process, collaboration helps align gs resolve conflicts, and improve efficiency. Key Aspects of Effeetive Collaboration 1, Clear Communication91Pece @ Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act. © Use structured documentation and meetings to align expectations. © Maintain transparency in decisions and project pr Cross-Functional Teamwork © Developers, designers, testers, and business analysts should work together rather than in isolation. © Encourage knowledge sharing between different roles 3. Agile Methodology © Use Agile practices like Serum or Kanban to promote itetitive development and continuous collaboration. © Conduct daily stand-up meetings to discuss progress and réadblogks. 4, Version Control & Code Collaboration © Use Git, GitHub, or GitLab for managing code, versions and enabling multiple developers to work on the same project. © Conduct code reviews and p: programmiifig t0 maintain code quality. 5. Requirement Gathering with Stakeholders © Involve clients, sets, and business/analysts in requirement discussions. fo Use techniques like brainstorming, interviews, and prototyping to align needs. 6. Feedback & Iteration © Enediirage frequent feedback loops through testing, prototyping, and usabil evaluations, © Thiplement continuous integration/continuous deployment (CCD) to streamline updates. Conflict Resolution & Team Bonding 9 Address conflict constructively by encouraging open discussions. © Build a positive work culture with mutual respect and accountability 1.7 Asking the First Questions10 | Page © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act, "Asking the First Quest where fundamental questions are posed to understand the problem, define requirements, and ns" in software engineering refers to the initial phase of a project set the direction for development. These questions help in gathering critical information about the project's scope, objectives, constraints, and stakeholders, Key Questions to Ask in the Initial Phase 1, Understanding the Problem Domain + What problem is the software intended to solve? + Who are the primary users, and what are their needs? + Are there any existing solutions, and what are their shortcomings? 2, Identifying Stakeholders + Who are the key stakeholders (clients, user dévelopéts, reatllators, et ‘+ What are their expectations from the software? ‘+ How will different stakeholders intekact with the gystem? 3. Defining Requirements ‘+ What are the core functional requirements (features, operations, data handling)? ‘+ What are the noféfunctidnal requirements (performance, security, scalability)? + Are there any legal, ethical, of regulatory constraints? 4. Te€hnical Considerations ‘+ Whaltechnology stack (programming languages, frameworks, databases) will be used? +) What are the system integration requirements? + Artthere any infrastructure or hosting considerations? 5. Project Feasibility & Constraints ‘+ What is the estimated budget and timeline for development? + What resources (team, tools, infrastructure) are available? ‘+ What are the potential risks and mitigation strategies?Mf Pas © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act, 6, Expected Outcomes & Success Criteria ‘+ What are the key performance indicators (KPIs) for project success? ‘+ How will the software be tested and validated? ‘+ How will updates and maintenance be handled post-deployment? 1.8 Eliciting Requirements Eliciting requirements is the process of gathering, understanding, and documenting the needs and expectations of stakeholders for a software system. It is a crucial phasélin Requirements Engineering, as it ensures that the final product aligns with user needs, business goals, and technical constraints. Key Techniques for Requirements Eli 1, Interviews © One-on-one discussions with stakeholders to understand their expectatio Can be structured (predefined questions) or unstructured (open discussions). Surveys & Question: s © Used to collect feedback fromaylange number of stakeholders efficiently. © Helps in understafiding preferences and common pain points, servation Analysts observe how" users interact with existing systems to identify issues and improvements. {94/ Useful fOnunderstanding implicit requirements that users may not express directly. 4, Braitstorming Sessions © Involves stakeholders discussing ideas, potential features, and system improvements, © Encourages innovative thinking and collaborative decision-making. Prototyping Creating a preliminary model of the software to gather feedback before full development,I Pog © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act, © Helps stakeholders visualize and refine requirements, 6. Use Cases & Scenarios © Defines specific situations in which users will interact with the system, © Helps in understanding functional requirements and user workflows. 7, Document Analysis © Reviewing existing documentation, business reports, and pre¥ious _ system requirements, © Helps in identifying constraints, compliance requirements, and dependencies, 8, Workshops & Joint Application Development (JAD) © Interactive sessions involving developerg)designers, and users to gollaboratively define requirements, Helps in resolving conflicts and aligning expectations General Process Models of Requirements Elicitation 1, Traditional Process Modeki/"This model follows a linear sequence for gathering requirements, Steps: 1, Identify Stakeholders ~ Determine who will provide requirements (users, clients, managers). Collect Requirements — Use interviews, surveys, and documents to gather {nformation. 3. Analyze Requirements ~ Identify feasibility, conflicts, and missing information, 4, Document Requirements — Create a Software Requirement Specification (SRS). 5, Validate Requirements ~ Ensure correctness and completeness with stakeholders. Best for: Well-defined projects with clear needs. Limitation: Not flexible for changing requirements.13 [Poe © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act. 2. Prototyping Model: This model involves building a working prototype to understand user needs better. Steps: 1. Gather Initial Requirements — Collect preliminary needs. 2. Develop Prototype ~ Build a basic version of the system. 3. Get User Feedback — Stakeholders interact with the prototype. 4, Refine Requirements ~ Modify based on feedback. 5. Finalize Requirements ~ Once satisfied, document them for development Best for: Complex or unclear projects needing user interaction, Limitation: Time-consuming and may lead to dhrealistigexpectations, 3. Joint Application Development (JADJ/Model: JAD involves collaborative workshops with stakeholders and developers to define requirements. Steps: 1, Conduct JAD Sessions Bring users, developers, and analysts together. Brainstorm & Discuss ~ Téehtify heeds, expectations, and constraints. 3. Create Models & Diagrams “Represent system processes visually. 4, Review 8 Finalizes Stakeholders agree on requirements, needin Best for: Large enterprise systen agreement from multiple stakeholders. Limitation: Requiresextensive time and scheduling efforts. 4. Cognitive Model: This model focuses on understanding how users think and behave when interacting with a system. Steps: 1, Observe Users ~ Study how they use existing systems. Analyze Thought Process — Identify pain points and expectations. Define Requirements ~ Document insights into formal requirements.1] Pog © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act, Best for: UX/UI-focused projects where user behavior matters, Limitation: May not cover all technical requirements. 5, Contextual Inquiry Model This model involves gathering requirements in the real environment where the system will be used, Steps: 1 Vi Users’ Workplaces — Observe tasks and workflows 2. Conduet Interviews — Ask questions while they perform tasks 3. Analyze & Extract Requirements ~ Identify needs baged on\teal-worlildata, Best for: Systems requiring deep domain knowledge (eqqmedical or industrial software). Limitation; Time-intensive and may not be'Sealable for large projects. 6, Agile-Based Elicitation Model This model follows an iterative approach, gathering requirements continuously through user feedback. Steps: 1. Identify Initial Requirements Basic features needed. 2, Develop/Small Iterations — Deliver working software frequently. 3. Get Feedhaek ~ Users test and provide input. 4, Refine & Adjust ~ Modify requirements as per feedback. Best for; Projects with evolving requirements (c.g., startups and dynamic markets) Limitation? May lead to scope creep if not controlled, 1.9 Collaborative Requirements Gathering Collaborative Requirements Gathering (CRG) is a structured, team-oriented approach in software engineering where developers, stakeholders, and customers work together to define, refine, and document the requirements of a software system. This ensures that all perspectives, are considered, leading to a well-balanced and clearly defined set of software requirements,15 | Page © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act, One of the most widely used techniques for CRG is the Facility Application Specification ‘Technique (FAST), where a joint team of developers and customers collaborates to identify the problem, propose solutions, negotiate approaches, and prepare an initial specification. FAST Approach for Collaborative Requirements Gathering FAST involves a structured meeting where stakeholders and developers collectively discuss and refine the requirements. The process follows these guidelines: 1, Neutral Meeting Site: The meeting should be conducted at a neutral location where both customers and developers can communicate openly. Preparation Rules: Clear guidelines should be set for participation, including, defining roles, objectives, and expected contributions. 3. Agenda Planning: The mecting agenda should covenal! key points while allowing room for innovative ideas and discussions. 4. Facilitator Role: A facilitator (who ean be a customets developer, or an outsider) ensures smooth discussions, manages conflict’, and maintains foctis. 5. Defin n Mechanism: Work tools like worksheets, flip charts, electronic boards, or virtual forums are used to dggument discussions and ideas. 6. Goals of FAST © Identify tieproblem © Define sélution elements © Negotiate different approaches © Prepare an initial specification for the software requirements Example: FAST for a Video Game System (Gamefun) 1) List of Objects + Display ~The game interface, + Menu ~ Start, exit, and game settings, + Sound — Different sound options. + Event ~ Game progression (moving between levels).16 Pag © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act, of Serv s + Setting Sounds — Adjusting game audio + GUI Customization — Changing color themes, + Help & Instructions ~ Providing user guidance. + Scoreboard — Displaying player scores. 3) List of Constraints + User-friendly interface ~ Should be easy to navigate + High speed — Smooth performance without lag + Low memory usage ~ Should not consume excessive system resources. + Cost efficieney ~ Should be affordable. 1.10 Usage Scenarios A.usage scenario is a specific sequence of interactions between a user and a software system, describing how the system is expected to behave\in a given situation. It helps in understanding system requirements, designing uséPinterfaces, and testing system functionality Key Aspects of Usage Scenarios 1. User-Centered — Focusesjon how users interact with the system, 2, Step-by-Step Interaction — Describes a logical flow of actions, 3. Real-World Context — Represents practical use cases. 4, Goal-Oriented— Helps achieve specific user objectives. ‘Can Be Detailed or High-Level ~ Ranges from broad descriptions to precise step-by- steBactions. ‘Types of Usage Seen ios 1, Normal Scenario (Happy Path) © Represents the expected and error-free interactiona7 [Page © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act, Example: A user logs into an e-commerce website, searches for a product, adds it to the cart, and completes the purchase. 2, Alternative Scenario © Describes variations in the normal flow due to different user choices or system conditions. © Example: A user selects a different payment method or applies a discounteode. 3. Exception Scenario © Describes what happens when an error or unexpected event oogurs. © Example: A user enters incorrect login credentials, leading an errobmessige. Example of a Usage Scenario Scenario: User Registration in a Web Application) 1, The user opens the website 2. Clicks on the "Sign Up" button, 3. Fills in personal details (nalfie, email, password) 4, Clicks "Register." 5. The system validates the input aiid sends a confirmation email 6, The userlicks the Verification link in the email. 7. ‘he systern/activaites the account, allowing the user to log in. 4.11 Elicitation Work Products Elicitation work products are the artifacts or documents created during the requirements clicitation)phase in software engineering. These work products help in capturing, analyzing, and refining system requirements to ensure that the final software meets user needs. Key Elicitation Work Products 1, Stakeholder Needs ist A document listing all key stakeholders and their expectations from the system.18 I Pag © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act, Use Cases & Usage Scenarios © Use Cases: Describe how users interact with the system to achieve specific goals. © Usage Scenarii Step-by-step interaction flows between users and the system, 3. User Stories (Agile Approach) © Short, simple descriptions of system features from an end-user perspective (c.g... "As a customer, I want to reset my password so that I ean access my accountyagain"), 4, Requirements Specification Documents © Software Requirement Specification (SRS): A formal document detailing funetional and non-functional requirements © Business Requirement Document (BRD): Captures high-level biisiness needs. 5, Prototypes & Wireframes © Prototypes: Interactive mockups of the system to Visualize functionality. © Wireframes: Statie blueprints of the System's UL) 6. Process Models & Diagrams: Flowehs : Show step-bysStep Processes © Data Flow Diagrams (DEDs):Mustrate data movement in the system. © Enti -Relationship Diagrams (ERD): Represent database relationships. 7. Metting Notes’& Interview Summaries © _Documentatioil of stakeholder meetings, interviews, and workshops to ensure key points are fecorded. 8. Risk Analysis Reports © Idemtfies potential risks in system development and suggests mitigation strategies. 9. Feasibility Study Report © Evaluates the project's technical, economic, and operational feasibility before development begins.19} Pace © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act 1.12 Developing Use Cases A use case is a fundamental modeling unit in software engineering that distinetly represents a system’s functionality. It depicts the software/system from an end-user’s perspective, ensuring that all necessary interactions between the user and the system are well-defined. User or ‘Action ‘Actor Steps in Developing Use Cases 1. Identifying Actors ‘+ Actors are external entities that use or interact with the system to achieve a goal. + Each actor represents a specific role rather than an individual person. + Actors ean be: © Primary Actors — Directly interact with the system to perform tasks, 6 Secondary Actors — Support the system indirectly to help primary actors achiev€ltheir goals Example: In af online bankitig system, + A€ustomer (primary actor) performs transactions. + A BankServer (secondary actor) processes requests in the background. 2, Iterative Requirement Elicitation + Identifying all actors in a single step is not always possible. + Initially, primary actors are identified. ‘+ In later iterations, secondary actors are included Example: In an e-commerce platform,201 Page © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act, + First Iteration: Identifying customers who browse and purchase products. + Later Iterations: Adding roles like admin (who manages inventory) and payment gateway (which processes transactions). 3, Developing the Use Case To define a use case, Jacabson’s Questions should be answered Question Example for an Online Banking System 1. Goals of the system? Provide banking servie®® like balanbe checking, fund transfers, bill payments 2 Who are the primary and secondary actors? Primary: Customer, Secondary) Bank database, Payiment Gateway. 3. Preconditions before system development? Bank database should be Operational, users must be registered, @. Main functions performed by the actor? Login, Gheck balance, transfer funds, pay bills. 5. Exceptions to be handled? Tnsufficieht finds, incorrect login details, transaction failures 6. Changes in actor beliavior? A user may update account details, switch accounts. 7. What system infoxdoes the actor produce? ‘Transaction logs, account updates. 8. What info does the actor receive? ‘Account balance, transaction confirmation, 9. Will the aétor inform extemal systems? Yes, alerts may be sent to mobile/email Example: Write a usecase for ‘login’ with a template and diagram. Use case template for login Use Case Course Registration System Primary Actor Student Goal in Context ‘To monitor all the functionalities required to register for the course Preconditions None. Scenario / Basic Flow 1. The system requests student to enter his name and password. 2. The student enters his/her name and password,2i|Poge © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act the student into the system, 3. The system validates the entered name and password and logs Exceptions 1. The control panel is not ready. 2, User name is invalid, 3. Password is incorrect. Priority Essential and must be implemented in course registration system, displayed to him / her. Posicondition If user logs in successfully then course informationamust be Secondary Actor ‘Administrator. é \ <> /> \, Validate data 1.13 Building the Requirements Model x Student NG ‘Administrator Building a Requirements Model involves structuring and representing the collected requirements jt a way, that Rélps stakeholders understand, analyze, and validate them before ‘moving to system design and implementation, ‘Analysis | [ Design model] | mode! System Requirement] | Sofware engineering | | analysis design221 Pee © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act, Key Steps in Building a Requirements Model 1. Eliciting Requirements ‘+ Gather customer needs using interviews, surveys, brainstorming, and workshops, ‘+ Identify functional and non-functional requirements, Example + Auser wants seeure login with two-factor authentication. ‘+ The system must support 1000 concurrent users. 2. Categorizing Requirements + Funetional Requirements: Define system behavior (g., "Uséh:must be able to reset password”). + Non-Functional Requirements: “Define system constiaints (e.g., "System must respond within 2 seconds"). + Business Requirements: High-level)goals of thé software (e.g., "Increase customer engagement by 20%"). 3. Choosing a Requirements Modeling‘Technique There are various technijes to tepresentfequirements: A, Use Case Modeling (UML Diagram) +QWUses actors (users) and/use eases (Functions). + Shots, how users interact with the system. ‘| Example:)A "Login use case shows that a user enters credentials, and the system Verifies them, Data Flow Diagrams (DFD) ‘+ Represents the flow of information in the system, ‘+ Shows how data is processed and stored. + Example: A DFD for an ATM system shows how user input is processed by the bank database,231 Po8 © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act, Entity-Relationship Diagram (ERD) ‘+ Used in database modeling, ‘+ Defines relationships between entities (e.g., Users, Orders, Payments). D. State Transition Diagrams + Represents different states of an object in the system. + Example: A document in a workflow system may have states like "Draft," "Under Review," and "Approved." 4. Validating the Requirements Model ‘+ Ensure completeness, consistency, and feasibility ‘+ Conduct reviews with stakeholders. ‘+ Identify missing or conflicting requifements Example: + Ifa requirement states that the system\should allow password recovery, but another says no user information should be stored, there's a conflict. 5, Documenting the Modeh(Software Requirement Specification - SRS) + Clearly defines System requirertiémts for developers, testers, and stakeholders. + Includesiuse cases, diagrams, constraints, and assumptions. Example SRS Sectiéns 1, Introduction'(Scope, Objectives) 2, Funetional Requirements (Login, Registration, Checkout) 3. Non-Funetional Requirements (Performance, Security) 4. Data Requirements (ERD, Database Schema) 5, System Models (DFD, UML Diagrams) 1.14 Elements of the Requirements Model2 |Poge © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act ‘A Requirements Model helps define, organize, and visualize the system's functional and non- functional aspects. It acts as a blueprint for software development. 1. Scenario-Based Elements (Describes System Interactions) ‘These elements focus on how users interact with the system, ‘+ Use Cases ~ Define system functionalities fromthe user's perspective. 1+ User Stories ~ Short desortions of user needs in simple language ‘* Use Case Diagrams — Graphiealrepresentation of actors and use eases. Example: + Actor: Customer «(Wee Case: "Place an Oriler" + Scomtario: Usenselects items, enters details, and confirms payment. 2. Behavioral Elements (Describe System Reactions & State Changes) ‘These defitie how the system behaves under different conditions. ‘+ State Transition Diagrams — Show how the system moves between different states (eg.. "Draft" > "Submitted" — "Approved. ‘* Sequence Diagrams — Illustrate interactions between system components. ‘* Activity Diagrams — Represent workflows and actions, Example:251Poce © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act + A document approval system has states: "Pending" ~» "Reviewed" + "Approved." 3. Class-Based Elements (Define System Objects & Relationships) ‘These represent the data structure and system objects. ‘+ Class Diagrams ~ Define system objects, their attributes, and relationships. © Entit Relationship Diagrams (ERD) — Represent database entities and their relationships Example: + Entities: User, Order, Product ‘+ Relationship: A User places an Order, and an Order conifaitis Produtts 4, Flow-Oriented Elements (Define Data Processing & System Logic) These elements define ho information is processed in the s¥8tem. ‘+ Data Flow Diagrams (DFD) — Illustrate data movéiment between system components, ‘+ Control Flow Diagrams ~ Show the logical flow)of execution in a system. Example: ‘= Inan ATM system, a DFDishowSithe process: User enters PIN — System verifies PIN — User selects action (withdraw, balance check, etc.) 1.15 Wr ing a Use Case 1. Definition /of Use Cases A use case tepresents the interaction between an actor (user or external system) and the system tolachiéve a spéeific goal. It defines how the system behaves in different scenarios. Example|n a library system, the use case "Reserve a Book" describes the steps a student follows to search, find, and reserve a book. Use cases can be represented as follows: Search a title 2. Components of a Use Case261 Poe © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act, Actors An actor is an entity (person, system, or device) that interacts with the system. ‘© Primary Actor ~ Initiates the interaction (e.g., Student). ‘* Secondary Actor ~ Supports the process (¢.g., Library Database). Example: + Student is an actor in a library system. ‘+ Bank System can be an actor in an online payment system, B. Use Cases Use cases describe system functionalities in terms of user interactions, Example (Library System Use Cases) 1, Search for a Book 2. Reserve a Book 3. Borrow a Book 4, Return a Book. 5. Pay Fine Each use case represents specifie behavior of the system. C. Relationships in Use Cases 1. Associaition: Defines interaction between an actor and a use case Example: A student is associated with the "Reserve a Book" use case, 2. Include Relationship: Represents a mandatory use case that must be executed as part of another use case. Example: The "Login" use case is ineluded in "Reserve a Book” because a student must log in before reserving a book. 3. Extend Relationship: Represents a conditional use case that extends another use case when needed.271 Pege © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act Example: A "Late Fee Caleulat the book is returned late, n" use case extends the "Return Book" use case only if 4. Generalization: Defines an inheritance relationship between use cases or actors Example: A “Librarian is a specialized actor of "Library Staff" because they have additional privileges. Q. Design use case diagram for user interaction with ATM system. For an ATM system following are'the"S@Biarios with the user. 1. User enters the card, types usennamesaind PIN. 2. User makes enquiry forbbalance. He may demand for getting the mini statement, 3. Usewithdraws the d&sired amount of money. "4, User may Weposit'some money. 5, Finally, user clo8es the session, 1.16 Negotiating Requirements Requirement negotiation is the process of resolving conflicts, inconsistencies, or differences among stakeholders regarding software requirements. It ensures that all parties agree on a common set of requirements before development begins. Example:28] Pace © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act. + A customer wants a highly secure system, but a developer is concerned about performance trade-offs. ‘+ The negotiation involves balancing security and performance to find optimal solution, Steps in Requirement Negotiation 1. Identify Conflicts ‘© Review requirement documents and feedback. © Find conflicting needs (e.g., cost vs. features, usability vs. cOimplexity) Analyze Stakeholder Interests © Understand each stakeholder’s concerns, ©. Prioritize based on project constraints (budget, timeline, feasibility). 3. Discuss and Resolve Differences, © Conduet meetings or workshops to discuss conflicting requirements. 9 Use trade-offs or compromises tosfind aiddle ground. 4, Document Agreed Requirements © Clearly definelfinal requirements and ensure all parties agree, © Avoid Vague descriptions that could lead to future disputes ‘Validate with) Sta sholders © Get formal approval before moving forward with development. Example of Requirement Negotiation Scenario; Developing an E-Commerce Websit Stakeholder | Requirement Conflict Negotiation Solution | Customer High-resolution Increases page load time | Optimize image images for products compression Developer Fast-loading website | Requires lower-quality | Use CDN and lazy images loading Marketing Team | More ads for revenue | Affects user experience | Limit ad frequency |291 Pee © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act, 1.17 Validating Requirements. Requirement validation is the process of ensuring that the gathered software requirements are complete, consistent, unambiguous, and feasible before development begins. The goal is to confirm that the requirements meet the needs of stakeholders and align with business objectives. Without proper validation, errors in requirements can lead to costly rework, project delays, or software that fails to meet user expectations Steps in Requirement Validation 1. Review Requirements © Check for completeness, correctness, and clarity. © Mdentify missing or conflicting requiremetits Perform Requirement Analysis © Ensure requirements are realistic and feasible © Evaluate if they align with technical andbusine$s constraints. 3. Validate with Stakeholders © Conduct meetingswithhusers, customers, and developers to confirm requirements. © Gather feedback and make necessary adjustments. 4. Verify Comsisteney. and Traceability 6 Eniure there are no contradictions between different requirements. ‘09 Check that each requirement is traceable to business objectives. 5, Perform Requirement Testing © Create test cases based on requirements to check if they can be implemented correctly Example of Requirement Validation Scenario: Online Banking System301 Poe © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act, Requirement Validation Cheek | Findings Solution The system must allow | Can the feature be | Security concems | Implement fund transfers implemented in data eneryption protocols securely? transmission The login should take | Is this performance | Server response | Optimize database no more than 2 seconds | goal realistic? time too slow queries The system should Does infrastructure | Scalability Use cloud-based support I million users | support this? concerns hosting 1.17 Quality Funetion Deployment (QFD) Quality Function Deployment (QFD) is a structured approach/tised to ftanslate customer needs into specific engineering requirements. It ensures that the final Software product meets user expectations by systematically prioritizingland aligiting software features with business goals. QED is often represented using 2 House of Quality (H6Q) matrix, which maps customer requirements to technical requirements. Key Objectives of QFD Identify customer needs (also‘éallled "Voice of the Customer"). Convert customér heeds into measurable technical requirements. Prioritize requiremignts based on business and technical feasibility Minimize enforsiby ensuring alignment between customer expectations and software design ‘Types of Requirements in QED QED classifies requirements into four types 1. Normal Requirements (Expected Needs) + These are the basic features that users expect in the software ‘+ If these features are missing, users will be dissatisfied, but having them does not necessarily increase satisfaction Example: A banking app must allow users to check account balance and transfer funds.31 Peg © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act, 2. Performance Requirements (Variable Needs) + These requirements directly impact user satisfaction. ‘+ The better the software performs these functions; the more satisfied users will be. Example: A faster response time in a search engine improv s user experience. 3. Exciting Requirements (Delighters) + Features that users did not explicitly request but, when provided, gfeatly enhance satisfaction, ‘+ Their absence does not cause dis tisfaction, but their presene@)ereates a)eompetitive advantage Example: A banking app automatically categorizing expenses and providing financial insights. 4. Unspoken Requirements (Latent Neéds) + These are needs that customers may.not be awate of but still expect when using the system. ‘+ Identifying thesejrequire$ deep analysis and experience. Example: Auto-save functionality in word-processing software prevents data loss, even though users may notfexplicitly request it Steps in QFD Proeess 1, Gather Customer Requirements: Conduct surveys, interviews, and market research, 2) Prioritize Requirements: Use techniques like ranking or weighting based on importance, 3, Translate into Technical Specifications: Define measurable engineering or software design fequirements, 4, Develop the House of Quality (HoQ) Matrix: A visual representation of how customer needs relate to technical requirements. Refine and Implement the Requirements: Develop prototypes, validate with users, and adjust based on feedback Example of QFD in Software Development321 Page © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act, For an e-commerce website, different types of requirements can be Requirement Type Example Impact Normal Requirement Secure login with two-factor | Essential, expected by users authentication Performance Requirement _ | Website should load in Directly impacts user under 2 seconds satisfaction Exciting Requirement ‘Al-based product Increases eustonier recommendations, engagement, Unspoken Requirement Auto-save cart items across | Prevents frustfation, devices improveSusability 1.17 Data Flow Diagram (DFD) ‘A Data Flow Diagram (DFD) is a graphical represéntation, of howsdata moves through a system, It illustrates ‘+ Processes that transform data + Data stores where data is held + External entities (sources and destinations of data) + Data flows (moyementtof data benween elements) DEDs are used to analyze, model, and document information flow within a system, making them essential iff PSquirement analysis and system design. Levels imData Flow Diagram (DED) DEDs can be divided into different levels, which provide varying degrees of detail about the system, The following are the four levels of DFDs: 1, Level 0 DED 2, Level 1 DED 3. Level 2 DED 4, Level 3 DED331 Poge © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act The choice of DFD level depends on the complexity of the system and the level of detail required to understand the system. Higher levels of DED provide a broad overview of the system, while lower levels provide more detail about the system’s processes, data flows, and data stores. A com ition of different levels of DFD can provide a complete understanding of the system. Level 0 Data Flow Diagram (DED) Level 0 is the highest-level Data Flow Diagram (DFD), which provides an overview of the entire system. It shows the major processes, data flows, and data stores in the system, without providing any details about the internal workings of these processes, It is also known as a context diagram. It’s designed to be an. abstraction View, showing the system as a single process with its relationship to external entities, Ityepresents the entire system as a single bubble with input and outputata indiated by incoming/outgoing arrows. — F E teservation Railway ——> Y aa cn Taleo) —___ ‘O-LEVEL DFD L-Leyel Data Flow Diagram(DFD) I-Level pitovides & more detailed view of the system by breaking down the major processes, ‘identified in the level 0 Data Flow Diagram (DFD) into sub-processes. Each sub-process is, depieted as a separate process on the level | Data Flow Diagram (DED). The data flows and data stores associated with each sub-process are also shown, In Level Data Flow Diagram (DFD), the context diagram is decomposed into multiple bubbles/processes. In this level, we highlight the main functions of the system and breakdown the high-level process of 0-level Data Flow Diagram (DFD) into subprocesses.34 Poge © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act Reservation iy = eS _ecs Oy 1-LEVEL DFD 2-Level Data Flow Diagram (DED) 2-Level provides an even more detailed view of the system by breaking down the sub-processes, identified in the level 1 Data Flow Diagram (DFD) iiito furthe® sub-processes. Bach sub- process is depicted as a separate process on the level 2 DFD, The data flows and data stores associated with each sub-process are also shown. 2-Level Data Flow Diagram (DEDY goes one step deeper into parts of 1-level DFD. It can be used to plan or record the specifieineeessary detail about the system’s functioning. wes 3° 0°-¢ 2-LEVEL DFD