Requirement Engineering

Requirements Engineering is essential to ensure that a software development project

meets the genuine needs of its users and stakeholders. It acts as a foundation for all
subsequent stages of software development.

• Adapted to the needs of the process, project, product, and the workforce.
• Builds a bridge to design and construction.
• Mechanism for understanding customer needs, analysing, assessing feasibility,
negotiation, specification, validation, and managing requirements.
1. Inception
• Description: This is the initial phase where stakeholders establish a
clear understanding of the problem and the desired solution. It sets the
stage for subsequent activities.
• Key Activities:
• Identify stakeholders.
• Define the scope of the system.
• Understand the current problems and limitations.
• Example: A retail company wishes to replace its outdated Point Of Sale
(POS) system. During inception, stakeholders discuss the problems with
the current system, desired features for the new system, and initial
constraints.
2. Elicitation
• Description: In this phase, detailed information about the system's
requirements is gathered from various stakeholders, which might
include end-users, managers, and external interfaces.
• Key Activities:
• Conduct interviews and surveys.
• Observe users in their natural environment.
• Host workshops with different stakeholders.
• Example: The software development team arranges meetings with
cashiers, store managers, and sales analysts to understand their
expectations from the new POS system. They discover that cashiers
want a faster checkout process, managers desire inventory tracking,
and analysts need sales reporting tools.

Requirements Elicitation

3. Collaborative Requirements Gathering

• Meetings with software engineers and stakeholders.
• Defined rules and agenda.
• Use of facilitators and definition mechanisms (worksheets, electronic
boards, etc.).
4. Quality Function Deployment (QFD)
• Translates customer needs to technical requirements.
• Identifies three types of requirements: Normal, Expected, Exciting.
5. Usage Scenarios
• Describes how system functions and features will be used by users.
• Often referred to as use cases.
6. Elicitation Work Products
• Output includes statements of need, scope, descriptions of the
technical environment, lists of stakeholders, requirements, usage
scenarios, and prototypes.
•
3. Elaboration
• Description: It's about taking the raw information gathered and
refining it into a more detailed and structured format, often resulting in
a clear model of the requirements.
• Key Activities:
• Create detailed use cases or user stories.
• Model system behaviors, possibly using tools like Unified
Modeling Language (UML).
• Document constraints and non-functional requirements.
• Example: The team creates a UML diagram depicting how the new POS
system interacts with other systems like inventory management and
online sales. They also document requirements such as "The system
should process transactions within 5 seconds."
4. Negotiation
• Description: Not all elicited requirements can be implemented due to
time, budget, or technology constraints. In this phase, conflicts are
resolved, and priorities are set.
• Key Activities:
• Rank requirements based on their importance and feasibility.
• Discuss and reconcile conflicting requirements among
stakeholders.
• Finalize the list of requirements to be implemented.
• Example: The company desires facial recognition for customer loyalty
integration. However, due to privacy concerns and budget limits, this
feature is postponed to a later version.
5. Specification
• Description: The finalized requirements are documented in a
structured and detailed manner.
• Key Activities:
• Document requirements in a Software Requirement Specification
(SRS) document.
 • Model system architecture.
• Establish a traceability matrix to track each requirement.
• Example: An SRS is developed for the POS system, detailing each
functionality, its input/output data, and the expected behavior. It also
includes diagrams representing the system's workflow.
6. Validation
• Description: This phase ensures that the specified requirements are
clear, consistent, feasible, and meet the project's objectives.
• Key Activities:
• Conduct peer reviews of the SRS document.
• Engage stakeholders in validation meetings.
• Use prototypes or mockups to visualize the end product.
• Example: The team develops a prototype of the POS system and
presents it to the stakeholders. This interactive session helps in
identifying missing elements or misinterpreted requirements.
7. Requirements Management
• Description: Requirements might evolve as the project progresses.
This phase ensures they are tracked, managed, and updated
accordingly.
• Key Activities:
• Use Requirement Management tools to track changes.
• Maintain a version history of requirement documents.
• Communicate changes to all relevant stakeholders.
• Example: Midway through development, the retail company decides to
introduce online gift cards. This change is added to the requirements,
tracked, and stakeholders are informed.

. Requirements Engineering Overview

• Stakeholders
• Definition: Anyone with a vested interest in the system.
• For the Digital Library System: This would include Students, Professors,
Librarians, IT Support, and perhaps even Alumni.
• Multiple Viewpoints
• Due to the variety of stakeholders, different perspectives arise.
• For instance, students might prioritize easy access and user-
friendliness, while librarians might be concerned with inventory
management.
• Collaboration
• Aim: To find common ground and resolve conflicts.
 • In our example, while students might want unlimited digital rentals, the
library might set a cap. This cap could be decided upon after
discussions between students and library management.
• Asking the First Questions
• These are foundational queries to understand the project.
• For the Digital Library System, questions might include: "Who will be
the primary users?" or "What's the primary goal: academic research or
leisure reading?"

2. Requirements Elicitation

• Collaborative Requirements Gathering

• This involves meetings and brainstorming sessions.
• In our library system, librarians and students might hold joint sessions
to discuss what features the system should have.
• Quality Function Deployment (QFD)
• This is about converting customer needs into technical requirements.
• If students express a need for "easy searching", the technical
requirement might be "incorporate a search engine with filters".
• QFD idetenfies three types of requirement :

• Normal requirements : The

objectives and goals that are
stated for a product or system during meetings with
the customer
•

• • Expected requirements. These

requirements are implicit to the product
or system and may be so fundamental that
the customer does not explicitly state
them. Their absence will be a cause for
significant dissatisfaction.
• Exciting requirements. These features go beyond the
customer’s expectations and prove to be very satisfying
when present.
•
• Detailed descriptions of system interactions.
• A scenario might involve a student logging in, searching for a book,
and then digitally borrowing it.
Usage Scenarios (Use Cases):

• Definition: Scenarios or use cases are descriptions of how the system will be
used by different classes of end users. They act as a thread linking system
functions and their real-world applications.
• Purpose:
• To give developers a clear understanding of system functions from the
user's perspective.
• To create a connection between system requirements and real-world
user interactions.
• Example: In an e-commerce system, a use case might describe the process of
a user selecting items, adding them to their cart, and then proceeding to
checkout.

2. Elicitation Work Products:

• Definition: Outputs or results produced as part of the requirements elicitation

process. The specifics of these products can vary based on the system's size
and scope.

List of Work Products and their Descriptions:

1. Statement of Need and Feasibility:

• Description: This outlines the reason for building the system and its
feasibility.
• Example: For a new transportation app, the statement might be: "To
provide city residents with a convenient way to book public transport.
Feasibility has been verified through a preliminary market survey."
2. Bounded Statement of System/Product Scope:
• Description: This details the system's boundaries, indicating what it will
and won't do.
• Example: The transportation app will allow bookings for buses and
trams but will not include ride-sharing options.
3. List of Participants in Elicitation:
• Description: Names or groups who contributed to gathering
requirements.
• Example: Stakeholders like city transportation officials, bus company
representatives, and potential users.
 4. Description of System's Technical Environment:
• Description: Technical platforms or environments where the system
will operate.
• Example: The app will work on Android and iOS smartphones, and its
backend will run on AWS cloud servers.
5. List of Requirements and Domain Constraints:
• Description: Specific system needs, along with any constraints based
on the domain.
• Example: Requirement: "Real-time bus tracking." Constraint: "Use the
city's existing GPS data for tracking."
6. Set of Usage Scenarios:
• Description: Insights into the system's operation under different
conditions.
• Example: Scenarios like "Booking a bus ride during peak hours" or
"Finding alternative routes when a tram line is down."
7. Prototypes Developed:
• Description: Preliminary versions of the system used to clarify
requirements.
• Example: A clickable mockup of the transportation app showing the
user interface.
Reviewing the Work Products:

• All participants in the requirements elicitation process review these work

products. This ensures accuracy, completeness, and alignment with user needs
and system goals

3. Developing Use Cases

• Actors are the entities interacting with the system.

• In the library example, the "student" might be a primary actor who wants to
borrow a book, while the "system notification" reminding them to return the
book might be a secondary actor.

4. Building the Requirements Model

• Scenario-based elements: Focus on user experience. In our system, this

might look at the step-by-step process a professor undergoes to upload
research papers.
• Class-based elements: This categorizes objects within the system. In the
library system, classes could be 'Books', 'Users', 'Transactions', etc.
 • Behavioral elements: Describes system behavior, like how the system reacts if
a student tries to borrow a book that's already checked out.
• Flow-oriented elements: This maps the flow of information. For instance,
when a book is borrowed, the system updates the inventory, informs the user,
and sets a return date.
• Analysis Patterns: If there are existing models or patterns that fit the
requirements, they can be used. For example, the user login and
authentication process might follow a widely accepted pattern.

• Geyer-Schulz and Hahsler suggest two benefits

that can be associated with the use of analysis
patterns:
• First, analysis patterns speed up the development
of abstract analysis models that capture the main
requirements
• Second, analysis patterns facilitate the
transformation of the analysis model into a design
model
5. Negotiating Requirements

• This involves reconciling stakeholder needs with practical constraints.

• Aim for a “win-win” solution for both stakeholders and the software team.
• Activities include identifying stakeholders, determining win conditions, and
reconciling to achieve win-win conditions.

• In our library example, if students want 24/7 IT support, but budget

constraints exist, a compromise might be providing extensive FAQ sections
and chatbot support.
•

6. Validating Requirements

• The aim here is to ensure that the set requirements align with stakeholder
needs and are feasible.
• For instance, if one requirement is for the digital library to support 10,000
concurrent users, stress tests must be performed to validate this.
UML Model

REQUIREMENTS ANALYSIS

The act of requirements modeling can result in the following types of models:

1. Scenario-based Models:
• Provides requirements from the perspective of different system
"actors".
• Depicts sequences of actions an actor performs in a given scenario.
2. Data Models:
• Represents the information domain.
• Shows how data is structured and related.
3. Class-oriented Models:
• Represents object-oriented classes with attributes and operations.
• Shows how classes collaborate to meet system requirements.
4. Flow-oriented Models:
• Depicts the functional components of a system.
• Shows how data is transformed as it navigates through the system.
5. Behavioral Models:
• Describes the system's behavior in response to external "events".
• Models how the system reacts and changes state.

UML (Unified Modeling Language)

Overview:

• UML is a standard language designed for visualizing, constructing,

documenting, and specifying software systems' artifacts.
• Created by the Object Management Group (OMG).
• UML 1.0 specification draft was introduced to OMG in January 1997.
• Different from common programming languages.
• A pictorial language used for creating software blueprints.
• While predominantly used for software systems, UML can also model non-
software systems.
• Can be integrated with tools to generate code in multiple languages.
• Closely related to object-oriented analysis and design.
Conceptual Model of UML:

1. UML Building Blocks:

• Definition: These are foundational elements in UML.
2. Rules for Connecting Blocks:
• Definition: Set guidelines governing interactions and connections
between blocks.
3. Common UML Mechanisms:
• Definition: These are standardized conventions used across UML for
consistency.

Building Blocks of UML:

1. Things:
• Structural Things: Define static components.
• Class: Object templates with defined attributes and
responsibilities.
• Interface: Exposes certain functionalities (operations) of a class.
• Collaboration: Represents interactions between elements.
• Use Case: A set of actions with a distinct outcome.
• Component: Physical entities in a system.
• Node: Runtime physical elements.
• Behavioral Things: Depict dynamics and interactions.
• Interaction: A sequence of messages between elements.
• State machine: Tracks object states and transitions.
• Grouping Things: Clusters UML elements.
• Package: Contains related UML entities.
• Annotational Things: Used for notes and comments.
• Note: Adds annotations to UML elements for clarity.
2. Relationships:
• Dependency: A change in one element may affect another.
• Association: Describes how many objects participate in a relationship.
• Generalization: An inheritance relationship, showcasing a parent-child
hierarchy.
• Realization: An implementing relationship, especially regarding
interfaces.
3. UML Diagrams:
• Visual manifestations of UML designs.
• Types:
• Class Diagram: Depicts classes and their relationships.
•
 • Object Diagram: Instance of a class diagram at a particular
moment.
•
• Use Case Diagram: Shows system functionality from a user's
perspective.
• Sequence Diagram: Displays object interactions in a time
sequence.
• Collaboration Diagram: Focuses on object organization.
• Activity Diagram: Highlights workflow and processes.
• Statechart Diagram: Shows object state transitions.
• Deployment Diagram: Describes system's hardware
configuration.
• Component Diagram: Showcases software components and
dependencies.

Class interface collaboration use case component node

Interaction - state Machine -
Package –

Annotational thing -

Relationship

Dependency -

Association -
Generalisation –

Realisation -

Creating a Preliminary Use Case

Scenario-based elements

1. Definition: Use cases capture the interactions between producers and

consumers of information in a software system.
• Example: A user (actor) wants to purchase a product from an online
store.
2. Characterization: Alistair Cockburn describes a use case as a "contract for
behavior."
• Example: An agreement (or contract) that outlines how a user can
search, select, and purchase a product on an e-commerce website.
3. Purpose of Use Case: It describes a specific scenario from an actor's
perspective.
• Example: "As a shopper, I want to add items to my cart so I can
purchase them."
4. Questions to Answer:
• What to write about?
• Example: Describing the process of adding items to a cart.
• How much to write about it?
• Example: Cover the entire process from item selection to adding
to cart.
• How detailed should the description be?
• Example: Specify where the "add to cart" button is located and
any confirmation messages.
• How to organize the description?
• Example: Start from item selection, then quantity choice, and
finally adding to cart.
5. Starting Point: List the functions or activities performed by an actor.
• Example: Searching for a product, selecting a product, choosing a
quantity, adding to cart.

Refining a Preliminary Use Case

 1. Evaluate Each Step:
• Can the actor take another action?
• Example: The user might want to read reviews before adding
the product to the cart.
• Possibility of encountering an error?
• Example: The selected item is out of stock.
• Any other possible behaviors?
• Example: Discounts or offers pop up for the selected item.
2. Brainstorming Session: Derive a complete set of exceptions.
• Example: What happens if there's a failed payment? Or if there's a
discount code to apply?
3. Additional Considerations:
• Validation functions:
• Example: Checking if a provided discount code is valid.
• Failure of a supporting function:
• Example: Payment gateway doesn't respond.
• System performance leading to errors:
• Example: Slow website causing multiple clicks on "Place Order"
button.

Writing a Formal Use Case

1. Goal in Context: Define the use case's scope.

• Example: Making a successful online purchase.
2. Precondition: Known conditions before initiating the use case.
• Example: User is logged in and has items in the cart.
3. Trigger: Event that starts the use case.
• Example: User clicks on "Checkout" button.
4. Scenario: Actions by the actor and system responses.
• Example: User provides shipping details, system calculates total cost
including shipping.
5. Exceptions: Situations uncovered during refinement.
• Example: Item became out of stock during checkout.
6. Limitations: Use cases focus on functional and behavioral requirements, not
non-functional.
• Example: Use cases would describe the checkout process but not
necessarily the speed at which the checkout page loads.

Conclusion

• Insight: Scenario-based modeling is fit for most software engineering

situations.
 • Example: While designing a music app, use cases can outline functions
like searching for a song, playing it, or creating a playlist.

1. UML Activity Diagrams

• Represents the flow of activities and decisions.

• Uses:
• Rounded rectangles for actions.
• Arrows for the flow.
• Diamonds for decisions.
• Horizontal lines for parallel activities.
• Example: Think of a library system where:
• User selects a book.
• If the book is available (diamond decision), the system issues the book.
• Else, it prompts the user to select another book or place a reservation.

2. UML Swimlane Diagrams

• Represents flow of activities and shows responsibility of each actor.

• Diagram is divided into segments (lanes) representing different actors or
classes.
• Example: In a job application system:
• Applicant fills out application form.
• HR reviews application.
• Manager makes a final decision. Each step occurs in its respective lane.
3. Class-Based Modeling

• Represents objects, operations, relationships, and collaborations.

• Elements:
• Classes and objects.
• Attributes.
• Operations.
• CRC models.
• Collaboration diagrams.
• Packages.

4. Identifying Analysis Classes

• Derived from usage scenarios and use cases.

• Examples of Analysis Classes:
• External entities: A payment gateway system.
• Things: Sales report.
• Occurrences or events: Alarm trigger.
• Roles: Customer.
• Organizational units: Sales department.
• Places: Warehouse.
• Structures: Mobile device.
• Selection Characteristics for Potential Classes:
1. Retained information: A user profile class retains user data.
2. Needed services: A product class may have a method to calculate its
price with tax.
3. Multiple attributes: A car class has attributes like color, model, and
speed.
4. Common attributes: Every instance of a book class has a title and
author.
5. Common operations: All instances of a bank account class can be
credited or debited.
6. Essential requirements: A payment gateway that is crucial for an
online shopping system.

5. Specifying Attributes

• Attributes detail the data related to an object.

• Example: A student class has attributes such as student_id, name, and age.

6. Operations

• Define object behavior.

 • Categories:
1. Manipulate data: Add a new item to a list.
2. Perform computation: Calculate total price.
3. Inquire state: Check if a user is active.
4. Monitor: Monitor battery level of a device.

7. Associations and Relationships

• Defines how classes relate.

• Multiplicity: A library has multiple books.
• Client-server relationship: A mobile app (client) might rely on a backend server
(server) for data.
• Stereotype: Custom relationships. For instance, <<uses>> might indicate one
class uses the functions of another.
8. Analysis Modeling and Categorization

• Grouping elements of the analysis model.

• Example: An e-commerce system might have analysis packages like 'User
Management', 'Product Management', and 'Order Processing'.

Data Flow Diagram (DFD):

• Definition: Represents flow-oriented modeling, bridging the gap between

users and developers.
• Purpose: To visualize the system's data flow.
• Components:
1. Data objects: Flow into and out of the software.
 2. Processing elements: Transform data objects.
• Representation:
• Data objects are shown by labeled arrows.
• Transformations are depicted by circles or bubbles.
• Hierarchy:
• Level 0 (Context diagram): Represents the entire system.
• Subsequent Levels: Offer refined views with increasing detail.
• Example: A book ordering system. Level 0 might just depict a user making an
order. Level 1 could elaborate on order placement, payment processing, and
shipment tracking.

2. Benefits of DFD:

• Model Creation: Helps in developing models of both information and

functional domains.
• Refinement: As DFD detail increases, there’s a corresponding refinement in
the data flow.

3. Guidelines for DFD Creation:

• Level 0: Shows the software/system as one bubble.

• Primary I/O: Should be noted.
• Refinement: Begins by identifying candidate processes, data objects, and
data stores.
• Labeling: All elements must be meaningfully named.
• Flow Continuity: Must be consistent across levels.
• Simplicity: Refine one bubble at a time to avoid over-complexity.
 5. Behavioral Model Creation:

Definition: Represents the behavior of a system, often depicted using state

diagrams.

To create the model, you should perform the following steps:

1. Evaluate all use cases to fully understand the

sequence of interaction within the system.

• . Identify events that drive the interaction sequence and

understand how these events relate to specific objects.

• . Create a sequence for each use case.

• Build a state diagram for the system.

. Review the behavioral model to verify accuracy and consistency.

• State Diagrams: Used to represent system behavior.
• Steps:
1. Determine initial and final states.
2. Identify all possible object states.
3. Label events triggering state transitions.
• Example: A coffee machine. States include "Idle", "Brewing", and
"Dispensing". Events like "Start Brew" can trigger transitions between these
states.
5. Patterns for Requirements Modeling:

• Definition: Mechanisms for capturing and reapplying domain knowledge.

• Utility: Patterns can be reused for requirements modeling in different
domains.
• Analysis Patterns: Stored in repositories, enabling easy access and
application by software teams.
• Use Cases: Fundamental in requirements modeling and can be the basis for
discovering analysis patterns.
• Semantic Analysis Pattern (SAP): Describes coherent use cases defining a
basic generic application.
• Example: A "User Authentication" pattern that can be reused across various
applications, ensuring consistency and saving design effort.

6. Software Design:

• Position: Central to software engineering.

• Sequence: Occurs after requirements analysis but before coding and testing.
• Objective: To lay the groundwork for construction.
• Requirements Model: Influences design by offering various views of the
system.
• Design Types:
1. Data/Class Design: Turns class models into realizations.
2. Architectural Design: Dictates system structure, patterns, and
constraints.
3. Interface Design: Dictates software communication.
4. Component-Level Design: Describes software components.
 • Importance: Ensures quality, offering representations that can be quality-
assessed.
• Example: For a mobile banking app, the software design will outline how user
login works, how transactions are processed, and how data is securely stored.

7 The Design Process:

• Nature: Iterative.
• Outcome: A blueprint for software construction.
• Quality Guidelines:
• McGlaughlin’s Characteristics:
1. Fulfill all requirements.
2. Be readable and understandable.
3. Offer a holistic software view.
• Hewlett-Packard’s FURPS Attributes: Functionality, Usability,
Reliability, Performance, and Supportability.
• Evolution: From modular to structured programming and beyond.
• Commonalities across Methods: Translation mechanisms, representational
notations, refinement heuristics, and quality guidelines.

8. Design Concepts:

• Origin: Evolved over the course of software engineering history.

• Purpose: To guide more sophisticated design methods.
• Key Questions:
1. How to partition software?
2. How to separate detail from concept?
3. How to ensure technical quality?
• Example: When designing a cloud storage service, the system might be
partitioned into user management, data storage, security, and UI design,
following key design concepts.
3.3.1 Abstraction

• Definition: Simplifying complex reality while retaining its essential features.

• Procedural Abstraction: Representing a task or function without focusing on
internal details.
• Data Abstraction: Representing essential data without including its internal
workings.
• Example:
• Procedural Abstraction: Using the "print" function in programming
without knowing how it internally processes the command.
• Data Abstraction: Using an "integer" data type without knowing how
it's represented in memory.

3.3.2 Architecture

• Definition: The overall structure of software, including components and their

interactions.
• Structural Properties: Define software's components and how they interact.
• Extra-functional Properties: Address requirements like performance,
security, etc.
• Families of Systems: Using repeatable architectural patterns.
• Example:
• Designing a shopping website. The structural properties might
include the user interface, the database for product storage, and the
payment gateway. The extra-functional properties might cover the
website's load time, its encryption for security, etc.

3.3.3 Patterns

• Definition: Proven solutions to recurring problems.

• Design Patterns: Descriptions of communicating objects and classes
customized to solve a general design problem in a particular context.
• Example:
• Singleton Pattern: Ensures that a class has only one instance and
provides a point of access to it.

3.3.4 Separation of Concerns

• Definition: Breaking a software application into distinct sections, where each

section addresses a separate concern.
 • Example:
• In a Model-View-Controller (MVC) architecture:
• Model: Manages data, logic, and rules of the application.
• View: Displays the data, gets user input.
• Controller: Modifies the view and the model based on user
input.

3.3.5 Modularity

• Definition: Dividing software into separate modules that operate

independently.
• Example:
• A music app could have separate modules for playing tracks,
downloading songs, and searching for artists.

3.3.6 Information Hiding

• Definition: Restricting the details of a module to avoid unintended

interference and misuse.
• Example:
• In Object-Oriented Programming, using private and protected access
specifiers restricts access to certain members of a class.

3.3.7 Functional Independence

• Definition: Modules in software should have a single responsibility and

minimal dependency on other modules.
• Cohesion: Indicates how closely the functions in a single module are related.
• Coupling: Indicates the degree of dependence between different modules.
• Example:
• An authentication module in software should only handle login and
logout functions, indicating high cohesion. If this module does not rely
on the user profile module for its operations, it has low coupling.

3.3.8 Refinement

• Definition: Elaborating on a basic design to improve its detail and clarity.

• Example:
• A basic design might state that a software application needs a user
login system. Refinement could involve detailing how authentication is
done, specifying the use of two-factor authentication.
3.3.9 Aspects

• Definition: An aspect is a representation of a crosscutting concern.

Crosscutting concerns apply across many different requirements, affecting
various parts of a system.
• Example: Logging is a crosscutting concern because many parts of a
software system need logging capabilities, irrespective of their primary
functionality.

3.3.10 Refactoring

• Definition: Refactoring improves the internal structure of a software system

without altering its external behavior.
• Example: Renaming a variable to make its purpose clearer is a
refactoring step. Though the system behaves the same way, its
readability improves.

3.3.11 Object-Oriented Design Concepts

• Definition: Object-oriented design involves classes and objects, inheritance,

messages, and polymorphism.
• Example: A 'Vehicle' class can have subclasses like 'Car' and 'Bike'. Both
subclasses inherit properties from 'Vehicle' but can also have specific
functionalities.

3.3.12 Design Classes

• Definition: Design classes refine analysis classes with design details to

support the software solution.
• Example: An analysis class 'User' may only have 'username' and
'password'. In the design class, it could be refined to include methods
like 'login' and 'logout'.

1. Analysis and Design Classes

• Analysis classes provide an abstract view of the problem domain, focusing on

user-visible aspects.
• Design classes refine analysis classes, adding details necessary for
implementation.
Example:

• Analysis Class: A 'Customer' with basic details such as name and address.
• Design Class: The 'Customer' is now detailed with attributes like 'CustomerID',
methods like 'getPurchaseHistory()', and associations to other classes like
'Orders'.

2. Types of Design Classes

a. User Interface Classes

• Handle human-computer interaction (HCI).

• Might be visual representations of interface elements.

Example: A graphical button on a screen that allows users to submit a form.

b. Business Domain Classes

• Refinements of analysis classes.

• Define attributes and services necessary for a specific business element.

Example: 'BankAccount' class with attributes like 'balance' and methods like
'deposit()' and 'withdraw()'.

c. Process Classes

• Handle lower-level business functions.

• Manage business domain classes.

Example: A 'TransactionManager' class that oversees the process of transferring

money between two 'BankAccount' instances.

d. Persistent Classes

• Represent long-lasting data storage.

Example: A 'DatabaseHandler' class that communicates with a SQL database to store

and retrieve 'BankAccount' data.

e. System Classes

• Manage the software and enable communication with its environment.

Example: 'NetworkManager' class that handles all incoming and outgoing network
requests.

3. Characteristics of a Well-Formed Design Class

a. Complete and Sufficient

• Full encapsulation of necessary attributes and methods.

• Neither too much nor too little.

Example: A 'CalendarEvent' class has methods to 'addEvent()', 'deleteEvent()', but not

'changeWeather()' because that's not its responsibility.

b. Primitiveness

• Each method should have a single, clear purpose.

Example: 'addEvent()' should only add an event, not check weather or send emails.

c. High Cohesion

• A class should have a focused responsibility.

Example: A 'MailSender' class should only handle sending emails, not managing
calendar events.

d. Low Coupling

• Design classes should collaborate but remain independent.

Example: While 'CalendarEvent' might trigger an 'EmailAlert', it shouldn’t directly

handle email delivery. That would be the 'MailSender's job.

4. Dimensions of the Design Model

a. Process Dimension

• Indicates the model's evolution during the software process.

b. Abstraction Dimension

• Represents the level of detail in the transformation from analysis to design.

Example: Starting with a vague concept of 'Communication' in the analysis model
and refining it to specific classes like 'Email', 'SMS', and 'Notification' in the design
model.

5. Major Elements of Design Model

a. Data

• Information handled by the system.

Example: User profiles, transaction logs.

b. Architecture

• The high-level structure of the software.

Example: A three-tier architecture with presentation, logic, and data layers.

c. Components

• Individual, interchangeable parts of the system.

Example: A payment gateway component in an e-commerce system.

d. Interface

• Points where the system interacts with users or other systems.

Example: API endpoints, GUI components

3.4.1 Data Design Elements

• Definition: Data design translates a high-level data model into specific

representations suitable for a computer-based system.
• Example: An abstract 'Employee' data model may be transformed into
a detailed database table with fields such as 'EmployeeID', 'Name', and
'Position'.

3.4.2 Architectural Design Elements

 • Definition: Architectural design depicts the overall software layout, like a
house's floor plan.

• The architectural model is derived from three

sources: (1) information about the application
domain for the software to be built; (2)
specific requirements model elements such as
data flow diagrams or analysis classes, their
relationships and collaborations for the
problem at hand; and
• the availability of architectural styles and patterns
• Example: A software may have a three-tier architecture, consisting of
presentation, logic, and data tiers. This would be similar to having a
ground floor, first floor, and basement in a house.

3.4.3 Interface Design Elements

• Definition: Interface design focuses on how software components interact,

both internally and externally.
• There are three important elements of interface design: (1) the user
interface (UI); (2) external interfaces to other systems, devices, networks,
or other producers or consumers of information; and (3) internal
interfaces between various design components
• Example: An ATM software needs to interface with the bank's
mainframe to fetch and update account details. This interaction design
is an integral part of the software's interface design.

3.4.4 Component-Level Design Elements

• Definition: Component-level design details the internal structures and

functionalities of each software component.
• Example: For an e-commerce website, the 'ShoppingCart' component
might be designed to handle item additions, deletions, and quantity
updates.

3.4.5 Deployment-Level Design Elements

• Definition: Deployment design concerns how software and subsystems will

be physically allocated in a computing environment.
• Example: A cloud-based application might be deployed across
multiple servers in different geographical locations to ensure
redundancy and availability.
 The FURPS quality attributes represent a target for all software design:
• Functionality is assessed by evaluating the feature set and capabilities of the program, the generality of
the functions that are delivered, and the security of the overall system..
• Usability is assessed by considering human factors, overall aesthetics, consistency, and
documentation.
• Reliability is evaluated by measuring the frequency and severity of failure, the accuracy of output
results, the mean-time-to-failure (MTTF), the ability to recover from failure, and the predictability of the
program.
• Performance is measured by considering processing speed, response time, resource consumption,
throughput, and efficiency.
• Supportability combines the ability to extend the program (extensibility), adaptability,
serviceability—these three attributes represent a more common term, maintainability—and in addition,
testability, compatibility, configurability, the ease with which a system can be installed, and the ease with
which problems can be localized.
provide me the points level manner

Layered Engineering in Software Development:

1. What is it?

A method to organize code and systems into separate "layers" or tiers.

Each layer has a specific job.
2. Why use it?

Modularity: Layers can be developed separately.

Maintainability: Easier to fix or upgrade parts of the system.
Reusability: Layers or components can be reused in different contexts.
Separation: Each layer focuses on a specific function, keeping things organized.
3. Common Layers:

Presentation Layer: The user interface. What users see and interact with.
Application Layer: Coordinates the application's operations, like handling user commands.
Business Logic Layer: Contains rules of the system – how data is processed or decisions are made.
Data Access Layer: Communicates with databases. Fetches, saves, or updates data.
Data Storage Layer: The actual storage like databases or file systems.
4. Example: Book Management Web App

Presentation Layer: Webpage showing a list of books.

Application Layer: Processes when you click on a book title.
Business Logic Layer: Ensures you can rate a book only once.
Data Access Layer: Fetches the clicked book's details from a database.
Data Storage Layer: The actual database storing book details.