UCSD Unit 1 Presentation

Course Objectives

• Understand the process of requirements analysis and its various techniques.

• Gain a comprehensive understanding of project risk management and software configuration management principles and practices.

• Develop an understanding of software quality assurance principles, techniques, and tools.

• Understand principles & practices of user-centered software design & its significance in modern technology.

• Gain proficiency in designing effective interfaces and creating prototypes for software systems.

• Develop proficiency in evaluating user interfaces using a variety of techniques and models.

Syllabus

• Unit I- Requirement analysis

  • Requirements Capturing: requirements engineering (elicitation, specification, validation, negotiation) prioritizing requirements (Kano diagram) - real life application case study.

  • Requirements Analysis: basics, scenario based modeling, UML models: use case diagram & class diagram, data modeling, data and control flow model, behavioral modeling using state diagrams - real life application case study, software Requirement Specification

• Unit II - Risk Management, Configuration Management

  • Project Risk Management: Risk Analysis & Management: Reactive versus Proactive Risk Strategies, Software Risks, Risk Identification, Risk Projection, Risk Refinement, Risk Mitigation, Risks Monitoring and Management, The RMMM plan for case study project

  • Software Configuration Management: SCM basics, SCM repository, SCM process, SCM tools such as GitHub, CASE – taxonomy, tool-kits, workbenches, environments, components of CASE, categories(upper, lower and integrated CASE tools).

• Unit III- Testing & Software Quality Assurance

  • Software Quality, Achieving Software Quality: Software engineering methods, Project Management techniques. Quality control and quality assurance. Software Reliability, SQA Tools, Goals and Metrics

  • Introduction to Software Testing: Principles of Testing, Testing Life Cycle, Phases of Testing, Types of Testing, Verification & Validation, Defect Management, Defect Life Cycle, Bug Reporting, GUI Testing, Test Management and Automation.

  • Software Process Improvement (SPI): What is SPI, SPI Process, The CMMI, The People CMM, Case study: SPI frameworks.

• Unit IV- Fundamentals of HCI & UCD

  • History, principles, and importance in modern technology. User-centered design (UCD) principles.

  • Includes the difference between good and poor interaction design, what interaction design is and how it relates to human-computer interaction and other fields, what is involved in the process of interaction design, the different forms of guidance used in interaction design, etc.

  • Interaction design basics, HCI in the software process, Design rules, Implementation support, Evaluation techniques, Universal design, User support, Individual differences, designing interfaces for all, User research and techniques, Understanding Personae, Good and poor design, Ergonomics.

• Unit V-Interface Design and Prototyping

  • Understanding Information Architecture, Understanding navigation models based on information architecture, High level concept sketches/wireframes. Balancing Function and Fashion, User Documentation and Online Help, Information Search, Information Visualization.

  • Exercise - Open and closed card sorting technique - Creating information architecture for a system.

  • Exercise - Creating low fidelity concept sketches for critical tasks of system/problems.

• Unit VI- UI Evaluation Techniques

  • What, why and when to evaluate, Design guidelines, Golden rules and heuristics, Goals of Evaluation, Evaluation criteria, Evaluation through: Expert analysis, User participation.

  • Testing techniques - Formative and Summative testing, surveys, peer reviews and so on. Cognitive models, Goal and Task hierarchy models, Linguistic models, Physical and Device models

Prerequisites: Software Development Methodologies (SDM)

• SDMs are structured approaches used to plan, manage, and control the process of developing software systems.

• These methodologies provide a framework that guides the development team in completing projects efficiently, on time, and within budget while meeting quality standards and customer requirements.

Key Features of SDM

• Process Organization: Define stages such as planning, design, coding, testing, and deployment.

• Collaboration: Emphasize communication between stakeholders, including developers, clients, and users.

• Flexibility and Adaptability: Some methodologies are rigid, while others allow for changes during the development process.

• Efficiency and Quality Assurance: Ensure efficient workflows and high-quality software delivery.

Popular SDM

• Waterfall Model:

  • Sequential and linear.

  • Each phase (requirement analysis, design, implementation, testing, maintenance) must be completed before the next begins.

  • Best for projects with well-defined requirements.

• Agile Methodology:

  • Iterative and incremental.

  • Focuses on flexibility, customer feedback, and delivering small, functional pieces of software.

  • Frameworks like Scrum, Kanban, and Extreme Programming (XP) fall under Agile.

• Scrum:

  • A subset of Agile.

  • Uses sprints (short development cycles) to deliver features iteratively.

  • Emphasizes roles like Scrum Master and Product Owner.

• Kanban:

  • Focuses on visualizing work and limiting work in progress.

  • Helps improve workflow efficiency.

• DevOps:

  • Combines development and operations for continuous integration and delivery (CI/CD).

  • Aims to reduce the time between writing code and deploying it to production.

• Lean Development:

  • Inspired by Lean manufacturing principles.

  • Focuses on minimizing waste, maximizing value, and rapid delivery.

• Spiral Model:

  • Combines iterative development with risk assessment.

  • Cycles through planning, risk analysis, engineering, and evaluation.

• RAD (Rapid Application Development):

  • Prioritizes rapid prototyping and iterative feedback.

  • Useful for projects requiring fast delivery.

Why Learn SDM?

• Improved Project Management

  • Methodologies provide a structured approach to manage software projects, ensuring tasks are completed in a logical order and within timelines.

  • They help in resource allocation, scheduling, and risk management.

• Enhance Team Collaboration

  • Define clear roles, responsibilities, and communication channels among team members.

  • Frameworks like Agile encourage regular interaction between developers, stakeholders, and clients, fostering teamwork.

• Deliver High-Quality Software

  • Methodologies emphasize quality control through rigorous testing, iterative development, and user feedback.

  • Following a systematic approach minimizes defects and improves the end product.

• Adaptability to Changing Requirements

  • Some methodologies (like Agile) are specifically designed to accommodate changes in requirements during development, making them ideal for dynamic projects.

• Efficiency and Productivity

  • Clear guidelines reduce confusion and streamline workflows, improving efficiency.

  • Reusing tested processes and best practices prevents "reinventing the wheel."

• Risk Mitigation

  • Methodologies like the Spiral Model include built-in risk analysis, helping teams identify and address potential problems early in the project lifecycle.

• Client Satisfaction

  • Iterative methodologies ensure that clients see progress regularly and can provide feedback.

  • Meeting customer requirements becomes easier and more effective.

• Career Advancement

  • Employers highly value knowledge of software development methodologies, as they demonstrate your ability to work systematically and adapt to team environments.

  • Familiarity with methodologies like Agile, Scrum, or DevOps is often a prerequisite for many software engineering roles.

• Scalability of Projects

  • Methodologies help in scaling projects, whether for a small team or a large, distributed workforce.

  • They provide a framework to manage complexity as projects grow.

• Compliance with Industry Standards

  • Many industries (e.g., healthcare, finance) require compliance with strict standards. Methodologies ensure that software meets regulatory and quality benchmarks.

• By understanding and mastering software development methodologies, you can become a more effective developer, team member, and leader, contributing to successful software projects.

What is a Requirement?

• A requirement is a documented need or condition that a software system must satisfy to fulfill its purpose. Requirements serve as the foundation for designing, developing, testing, and maintaining software.

• They describe what the system should do, how it should behave, or the constraints under which it must operate.

• A requirement can range from high-level abstract statement of a service or of a system constraint to a detailed mathematical functional specification.

Requirement Engineering

• Is a process of establishing the services that the customer requires from a system & the constraints under which it operates and is developed.

• The requirements themselves are the descriptions of the system services and constraints that are generated during the requirement engineering process.

• Requirement engineering helps s/w engineers and s/w developers to better understand the problem and the nature of the problem they are going to work on.

• It includes set of tasks that leads to understanding of -

  • a)What will be business impact of the s/w?

  • b)What the customer wants exactly?

  • c)How end users will interact with the system.

• S/w engineers and other project stakeholders, all participate in requirement engineering.

• The procedure which collects the software requirements from customer, analyze and document them is called as requirement engineering.

Need of Requirement Engineering:

• Create and maintain "System Requirement Specification Document".

• Which services are required and identifying constrain on services.

• Ensures you that software will meet user expectations.

Types of Requirements

• User: It is collection of statements in natural language plus description of the services the system provides and its operational constraints . It is written for customer.

• System requirement: It is structured documents that gives the detailed description of the system services .

• Software specification: It is detailed software description that can serve as a basis for design or implementation. It is written for s/w developer

Requirement Engineering Functions

• Requirement engineering can be carried out through some functions-

• Some of these requirements engineering functions occur in parallel.

• All these functions focus on customers needs and care must be taken to satisfy it.

• All these functions collectively form the strong base for s/w design and construction.

Activities Involved in Requirement Engineering

• Requirement Inception

• Requirement Elicitation

• Requirement Elaboration

• Requirement negotiation

• Requirement specification

• Requirements validation

• Requirement management

Activities involved in Requirement Engineering Explained

• 1. Inception:

  • Inception is beginning and it is, usually said that well beginning is half done.

  • But it is always problematic for the developer that what should be the starting point i.e. from where to start.

  • The customer and developer meet and they decide the overall scope and nature of the problem statement.

  • The aim is-

    • 1.To have the basic understanding of the problem.

    • 2. To know the people who will use the s/w.

    • 3.To know exact nature of problem that is expected from customer side.

    • 4.To maintain effectiveness of preliminary communication,

    • 5.To have collaboration between customer and developer.

• 2. Elicitation (Gathering)

  • Means to draw out the truth or reply from anybody.

  • In relation with requirements engineering elicitation is a task that helps the customer to define what is required.

  • To know the objective of the system or the project to be developed is a critical job.

  • Many times customer states unnecessary details may confuse developer instead of giving clarity of overall system objectives.

  • Researching and discovering requirement of system from customers.

  • It is non trivial(cant get all requirement from user)

  • Different ways to identify customer requirements:

    • Interviews(oral, written)

    • Surveys(large no. of person survey)

    • Questionaries‘(question with option)

    • Brainstorming(informal debate)

    • Prototyping

    • Observation(expert person visits organization or workplace of client)

  • Sometimes both customer as well as developer has poor understanding of -

    • 1.What is needed?

    • 2.Capabilities and limitations of the computing environment.

    • 3.Understanding of problem domain.

    • 4.Satisfy requirements those conflict with other customer and users. – Customer’s requirements may change time to time.

  • This is also a major problem while deciding fixed set of requirements .

• 3. Elaboration:

  • It means to work out in details.

  • Information obtained during inception and elicitation is expanded and modified during elaboration.

  • Now requirements engineering activity focuses on developing that will include-

    • 1.functions

    • 2.features

    • 3.constraints

  • Thus elaboration is an analysis modeling action. this model focuses on how the end user will interact with the system.

  • During elaboration ,each user scenario is parsed and various classes are identified.

  • These classes are nothing but the business entities that are visible to end users.

  • Then the attributes and services(functions) of these classes are defined. then the relationship among these classes is identified, Thus various UML(unified modeling Diagrams) are developed during this task.

  • Finally the analysis model gets developed during the elaboration phase.

• 4. Negotiation:

  • Negotiation means discussion on financial and other commercial issues. In this steps customer, user and other stakeholders discuss to decode.

    • 1.The rank the requirements

    • 2.To decide priorities

    • 3.To decide risks

    • 4.To finalize the project cost

    • 5.The impact of above issue on project cost and delivery date.

• 5.Specifications:

  • The specification is the final work product produced by requirement engineer.

  • The specification may take different forms-

    • 1.A written document

    • 2.A set of graphical model

    • 3.A formal mathematical model

    • 4.A collection of scenarios

    • 5.A prototype

    • 6.Any combination of above

  • A specification is considered as the foundation of all subsequent s/w engineering activities.

  • The specification describes the constraints are necessary in its development.

• 6.Validation:

  • All previous work completed will be just useless and meaning less if it is not validated against the customers expectations.

  • The requirement validation checklist includes-

    • 1.All requirements are stated clearly?

    • 2.Are the requirements misinterpreted?

    • 3.Does the requirements violate any system domain constraints?

    • 4.Is the system requirements traceable to the system to the system model that is created?

    • 5.Are the requirements associated with performance , behavior and operation characteristics.

  • The most commonly used requirement validation mechanism is formal technical review(FTR), the review team validates the s/w requirements.

• 7.Requirement management:

  • Definition: Requirement management is the process of managing changing requirements during the requirements engineering process and system development.

  • Requirement management is s/w engineering task that helps the project team members to identify the requirements, control the requirements, track the requirement and changes to requirement at any time as the project exceeds.

  • The requirement management task starts with identification and each of the requirement is assigned a unique identifier.

  • After a requirements finalization the traceability table is developed.

  • Traceability table relates the requirements to one or more aspects of the system or it is environment.

  • The traceability tables are used as requirement database and are useful in understanding how change in one particular requirement will affect other parts or aspects of the system.

  • Following are some examples of traceability table-

    • Features traceability table

    • Source traceability table

    • Dependency traceability table

Prioritizing Requirements

• Why Prioritize Requirements?

  • Limited resources (Schedule, Budget, Effort, Resources)

  • Customer expectations are high

  • Too many Reqs

  • Changing Reqs

  • Conflicting Reqs

  • All requirements are mandatory, but some are essential/critical while others are not.

What is Prioritizing Requirements?

• Definition: Prioritizing requirements is a crucial step in the process of software development or project management.

• It involves determining the relative importance or urgency of different features or functionalities that need to be implemented.

Steps to Prioritize Requirements:

• Understand Stakeholder Needs: Identify and involve key stakeholders to understand their needs, expectations, and goals for the project. This will help ensure that the prioritization process aligns with the overall objectives.

• Gather Requirements: Collect all the requirements for the project from stakeholders, user feedback, market research, etc. Ensure that you have a comprehensive list covering all aspects of the project.

• Categorize Requirements: Group similar requirements together based on functionality, user type, business impact, etc. This will help in analyzing and prioritizing them more effectively.

• Apply Prioritization Techniques: There are several techniques you can use to prioritize requirements, such as:

  • MOSCOW Method: Classify requirements as Must-have, Should-have, Could-have, and Won't-have. This helps in identifying the most critical features.

  • Kano Model: Categorize requirements into basic, performance, and delighter features to understand their impact on customer satisfaction.

  • Weighted Scoring: Assign weights to each requirement based on factors like business value, complexity, technical feasibility, etc., and then calculate an overall score for prioritization.

  • Value vs. Effort: Assess the value that each requirement delivers against the effort required for implementation.

• Consider Constraints: Take into account any constraints such as time, budget, resources, and technical limitations that may impact the prioritization decisions.

• Review and Validate: Review the prioritized requirements with stakeholders to ensure alignment with their expectations and validate that the prioritization reflects the project's goals.

• Iterate: Prioritization is not a one-time activity. As the project progresses, revisit and adjust the priorities based on changing circumstances, feedback, and new information.

• Document and Communicate: Document the prioritized requirements along with the rationale behind the prioritization decisions. Communicate the priorities clearly to all stakeholders to ensure everyone is on the same page.

Prioritization Details

• Prioritize means listing or rating in order of priority

• Requirements prioritization means balancing the business benefit of each requirement against its cost and any implications it has for the architectural foundation and future evolution of the product

• Requirements prioritization takes place at the requirements analysis and negotiation stage

Challenges of Prioritization

• Different stakeholders have usually different opinions about requirement’s importance and urgency.

  • People naturally have their own interest and they aren’t always willing to compromise their needs for someone else’s benefit.

• Customers may try to avoid prioritization, because they suspect that low priority requirements will never be implemented

• Developers may try to avoid prioritization, because they feel bad to admit, that they can’t implement all requirements

• Many of the prioritization methods are either too complicated and time consuming or insufficient

Prioritization Techniques

• Prioritization scales: Assign each requirement to a priority classification category (high, medium, low)

• Prioritization model - cost-value approach

• Analytic Hierarchy Process (AHP)

• value, cost, and risk estimation model

• Kano method

• Other approaches:

  • Quality function deployment (QFD)

  • Total quality management (TQM)

Prioritizing Requirements (MOSCOW)

• Must haves: top priority.

• Should haves: highly desirable.

• Could haves: if time allows.

• Wont haves: not today

KANO Model Details

• The Kano model is a theory of product development and customer satisfaction developed by Professor Noriaki Kano in the 1980s.

• It categorizes customer preferences into five distinct categories based on how they perceive different product attributes or features:

  • Must-be Quality: These are basic features that customers expect as a minimum requirement. Their absence would result in dissatisfaction, but their presence doesn't necessarily lead to increased satisfaction. Must-be quality features are often taken for granted and are essential for the product to be considered acceptable.

  • One-dimensional (Performance) Quality: These features directly correlate with customer satisfaction. As the level of these features increases, so does customer satisfaction, and conversely, decreasing the level leads to dissatisfaction. Customers are consciously aware of these attributes and often use them to compare products.

  • Attractive Quality: Also known as delighters or excitement factors, these are unexpected features that go beyond customer expectations. While the absence of attractive quality features does not result in dissatisfaction, their presence can lead to increased customer satisfaction and delight. They can differentiate a product from competitors and create a positive emotional response.

  • Indifferent Quality: These features do not significantly impact customer satisfaction. Customers neither expect nor care about them, so their presence or absence has little effect on their overall perception of the product.

  • Reverse Quality: Sometimes called "dissatisfiers," these are features that, if present, can lead to customer dissatisfaction. However, their absence does not necessarily result in increased satisfaction. Reverse quality features are typically undesirable and can harm the customer experience.

• The Kano model helps product developers and managers understand the relationship between product features and customer satisfaction.

• By categorizing features into these different types, teams can prioritize efforts on must-be and performance features while also identifying opportunities to incorporate attractive quality elements to differentiate their product in the market.

• In practical terms, the Kano model can be applied through techniques such as surveys, interviews, and customer feedback analysis to understand customer preferences and prioritize product development efforts accordingly.

• The Kano Model is an analysis tool to explore and measure customer needs.

• It's a way to identify the basic needs of customers, as well as performance and excitement requirements.

KANO Model Key Points

• Attractive: more satisfied if +, not less satisfied if -

• Must-be: dissatisfied when -, at most neutral

• Indifferent: don't care

• Reverse: opposite of what analyst thought

• Questionable: preferences not clear

KANO Model Categories

• Performance: Desired quality, Satisfiers, Normal quality.

  • Ex: Gas milage, Internet speed, battery life, storage space, etc.

  • The more you have of each of those, the greater your satisfaction.

  • Every increase in functionality leads to increased satisfaction.

• Must be: Dissatisfiers, taken for granted.

  • If the product doesn't have them, it will be considered to be incomplete.

  • We need to have them, but that won't make our customers more satisfied.

• Attractive: Delighters, WOWs

  • Unexpected features which, when presented, cause a positive reaction.

• Indifferent

  • Doesn't make any real difference in our reaction to the product.

  • Avoid working on these, they're essentially money sinks.

Requirements Analysis

• Specifies software’s operational characteristics

• Indicates software’s interface with other system elements

• Establishes constraints that software must meet.

• Requirement analysis allows the software engineer to:

  • Elaborate on basic requirements established during earlier requirement engineering tasks

  • Build models that depicts user scenarios, functional activities, problem classes and there relationships, system and class behavior, and the flow of data as it is transformed.

Requirements Analysis and Modeling

• Requirements analysis and modelling is probably the most important skill for a business analyst. The success of any software project depends on the this task.

• Requirements analysis and modelling involves multiple tasks: Understanding business requirements. Decomposition and analysis of requirements.

Analysis Model Objectives

• The analysis model must achieve three primary objectives:

  • To describe what the customer requires.

  • To establish a basis for the creation of a software design, and.

  • To define a set of requirements that can be validated once the software is built.

Rule of Thumb for Analysis Model

• The model should focus on requirements that are visible within the problem or business domain. The level of abstraction should be relatively high.

• Each element of the analysis model should add to an overall understanding of software req and provide insight into the information domain, function and behavior of the system.

• Delay consideration of infrastructure and other non-functional models until design.

• Minimize coupling throughout the system.

• Be certain that the analysis model provides value to all stakeholders.

• Keep the model as simple as it can be.

What is Requirements Modeling?

• Requirements modeling uses a combination of text and diagrammatic forms to depict requirements in a way that is relatively easy to understand

• Why is it important?

  • To validate software requirements, you need to examine them from a number of different points of view.

  • Here we’ll consider requirements modeling from three different perspectives: scenario- based models, data(information) models, and class-based models.

  • Each represents requirements in a different “dimension,” thereby increasing the probability that errors will be found, that inconsistency will surface, and that omissions will be uncovered.

Elements of Requirement Analysis

• Scenario-based models

  • use cases

  • user stories

• Behavioral models

  • e.g. state diagrams

  • sequence diagram

• Class models

  • e.g. class diagrams

  • collaboration diagrams

• Flow Models

  • e.g. DFDs

  • data models

Scenario-Based Modeling

• Use cases are simply an aid to defining what exists outside the system (actors) and what should be performed by the system (use-cases).

• What should we write about?

• How much should we write about it?

• How detailed should we make our description?

• How should we organize the description?

• Inception and elicitation-provide you with the information you'll need to begin writing use cases.

• Requirements gathering meetings, QFD, and other requirements engineering mechanisms are used to identify stakeholders

  • define the scope of the problem

  • specify overall operational goals

  • establish priorities

  • outline all known functional requirements, and

  • describe the things (objects) that will be manipulated by the system.

• To begin developing a set of use cases, list the functions or activities performed by a specific actor.

• As further conversations with the stakeholders progress, the requirements gathering team develops use cases for each of the functions noted.

• In general, use cases are written first in an informal narrative fashion.

• If more formality is required, the same use case is rewritten using a structured format similar to the one proposed.

Use Cases Details

• A scenario that describes a "thread of usage" for a system

• Actors represents roles people or devices play as the system functions

• Users can play a number of different roles for a given scenario

• Developing a use case:

  • What are the main tasks or functions that are performed by the actor?

  • What system information will the actor acquire, produce or change?

  • Will the actor have to inform the system about changes in the external environment?

  • What information does the actor desire from the system?

  • Does the actor wish to be informed about unexpected changes?

• A Use Case Diagram in Unified Modeling Language (UML) is a visual representation that illustrates the interactions between users (actors) and a system.

• It captures the functional requirements of a system, showing how different users engage with various use cases, or specific functionalities, within the system.

• Use case diagrams provide a high-level overview of a system's behavior, making them useful for stakeholders, developers, and analysts to understand how a system is intended to operate from the user's perspective, and how different processes relate to one another.

• They are crucial for defining system scope and requirements.

Use Case Diagram Notations

• Actors:

  • Actors are external entities that interact with the system.

  • These can include users, other systems, or hardware devices.

  • In the context of a Use Case Diagram, actors initiate use cases and receive the outcomes.

  • Proper identification and understanding of actors are crucial for accurately modeling system behavior.

• Use Cases

  • Use cases are like scenes in the play.

  • They represent specific things your system can do.

  • In the online shopping system, examples of use cases could be "Place Order," "Track Delivery," or "Update Product Information".

  • Use cases are represented by ovals.

• System Boundary

  • The system boundary is a visual representation of the scope or limits of the system you are modeling.

  • It defines what is inside the system and what is outside. The boundary helps to establish a clear distinction between the elements that are part of the system and those that are external to it.

  • The system boundary is typically represented by a rectangular box that surrounds all the use cases of the system.

Use Case Diagram Relationships

• 1. Association Relationship

  • The Association Relationship represents a communication or interaction between an actor and a use case.

  • It is depicted by a line connecting the actor to the use case. This relationship signifies that the actor is involved in the functionality described by the use case.

  • Example: Online Banking System

    • Actor: Customer

    • Use Case: Transfer Funds

    • Association: A line connecting the "Customer" actor to the "Transfer Funds" use case, indicating the customer's involvement in the funds transfer process.

• 2. Include Relationship

  • The Include Relationship indicates that a use case includes the functionality of another use case. It is denoted by a dashed arrow pointing from the including use case to the included use case. This relationship promotes modular and reusable design.

  • Example: Social Media Posting

    • Use Cases: Compose Post, Add Image

    • Include Relationship: The "Compose Post" use case includes the functionality of "Add Image." Therefore, composing a post includes the action of adding an image.

• 3. Extend Relationship

  • The Extend Relationship illustrates that a use case can be extended by another use case under specific conditions. It is represented by a dashed arrow with the keyword "extend." This relationship is useful for handling optional or exceptional behavior.

  • Example: Flight Booking System

    • Use Cases: Book Flight, Select Seat

    • Extend Relationship: The "Select Seat" use case may extend the "Book Flight" use case when the user wants to choose a specific seat, but it is an optional step..

• 4. Generalization Relationship

  • The Generalization Relationship establishes an "is-a" connection between two use cases, indicating that one use case is a specialized version of another. It is represented by an arrow pointing from the specialized use case to the general use case.

  • Example: Vehicle Rental System

    • Use Cases: Rent Car, Rent Bike

    • Generalization Relationship: Both "Rent Car" and "Rent Bike" are specialized versions of the general use case "Rent Vehicle."

How to Draw a Use Case Diagram in UML?

• Step 1: Identify Actors: Determine who or what interacts with the system. These are your actors. They can be users, other systems, or external entities.

• Step 2: Identify Use Cases: Identify the main functionalities or actions the system must perform. These are your use cases. Each use case should represent a specific piece of functionality.

• Step 3: Connect Actors and Use Cases: Draw lines (associations) between actors and the use cases they are involved in. This represents the interactions between actors and the system.

• Step 4: Add System Boundary: Draw a box around the actors and use cases to represent the system boundary. This defines the scope of your system.

• Step 5: Define Relationships: If certain use cases are related or if one use case is an extension of another, you can indicate these relationships with appropriate notations.

• Step 6: Review and Refine: Step back and review your diagram. Ensure that it accurately represents the interactions and relationships in your system. Refine as needed.

• Step 7: Validate: Share your use case diagram with stakeholders and gather feedback. Ensure that it aligns with their understanding of the system's functionality.

Use Case Diagram Example(Online Shopping System)

• Actors: Customer, Admin

• Use Cases: Browse Products, Add to Cart, Checkout, Manage Inventory (Admin)

• Relations:

  • The Customer can browse products, add to the cart, and complete the checkout.

  • The Admin can manage the inventory.

Class Diagram Details

• A UML class diagram is a visual tool that represents the structure of a system by showing its classes, attributes, methods, and the relationships between them.

• It helps everyone involved in a project—like developers and designers—understand how the system is organized and how its components interact.

• Class diagrams are a type of UML (Unified Modeling Language) diagram used in software engineering to visually represent the structure and relationships of classes within a system i.e. used to construct and visualize object-oriented systems.

• In these diagrams, classes are depicted as boxes, each containing three compartments for the class name, attributes, and methods. Lines connecting classes illustrate associations, showing relationships such as one-to-one or one-to-many.

• Class diagrams provide a high-level overview of a system’s design, helping to communicate and document the structure of the software.

• They are a fundamental tool in object-oriented design and play a crucial role in the software development lifecycle.

What is a Class?

• In object-oriented programming (OOP), a class is a blueprint or template for creating objects.

• Objects are instances of classes, and each class defines a set of attributes (data members) and methods (functions or procedures) that the objects created from that class will possess.

• The attributes represent the characteristics or properties of the object, while the methods define the behaviors or actions that the object can perform.

UML Class Notation

• class notation is a graphical representation used to depict classes and their relationships in object-oriented modeling.

• Class Name:

  • The name of the class is typically written in the top compartment of the class box and is centered and bold.

• Attributes:

  • Attributes, also known as properties or fields, represent the data members of the class. They are listed in the second compartment of the class box and often include the visibility (e.g., public, private) and the data type of each attribute.

• Methods:

  • Methods, also known as functions or operations, represent the behavior or functionality of the class.

  • They are listed in the third compartment of the class box and include the visibility (e.g., public, private), return type, and parameters of each method.

• Visibility Notation:

  • Visibility notations indicate the access level of attributes and methods. Common visibility notations include:

    • + for public (visible to all classes)

    • - for private (visible only within the class)

    • # for protected (visible to subclasses)

    • ~ for package or default visibility (visible to classes in the same package)

Relationships Between Classes

• 1. Association

  • An association represents a bi-directional relationship between two classes. It indicates that instances of one class are connected to instances of another class. Associations are typically depicted as a solid line connecting the classes, with optional arrows indicating the direction of the relationship.

  • Let’s consider a simple system for managing a library. In this system, we have two main entities: Book and Library. Each Library contains multiple Books, and each Book belongs to a specific Library. This relationship between Library and Book represents an association.

  • The “Library” class can be considered the source class because it contains a reference to multiple instances of the “Book” class. The “Book” class

is the target class because it is being referenced by the “Library” class.

• 2. Aggregation- Aggregation is a specialized form of association that represents a "has-a" relationship between two classes. It indicates that one class is part of another class, but the part can exist independently of the whole. Aggregation is depicted as a solid line with an open diamond at the end connected to the class representing the whole.

  • Example: University and Department- In a university system, there is an aggregation relationship between the "University" class and the "Department" class. The university is the whole, and the departments are its parts. Each department is part of the university, but it can exist independently of the university.

• 3. Composition- Composition is a strong form of aggregation that represents a "part-of" relationship between two classes. It indicates that one class is an exclusive part of another class, and the part cannot exist independently of the whole. Composition is depicted as a solid line with a filled diamond at the end connected to the class representing the whole.

  • Example: Car and Engine- In a car manufacturing system, there is a composition relationship between the "Car" class and the "Engine" class. The car is the whole, and the engine is its exclusive part. The engine cannot exist independently of the car; it is an integral component of the car. If the car is destroyed, the engine is also destroyed.

• 4. Inheritance (Generalization)- Inheritance, also known as generalization, represents an "is-a" relationship between two classes. It indicates that one class (the subclass or derived class) inherits the attributes and methods of another class (the superclass or base class). Inheritance is depicted as a solid line with an open triangle at the end connected to the superclass.

  • Example: Vehicle and Car- In a transportation system, there is an inheritance relationship between the "Vehicle" class and the "Car" class. The "Car" class inherits the attributes and methods of the "Vehicle" class. A car is a type of vehicle, but it can also have additional attributes and methods specific to cars, such as the number of doors or the model name.

• 5. Dependency- Dependency represents a weaker form of relationship between two classes, indicating that one class depends on another class for its implementation or behavior. It is depicted as a dashed line with an open arrow pointing to the class being depended upon.

  • Example: Order and PaymentProcessor- In an e-commerce system, the "Order" class may depend on the "PaymentProcessor" class to handle payment processing. The "Order" class depends on the "PaymentProcessor" class. Changes to the "PaymentProcessor" class may affect the "Order" class, but the "Order" class does not contain or inherit anything from the “PaymentProcessor” class.

• 6. Realization (Implementation)- Realization (Implementation) represents a relationship between a class and an interface, indicating that the class implements the methods defined by the interface. It is depicted as a dashed line with an open triangle at the end connected to the interface.

  • Example: Payment Interface and CreditCardPayment Class- In a payment processing system, there might be an interface called Payment that defines the basic methods for making payments. A class called CreditCardPayment can then implement this interface, providing specific implementations for these methods. This relationship ensures that the CreditCardPayment class adheres to the contract specified by the Payment interface.

How To Draw a Class Diagram

• Step 1: Identify Classes: Determine the classes that are relevant to the system you are modeling. Classes represent the main entities or concepts in your system.

• Step 2: Identify Attributes: For each class, identify the attributes (data members) that describe the characteristics or properties of the class. Attributes represent the data elements associated with the class.

• Step 3: Identify Methods: For each class, identify the methods (member functions) that define the behavior or actions of the class. Methods represent the functions or operations that the class can perform.

• Step 4: Define Relationships: Determine the associations and relationships between the classes. Use appropriate notations to represent these relationships, such as association, aggregation, composition, inheritance, dependency, or realization.

• Step 5: Add Visibility Modifiers: Indicate the visibility of attributes and methods using visibility modifiers such as public (+), private (-), or protected (#). Visibility modifiers control the access level of class members.

• Step 6: Review and Refine: Step back and review your diagram. Ensure that it accurately represents the structure and relationships in your system. Refine as needed.

• Step 7: Validate: Share your class diagram with stakeholders and gather feedback. Ensure that it aligns with their understanding of the system's structure and behavior.

Example Class Diagram (Library Management System)

• Classes: Book, Library, Member

• Attributes:- Book: title, author, ISBN

  • Library: name, address, books

  • Member: name, memberID, borrowedBooks

• Relations:- A Library has many Books (aggregation).

  • A Member can borrow many Books (association).

Data Modeling

• To represent the information domain for a problem

• To represent the data objects and relationships

• Data modeling is a method used to define and analyze data requirements needed to support the business processes of an organization

• The data are recorded in a data model that can be used to develop information systems. There are three main types of data models: conceptual, logical, and physical

Data Modeling Details

• Data modeling is the process of creating a visual representation of the data needed for an information system or application. It helps in understanding the relationships between different data elements and how they should be organized in a database

Importance of Data Modeling

• Provides a clear and concise representation of data requirements.

• Facilitates communication between stakeholders, developers, and database administrators.

• Helps in identifying data redundancies and inconsistencies.

• Enables efficient database design and implementation.

• Supports data integration and data warehousing efforts.

Steps in Data Modeling

• 1. Identify Entities:- Each entity should represent a distinct object or concept about which data needs to be stored.

  • Definition: Entities are objects or concepts about which you want to store information. They can be physical objects, events, roles, or abstract concepts.

  • Example: In a library system, entities could be Book, Author, Member, and Loan.

• 2. Define Attributes:- Each attribute should be specific and relevant to the entity it describes.

  • Definition: Attributes are characteristics or properties that describe an entity. They provide details and context about the entity.

  • Example: For the entity Book, attributes could include Title, Author, ISBN, Publication Year, and Genre.

• 3. Establish Relationships:- Relationships should reflect the real-world interactions between entities.

  • Definition: Relationships define how entities are related to each other. They specify how data in one entity is connected to data in another entity.

  • Types of Relationships:- One-to-One (1:1): Each instance of one entity is related to one instance of another entity.

  • One-to-Many (1:N): One instance of an entity is related to multiple instances of another entity.

  • Many-to-One (N:1): Multiple instances of an entity are related to one instance of another entity.

  • Many-to-Many (N:M): Multiple instances of one entity are related to multiple instances of another entity.

  • Example Relationships:- Book and Author: One-to-Many (1:N) - One author can write multiple books, but each book is written by one author.

  • Member and Loan: One-to-Many (1:N) - One member can have multiple loans, but each loan is associated with one member.

• 4. Define Primary keys:- The primary key should uniquely identify each instance of the entity.

  • Definition: A primary key is an attribute or a set of attributes that uniquely identifies each instance of an entity.

  • Example: For the entity Book, the ISBN is the primary key because it uniquely identifies each book.

• 5. Define Foreign Keys:- They help in establishing relationships between tables by referencing unique records of another table.

  • Definition: A foreign key is an attribute in one entity that refers to the primary key of another entity. It establishes a link between the two entities.

  • Example: In the Loan entity, the MemberID is a foreign key that refers to the Member entity, establishing the relationship between loans and members.

• 6. Normalize the Data:- Data should be structured in a way that minimizes redundancy and dependency, typically dividing databases into two or more tables and defining relationships between the tables.

  • Definition: Normalization is the process of organizing data to reduce redundancy and improve data integrity. It involves dividing databases into tables and defining relationships between the tables.

  • Normal Forms:- First Normal Form (1NF)

  • Second Normal Form (2NF)

  • Third Normal Form (3NF)

Data Flow Diagram(DFD)

• A data flow diagram (DFD) maps out the flow of information for any process or system. It uses defined symbols like rectangles, circles and arrows, plus short text labels, to show data inputs, outputs, storage points and the routes between each destination.”

• Data flow diagrams can range from simple, even hand-drawn, overviews, to in-depth, multi-level diagrams that dig progressively deeper into how the data is handled.

• They can be used to analyze an existing system or model a new one.

Data Flow Diagram Details

• A data flow diagram (DFD) is a graphical representation of the flow of data through an information system. It is a visual tool used to document and analyze the movement of data between different components or entities within a system. DFDs are commonly used in software engineering and systems analysis to model the flow of information and processes within an organization.

DFD Components

• 1. Entities (External Agents):- Entities are sources or destinations of data outside the system. They represent external entities that interact with the system by providing input or receiving output.

  • Notation: Represented by rectangles.

  • Example: Customer, Supplier, Bank.

• 2. Processes:- Processes represent activities or functions that transform data within the system. They perform operations on the data, such as calculations, data manipulation, or decision-making.

  • Notation: Represented by circles or rounded rectangles.

  • Example: Order Processing, Payment Processing, Inventory Management.

• 3. Data Stores:- Data stores represent repositories of data within the system. They are locations where data is stored and retrieved.

  • Notation: Represented by open-ended rectangles or parallel lines.

  • Example: Customer Database, Product Catalog, Order File.

• 4. Data Flows:- Data flows represent the movement of data between entities, processes, and data stores. They indicate the direction and type of data being transferred.

  • Notation: Represented by arrows.

  • Example: Customer Order, Payment Details, Product Information.

Levels of DFD

• Level 0 DFD (Context Diagram):- Shows the entire system as a single process and its interactions with external entities.

• Level 1 DFD:- Decomposes the Level 0 process into its main sub-processes and shows the data flow between them.

• Level 2 DFD:- Further decomposes one or more processes from Level 1 into more detailed sub-processes, providing a more granular view of the system.

• Higher Level DFDs:- Can be created to provide even more detailed views of specific processes, depending on the complexity of the system.

Benefits of Using DFDs

• Visual Representation:- DFDs provide a visual representation of the flow of data through a system, making it easier to understand and communicate complex processes.

• System Understanding:- DFDs help in understanding the different components of a system and how they interact with each other.

• Requirements Analysis:- DFDs aid in identifying and documenting system requirements by illustrating the flow of data and the processes involved.

• Communication:- DFDs facilitate communication between stakeholders, developers, and analysts by providing a common understanding of the system.

• Documentation:- DFDs serve as valuable documentation for the system, providing a reference for future development and maintenance efforts.

Steps to Create a DFD

• 1. Identify Entities: Start by identifying the external entities that interact with the system. These entities are the sources and destinations of data.

• 2. Identify Processes: Determine the main processes or activities that transform data within the system. Each process should represent a distinct function or operation.

• 3. Identify Data Stores: Identify the data stores or repositories where data is stored and retrieved within the system. Data stores can be databases, files, or any other storage medium.

• 4. Identify Data Flows: Determine the data flows between entities, processes, and data stores. Data flows should represent the movement of data and the type of data being transferred.

• 5. Draw the Context Diagram (Level 0 DFD): Create a context diagram that shows the entire system as a single process and its interactions with external entities. This provides a high-level overview of the system.

• 6. Decompose Processes (Level 1 DFD and Higher): Decompose the main processes into sub-processes to create more detailed DFDs. Continue decomposing processes until you reach a level of detail that is sufficient for analysis and understanding.

• 7. Review and Refine: Review the DFD to ensure that it accurately represents the flow of data through the system. Refine the diagram as needed to improve clarity and accuracy.

• 8. Validate: Share the DFD with stakeholders and gather feedback. Ensure that it aligns with their understanding of the system's functionality and requirements.

Real-Life Application of Data Flow Diagram

• Order Processing System:- In an order processing system, a DFD can be used to model the flow of data from customers placing orders to the system processing those orders and generating invoices.

• Hospital Management System:- In a hospital management system, a DFD can be used to model the flow of patient information from admission to discharge, including processes such as registration, diagnosis, treatment, and billing.

• Library Management System:- In a library management system, a DFD can be used to model the flow of data related to book borrowing, returning, and catalog management.

Behavioral Modeling using State Diagrams

• State diagrams are a visual way to represent the behavior of a system, particularly how it changes its state in response to different events.

• They're widely used in software engineering to model complex systems, embedded systems, and any scenario where the behavior of an object or system depends on its current state.

Key Components of State Diagrams

• States: A state represents a condition in which an object exists and waits for an event to occur. A state is shown as a rounded rectangle with the name of the state inside.

• Transitions: A transition is a change from one state to another. It is triggered by an event and is shown as a directed arrow from the origin state to the target state. The event that triggers the transition is written above the arrow.

• Events: An event is an occurrence that can trigger a state transition. It is a stimulus that causes the system to move from one state to another. Events can be signals, conditions, or the passage of time.

• Initial State: The initial state represents the starting point of the state diagram. It is shown as a small filled circle with an arrow pointing to the first state.

• Final State: The final state represents the end point of the state diagram. It is shown as a circle enclosing a smaller filled circle.

• Guard Conditions: A guard condition is a Boolean expression that must be true for a transition to occur. It is written in square brackets above the transition arrow. If the guard condition is false, the transition will not occur, even if the event is triggered.

• Actions: An action is an activity or operation that is executed when a transition occurs. Actions are typically written in the format “action/” above the transition arrow. Actions can include updating variables, sending signals, or performing calculations.

Steps to Create a State Diagram

• 1. Identify the Object/System: Begin by identifying the object or system whose behavior you want to model. This could be a class, a component, or an entire system.

• 2. Determine the States: Determine the different states that the object or system can be in. Each state should represent a distinct condition or mode of operation.

• 3. Identify the Events: Identify the events that can cause the object or system to transition from one state to another. Events should be specific and well-defined.

• 4. Define the Transitions: Define the transitions between states based on the events that occur. Each transition should specify the source state, the event that triggers the transition, and the target state.

• 5. Add Guard Conditions (Optional): Add guard conditions to the transitions if certain conditions must be met for the transition to occur. Guard conditions should be Boolean expressions that evaluate to true or false.

• 6. Add Actions (Optional): Add actions to the transitions if certain activities or operations need to be performed when the transition occurs. Actions should be specific and well-defined.

• 7. Draw the Diagram: Draw the state diagram using the appropriate notations for states, transitions, events, guard conditions, and actions.

• 8. Initial and Final State: Mark the appropriate states as Initial and Final states, as relevant to close the loop.

• 9. Review and Validate: Review the state diagram to ensure that it accurately represents the behavior of the object or system. Validate the diagram with stakeholders and domain experts to ensure that it meets their requirements.

Real-Life Application of State Diagrams

• Modeling the behavior of a vending machine, where the states could be “Idle,” “Selecting Product,” “Dispensing Product,” and “Collecting Money.”

• Representing the different states of a traffic light, such as “Red,” “Yellow,” and “Green,” and the transitions between them.

• Describing the lifecycle of an order in an e-commerce system, where the states could be “Created,” “Paid,” “Shipped,” and “Delivered.”

• Modeling the behavior of a washing machine, where the states could be “Idle,” “Filling,” “Washing,” “Rinsing,” “Spinning,” and “Finished.”

Sample Questions Related to Unit I

• Q1. What do understand by Requirement Engineering? Explain the Requirements Engineering Functions in detail.

• Q2. What do you mean by Prioritizing Requirements? List out the steps to Prioritize Requirements.

• Q3. What are the objectives of Analysis modelling? Explain the Rule of Thumb for Analysis Model.

• Q4. Write short note on Scenario based modelling. What you understand about Use case Diagrams? How to draw a Use case diagram through UML? Give a suitable example.

• Q5. What do you mean by class diagrams? How to draw a Class diagram? Explain with example.

• Q6. What do you understand by Data Modelling? Explain all the steps in detail.

• Q7. What are Data flow diagrams? Explain all components of DFD with example.

• Q8. What do you mean by Behavioural Modelling? How to draw a state