5.

Be Open to the Future

o Design systems to adapt to changes.
o Anticipate future requirements to avoid limitations.
6. Plan Ahead for Reuse
o Plan for reusable code and designs to save time.
o Effective reuse benefits development efficiency.
7. Think!
o Careful planning reduces errors and enhances system value.
o Thoughtful design leads to higher quality systems.

MODULE 2
MQP 1
3a. Explain Negotiating requirements & Validating requirements
Ans:
Negotiating Requirements
Negotiating requirements involves reconciling stakeholder needs and project constraints to ensure
realistic and achievable outcomes. The goal is to achieve a "win-win" result for all parties involved.
Key Activities in Negotiation:
1. Identifying Stakeholders:
o Identify the key individuals or groups involved in the project.
o Examples include customers, end-users, and development teams.
2. Determining Stakeholders' Win Conditions:
o Understand the objectives and expectations of each stakeholder.
o Win conditions might include specific features, timelines, or budget constraints.
3. Reconciling Win Conditions:
o Negotiate to balance stakeholder expectations with project constraints like time, budget,
and resources.
o Example: Adjusting feature priorities to meet deadlines while satisfying critical needs.
Outcome:
 A realistic project plan with mutually agreed-upon conditions, paving the way for successful
software development.

Validating Requirements
Validating requirements ensures the requirements are consistent, complete, and feasible, providing a
strong foundation for the development process.
Key Validation Questions:
1. Consistency and Relevance:
o Are requirements aligned with system objectives?
o Are they necessary, or do they add unnecessary complexity?
2. Clarity and Feasibility:
o Are requirements clear, unambiguous, and achievable within the technical environment?
o Example: A requirement specifying a response time of 1 second under defined
conditions.
3. Testability:
o Can the requirements be tested effectively once implemented?
 4. Conflict Resolution:
o Do any requirements conflict with others, and how are they resolved?
5. Source Attribution:
o Is the origin of each requirement clearly documented?
6. Model Validation:
o Does the requirements model accurately represent the information, functionality, and
behavior expected of the system?
o Example: Reviewing a UML diagram to ensure it matches functional requirements.
Outcome:
 A validated requirements model that is consistent, complete, and ready for subsequent design
and development activities.

Conclusion:
Negotiation focuses on balancing stakeholder needs with project constraints, while validation ensures
the requirements are clear, consistent, and feasible for successful implementation. Together, they form
a critical foundation for delivering quality software.

3b. Explain key steps are involved in establishing the foundational groundwork for a successful
software engineering project.
Ans:
Establishing the Groundwork for a Successful Software Engineering Project
The foundational groundwork of a software engineering project is crucial for its success. Properly
addressing the initial challenges ensures smooth progress throughout the development cycle. Here are
the key steps involved:
1. Identifying Stakeholders
 Definition: A stakeholder is anyone who benefits from or is impacted by the software system
being developed.
 Examples: Business managers, marketing teams, customers, end users, support engineers, etc.
 Purpose: It is essential to identify all stakeholders as they have different views, needs, and
expectations of the system. Understanding these helps in defining requirements that satisfy
multiple interests.
2. Recognizing Multiple Viewpoints
 Varied Stakeholder Interests: Different stakeholders may have distinct goals. For example,
marketing teams might focus on the system's marketability, while end users might prioritize
usability.
 Balancing Viewpoints: Software engineers need to consider all these viewpoints and ensure
that the requirements chosen are internally consistent and cater to the broader needs of the
project.
3. Working toward Collaboration
 Collaboration Over Committee: While a committee may not define requirements,
collaboration is essential for gathering different perspectives.
 Role of Project Champion: A project champion (e.g., a business manager or senior
technologist) often takes the responsibility of making the final decision regarding the
requirements after considering input from stakeholders.
4. Asking the First Questions
 Context-Free Questions: At the project’s inception, it's important to ask broad, context-free
questions that help understand the project’s goals. These questions focus on customer needs and
expectations.
o Examples:
 Who is requesting this work?
 Who will use the solution?
 What are the economic benefits of this solution?
 Are there alternative solutions available?
 Identifying Key Information: These questions help identify stakeholders, potential benefits,
and any existing solutions that could be considered.
5. Gaining a Better Understanding of the Problem
 Understanding Customer’s Perception: After identifying the stakeholders and the project’s
goals, it is important to delve into the specifics of the problem and solution.
o Examples:
 What would constitute a successful solution?
 What problems will the solution address?
 What constraints (e.g., performance issues) might affect the solution?
6. Meta-Questions for Effective Communication
 Meta-Questions: These help assess the effectiveness of the communication process itself.
o Examples:
 Are you the right person to answer these questions?
 Are my questions relevant to your needs?
 Can anyone else provide more information?
 Am I asking too many questions?
 Purpose: These meta-questions ensure that the communication remains focused and effective,
ultimately leading to a successful elicitation of requirements.

Conclusion
By following these steps—identifying stakeholders, recognizing multiple viewpoints, fostering
collaboration, asking critical questions, and validating communication—software engineers can lay the
groundwork for a successful software engineering project. This comprehensive approach ensures a
clear understanding of stakeholder needs and project goals, setting the stage for successful software
development.

3c. Provide a brief overview of the key tasks involved in requirement engineering.
Ans:
Brief Overview of Requirements Engineering
Requirements Engineering is the process of identifying and defining user expectations for a new or
modified product. It plays a crucial role in software development as it helps bridge the gap between
customer needs and the subsequent design and construction of the system.

Key aspects of Requirements Engineering include:

 Communication and Modeling: It begins during the communication phase of the software
development process and continues into modeling. This ensures a clear understanding of what
the customer wants.
  Adaptability: Requirements Engineering must be tailored to fit the specific needs of the
process, project, product, and the people involved.
 Building a Bridge: It creates a pathway for translating user requirements into design and
development tasks.

7 Key Tasks of Requirements Engineering

Requirements Engineering involves seven distinct tasks:
1. Inception: Establishes an initial understanding of the problem and the stakeholders involved.
2. Elicitation: Gathers detailed information about user needs and objectives.
3. Elaboration: Refines and expands the requirements based on user scenarios.
4. Negotiation: Resolves conflicts and prioritizes requirements among stakeholders.
5. Specification: Documents the requirements in clear and precise terms.
6. Validation: Ensures that the requirements are complete, correct, and consistent.
7. Requirements Management: Monitors and manages changes to requirements throughout the
project lifecycle.
This structured approach to understanding and documenting user expectations is essential for
developing software that meets the intended goals and provides value to users.

4a. Demonstrate access camera surveillance via Internet – display camera views function with a
neat activity diagram.
Ans:
Use Case: Access Camera Surveillance via the Internet – Display Camera Views
Actor: Homeowner
Goal: Homeowner accesses camera surveillance and views live camera feeds via the internet.
Formal Use Case Outline:
1. Goal in Context: Homeowner accesses live camera surveillance via the internet.
2. Precondition: The homeowner must have an account and be logged into the SafeHome
Products website.
3. Trigger: Homeowner chooses the "Surveillance" option after logging in.
4. Scenario:
o Homeowner logs in with credentials.
o Selects "Surveillance" and "Pick a Camera."
o The system displays a floor plan or list of available cameras.
o The homeowner selects a camera, and the system displays the live video feed.
5. Exceptions:
o If the floor plan is not available, an alternate camera selection method is provided.
o If credentials are incorrect, the system prompts the user for re-entry.
o If there is a delay or error in the video feed, the system notifies the homeowner of the
issue.
Developing an Activity Diagram
The UML activity diagram supplements the use case by providing a graphical representation of the
flow of interaction within a specific scenario. Similar to the flowchart,
An activity diagram uses:
 Rounded rectangles to imply a specific system function
 Arrows to represent flow through the system
 Decision diamonds to depict a branching decision
 Solid horizontal lines to indicate that parallel activities are occurring
A UML activity diagram represents the actions and decisions that occur as some function is
performed.

4b. Explain key steps involved in building a requirement model, and how do they contribute to
the software development process?
Ans:
Key Steps in Building a Requirement Model
1. Identify Stakeholder Requirements:
o Collect and analyze information from stakeholders (users, clients) to identify what the
system must achieve.
o Ensures that the software meets the actual needs of the users.
2. Develop Scenarios (Scenario-based Elements):
o Create use cases, activity diagrams, and scenarios from the user's perspective.
o Helps in understanding how the system will be used in real-world situations, ensuring it
aligns with user expectations.
 3. Define System Behavior (Behavioral Elements):
o Use state diagrams and sequence diagrams to represent how the system behaves in
response to external events.
o Defines how the system will react to different conditions and inputs, making sure it
behaves as expected.
4. Identify System Components (Class-based Elements):
o Identify objects and categorize them into classes that share common attributes and
behaviors.
o Helps in structuring the system, creating a clear mapping of objects and operations, and
ensuring modularity in the design.
5. Data Flow and Information Transformation (Flow-Oriented Elements):
o Use data flow diagrams (DFD) and control flow diagrams to describe how data moves
and is processed within the system.
o Provides clarity on how inputs are processed to outputs, ensuring smooth information
flow and reducing errors.
6. Use Analysis Patterns:
o Leverage reusable solutions, like design patterns, for common problems to speed up the
process.
o Improves efficiency, reusability, and consistency in the design phase by referencing
established patterns.
Contribution to Software Development Process
 Clarity and Precision: The requirements model clarifies what the software needs to do and how
it should behave, reducing ambiguity.
 Structure and Organization: Helps organize the system's components, flow, and behaviors,
making the development process more efficient.
 Facilitates Design and Implementation: The model acts as a blueprint that guides the
transition from analysis to design, ensuring smoother development.
 Improved Communication: Serves as a communication tool between stakeholders, developers,
and testers, ensuring everyone is aligned on system requirements.

4c. Demonstrate class-based modelling and identify the analysis classes

Ans:
Class-Based Modeling
Class-based modeling involves identifying the objects the system will manage, their attributes,
operations, relationships, and collaborations. The goal is to define how the system's components
(classes) interact and how they will perform necessary operations.
Key Elements of Class-Based Modeling:
1. Classes: Represent the types of objects in the system.
2. Objects: Instances of the classes.
3. Attributes: Properties or characteristics of the class objects.
4. Operations: Functions or methods that operate on the objects to manipulate data.
5. CRC Models (Class-Responsibility-Collaborator): Helps in defining the responsibilities and
collaborators of a class.
6. Collaboration Diagrams: Show how objects collaborate to achieve a specific function.
7. Packages: Group related classes together for better organization.
Identifying Analysis Classes
To identify analysis classes, we typically analyze the system's requirements and use cases, looking for
nouns, entities, events, and roles. These entities often point to potential classes.
Here are common types of analysis classes:
1. External Entities:
o Example: A "User" class, representing a person interacting with the system.
o Role: External systems or users providing input or receiving output.
2. Things:
o Example: A "Report" class or "Product" class.
o Role: Represents objects or items that are part of the system's information domain.
3. Occurrences/Events:
o Example: A "Transaction" class.
o Role: Represents events, like a completed purchase or system action.
4. Roles:
o Example: A "Manager" class or "Customer" class.
o Role: Represents people interacting with the system in a particular capacity.
5. Organizational Units:
o Example: A "Department" or "Team" class.
o Role: Groups or organizational structures that influence system behavior.
6. Places:
o Example: A "Warehouse" or "Factory" class.
o Role: Physical locations in the system's context.
7. Structures:
o Example: A "Sensor" or "Machine" class.
o Role: Represents hardware or components in the system that interact with the software.

Example:
Let’s say we are designing a library management system. Here's how we can identify the analysis
classes:
1. External Entity: "User" – represents a person using the library system.
2. Thing: "Book" – represents the books in the library.
3. Event: "Borrowing" – represents the action when a user borrows a book.
4. Role: "Librarian" – a person managing the library.
5. Place: "Library Branch" – a physical location where books are managed.
6. Structure: "Barcode Scanner" – a device used for scanning books.

This approach helps to map out the objects the system needs to manage and interact with, making it
easier to structure the system's architecture effectively.

MQP 2
3a. With an example, describe the Class-Responsibility-Collaborator(CRC) modeling
Ans:
Concept of Class, Responsibilities, and Collaborations (CRC Model)
CRC Modeling Overview:
 Class-Responsibility-Collaborator (CRC) Modeling is a method for identifying and
organizing relevant classes for a system’s requirements.
 Visualized using index cards with three sections:
 oClass Name: At the top of the card.
oResponsibilities: Listed on the left side (what the class knows or does).
o Collaborators: Listed on the right side (other classes that help fulfill the responsibilities).
Key Concepts:
1. Classes:
o Entity Classes: Represent persistent data stored in a database (e.g., User, Product).
o Boundary Classes: Manage user interface interactions (e.g., LoginForm, Dashboard).
o Controller Classes: Handle the overall flow of operations (e.g., OrderController,
UserController).
2. Responsibilities:
o Responsibilities should be distributed across classes to meet system needs.
o Each responsibility should be defined as broadly as possible.
o Encapsulate related data and behavior within the same class.
o Information should be localized within a single class, not spread across multiple classes.
o Share responsibilities among related classes when needed.
3. Collaborations:
o A class can fulfill its responsibilities through:
 Self-operations: Using its own methods to manipulate its attributes.
 Collaboration: Interacting with other classes to accomplish tasks.

Example of CRC Modeling

Example: Library Management System
 Class Card: Book
o Responsibilities:
 Store book details (title, author, ISBN).
 Check availability status.
o Collaborators:
 LibraryMember: To check out or return the book.
 LibraryCatalog: To search for books.
 Class Card: LibraryMember
o Responsibilities:
 Register member details.
 Borrow and return books.
o Collaborators:
 Book: To access book information for borrowing.
 Class Card: LibraryCatalog
o Responsibilities:
 Search for books by title or author.
 List all available books.
o Collaborators:
 Book: To retrieve book information during searches.

Review Process
1. Participants receive a subset of CRC cards.
2. Use-case scenarios are organized.
3. The review leader reads each use case, passing a token to the class responsible.
4. The class holder describes its responsibilities.
5. Modifications are made if the responsibilities do not meet the use case.
Summary
CRC modeling simplifies the identification of classes, their roles, and how they work together in a
system, fostering a clear understanding of the design.

3b. Explain three types of QFD with examples

Ans:
Three Types of Quality Function Deployment (QFD)
Quality Function Deployment (QFD) is a powerful tool used in quality management and software
engineering to translate customer needs into technical requirements. The QFD technique focuses on
maximizing customer satisfaction by ensuring that their needs are incorporated into every stage of the
development process. The QFD process identifies three types of requirements:

1. Normal Requirements
 Definition: These are the basic, explicitly stated requirements that customers mention during
meetings. Their presence is necessary to meet customer expectations, and if they are provided,
the customer will be satisfied.
 Examples:
o A customer asks for a specific graphical display in an application (e.g., a dashboard
with real-time data visualization).
o Specific system functions like login, registration, or data export.
o Performance levels, such as a software system responding within 2 seconds of input.
 Explanation: Normal requirements form the baseline features that the system must deliver. If
these are missing or poorly implemented, the customer will be dissatisfied, but if they are met,
the customer will be content.

2. Expected Requirements
 Definition: Expected requirements are implicit needs that the customer assumes will be present
in the product or system, though they may not specifically mention them. These requirements
are often fundamental and expected as part of the standard experience. The absence of expected
requirements can lead to significant customer dissatisfaction.
 Examples:
o Ease of human/machine interaction (e.g., user-friendly interfaces, intuitive navigation).
o System reliability and operational correctness, where the system should function
without errors under normal conditions.
o Ease of installation: The system should be easy to install without complications (e.g.,
simple setup wizards for software installation).
 Explanation: These requirements typically go unnoticed when present but can cause major
dissatisfaction when they are absent. They are the baseline expectations that the customer takes
for granted.

3. Exciting Requirements
 Definition: Exciting requirements are the "delighters" or unexpected features that go beyond the
customer's stated or expected needs. These features do not necessarily need to be present for
customer satisfaction, but when included, they can significantly increase customer delight and
loyalty.
 Examples:
o Voice searching in a mobile app, where a user can search hands-free.
 o A multi-touch screen in a mobile device that exceeds basic touch functionality.
o A software application with smart suggestions or automatic report generation based
on user activity, providing a more intuitive user experience.
 Explanation: These are the "wow" factors that customers don't explicitly ask for but are
pleasantly surprised by when they experience them. They significantly improve customer
satisfaction but are not mandatory for the product’s functionality.

Conclusion:
QFD uses these three types of requirements to ensure that the final product not only meets the basic
expectations of the customer (Normal and Expected Requirements) but also provides additional value
that exceeds customer expectations (Exciting Requirements). By systematically identifying and
deploying these requirements, QFD helps create products that enhance customer satisfaction and
loyalty.

4a. Explain scenario based model with example.

Ans:
Scenario-Based Modeling
Definition:
Scenario-based modeling focuses on depicting how users interact with a system and the sequence of
activities performed during the use of software. It is a way to capture the functional requirements and
user behavior through use cases.
Key Elements:
1. Use Cases: A scenario that outlines how an actor (user or system) interacts with the system to
achieve a goal.
2. Actors: External entities (like users or other systems) that interact with the system.
3. System Behavior: Describes the sequence of actions performed by the system in response to
user inputs.
Example:
Use Case: Access Camera Surveillance via Internet – Display Camera Views (ACS-DCV)
Actor: Homeowner
Main Scenario (Primary Scenario):
1. Homeowner logs onto the SafeHome Products website: The homeowner navigates to the
surveillance system's website.
2. Homeowner enters their user ID and two passwords: The system validates the user’s
credentials for security.
3. System displays all major function buttons: After login, the system shows options like
"Surveillance," "Settings," etc.
4. Homeowner selects "Surveillance" from the major function buttons: The homeowner clicks
on the surveillance option to access camera views.
5. Homeowner selects "Pick a camera": The homeowner is prompted to choose which camera to
view.
6. System displays the floor plan of the house: The system shows a map or layout with camera
icons on the floor plan.
7. Homeowner selects a camera icon: The homeowner clicks on a camera from the floor plan to
view its live feed.
8. Homeowner clicks the "View" button: The homeowner confirms the selection to view the live
feed.
 9. System displays video output: The system shows the live camera feed in a viewing window.
The feed updates at one frame per second.
This use case details the interaction between the homeowner and the system for accessing camera
views via the internet. It describes the steps involved from the actor's perspective, guiding the system's
required functionality.

4b. How can you develop an effective use case? Develop a UML use case diagram for home
security function.
Ans:
Developing an Effective Use Case
To develop an effective use case, the following steps are important:
1. Identify the Actors:
o Determine who or what will interact with the system (e.g., users, external systems, or
devices). For the home security system, actors might include "Homeowner," "Security
System," and "Administrator."
2. Define the System's Scope and Goals:
o Establish the boundaries of the system and clarify the main objectives that need to be
achieved. For instance, the goal could be to provide secure monitoring and alert
functionalities for the home.
3. Capture the Main Use Cases:
o Describe the major functionalities the system should support, focusing on the most
important tasks the actors will perform, such as "Monitor Camera Feed,"
"Activate/Deactivate Alarm," "View Alerts," etc.
4. Describe Interactions and Flows:
o For each use case, define the steps that need to be performed, highlighting how the
system and actors interact. Use simple and clear language to explain each step involved
in achieving the goal.
5. Handle Exceptions or Alternative Flows:
o Identify any potential errors or variations in the typical flow, such as system failures, or
alternate scenarios like "Camera Failure" or "Alarm Triggered."
6. Validate the Use Case:
o Ensure that the use case addresses the user's needs and expectations. Involve stakeholders
in reviewing and validating the use case to ensure it is comprehensive and accurate.

Example Use Case for Home Security System:

Use Case: Activate Home Security System
UML Use Case Diagram Sketch
 Actor: Homeowner
 Description: The homeowner activates the home security system when leaving the house to
ensure protection against break-ins.
 Preconditions: The system is turned off.

 Main Flow:
1. The homeowner opens the security app.
2. The homeowner selects the ―Activate‖ option.
3. The system turns on and confirms activation.
4. The homeowner receives a confirmation message on their phone.
  Postconditions: The system is active and monitoring the premises.

 Exceptions:
o If the system fails to activate, an error message is displayed.
This approach ensures that the use case captures the essential functionality while addressing potential
issues and alternative scenarios.

MODULE 3
MQP 1
5a. Explain Agile Process and its principles
Ans:
Agile Process
An Agile Process is a flexible and iterative approach to software development, addressing the
challenges of changing requirements and unpredictable customer priorities. It emphasizes adaptive
planning, iterative delivery, collaboration, and continual improvement. Key characteristics include:
1. Embracing Change: Requirements and priorities may evolve during the project.
2. Concurrent Activities: Design and construction proceed together to validate design early.
3. Iterative Approach: Analysis, design, construction, and testing are not strictly sequential.

Principles of Agility
1. Customer Satisfaction: Deliver valuable software early and continuously to meet customer
needs.
2. Welcome Change: Adapt to changing requirements, even late in development.
3. Frequent Delivery: Deliver functional software in short intervals (e.g., every few weeks).
4. Collaboration: Ensure continuous communication between business teams and developers.
5. Motivated Teams: Support and trust motivated individuals for project success.
6. Face-to-Face Communication: Prioritize direct communication for effective collaboration.
7. Working Software: Progress is measured by the delivery of working software.
8. Sustainable Development: Maintain a steady, sustainable pace of development.