1) What is requirements modelling in software engineering and why is it important

Requirements modelling is basically a way of making a clear picture of what the

software should do before we start building it.
Instead of just writing everything in plain text, we use diagrams and models (like
flowcharts, use cases, data diagrams) to show:

It’s like sketching a blueprint of a house before construction — so that everyone knows
what’s going to be built.

Why is it Important?

1. Clears confusion – plain words can be vague, diagrams make requirements

easier to understand.

2. Better communication – helps customers, developers, and testers stay on the

same page.

3. Catch mistakes early – easier (and cheaper) to fix problems in the plan than in
the code.

4. Gives a guide for design – the model acts like a roadmap for programmers and
designers.

5. Breaks down complexity – makes big, complex systems easier to manage.

2. Explain the steps to create a behavioural model in requirements modelling

A behavioral model in requirements modelling shows how the system will behave in
response to events or user actions. It focuses on what the system does, not how it is
built.

Steps to Create a Behavioral Model

1. Identify the Actors and Events

o Figure out who or what interacts with the system (e.g., user, another
system, sensor).

o Identify the events that trigger actions (e.g., “user clicks login”, “payment
request received”).

2. List the System’s Responses

o For each event, write down how the system should react.

o Example:
 ▪ Event: “User enters wrong password”

▪ Response: “System shows error message”.

3. Choose the Right Modeling Technique

Behavioral models can be drawn in different ways, such as:

o Use Case Diagram → shows how users interact with the system.

o Sequence Diagram → shows the order of messages/actions.

o State Transition Diagram → shows how the system changes state when
events happen.

o Activity Diagram → shows workflows or processes.

4. Draw the Model

o Use UML or another notation to make the diagram.

o Show events, states, decisions, and flows in a clear, step-by-step way.

5. Validate with Stakeholders

o Share the model with users, customers, and developers.

o Confirm that it truly represents the expected behavior.

6. Refine and Update

o If something is unclear or requirements change, update the model.

o Keep it simple but complete.

3. Define use cases how are the uses to identify events in a system

A use case is a description of how a user (or another system) interacts with the
software to achieve a goal.

• It answers: “What does the user want to do with the system?”

• Example: In an online shopping system, common use cases are: Login, Search
Product, Add to Cart, Make Payment, Logout.

A use case is usually shown in a Use Case Diagram with:

• Actors → the users or systems interacting (e.g., Customer, Admin, Bank System).

• Use Cases → the actions/goals (e.g., Place Order, Check Balance).

How Use Cases Help Identify Events in a System

Events are the triggers that cause the system to respond. Use cases help find them
because:

1. Each use case describes a user’s action.

o Example: “Customer clicks ‘Login’” is an event.

2. Each interaction has a system response.

o Event: “Customer enters wrong password”

o System Response: “Display error message”

3. Use cases cover all possible scenarios.

o They include normal flow (successful login) and alternate/exception

flows (wrong password, network error).

4. Every step in a use case is an event.

o Example (ATM Withdraw Use Case):

▪ Insert card → Event 1

▪ Enter PIN → Event 2

▪ Select amount → Event 3

▪ System dispenses cash → Event 4

[Link] are state representations give an example

What are State Representations?

A state representation shows the different conditions (states) a system or object

can be in, and how it changes from one state to another when certain events
happen.

• A state = the situation or mode the system is currently in.

• A transition = the change from one state to another, triggered by an event.

• This is usually shown using a State Transition Diagram (STD).

Example: ATM Machine (State Representation)

States:

1. Idle → ATM is waiting for a card.

2. Card Inserted → User puts in a card.

 3. PIN Entered → User types PIN.

4. Transaction Selected → User chooses withdraw, deposit, etc.

5. Transaction Completed → Cash given / balance updated.

6. Card Ejected → Card returned to user.

Events/Transitions:

• Event: Insert card → Transition: Idle → Card Inserted

• Event: Enter PIN → Transition: Card Inserted → PIN Entered

• Event: Select transaction → Transition: PIN Entered → Transaction Selected

• Event: Complete transaction → Transition: Transaction Selected → Transaction

Completed

• Event: Eject card → Transition: Transaction Completed → Card Ejected → Idle

[Link] different patterns used for requirement modelling

Patterns in Requirement Modelling

Patterns in requirement modelling are standard ways of representing requirements

of a system.

Different Patterns in Requirement Modelling

1. Scenario-Based Patterns

o Show how users use the system.

o Example: Use Case Diagram, User Stories.

2. Data Patterns

o Show how data is stored and related.

o Example: Entity–Relationship Diagram (ERD), Class Diagram.

3. Flow-Oriented Patterns

o Show how information flows step by step.

o Example: Data Flow Diagram (DFD), Activity Diagram.

4. Behavioral Patterns

o Show how the system changes when events happen.

o Example: State Diagram, Sequence Diagram.

6. How does requirements modelling differ from web applications and mobile
applications

Requirements modelling is about capturing what the system should .But when we apply it
to web apps and mobile apps, there are some differences because their users, devices, and
environments are not the same.

How Requirements Modelling Differs for Web Apps and Mobile Apps

1. User Interaction

o Web Apps → Work on browsers, big screens.

o Mobile Apps → Work on phones, small screens.

2. Internet & Performance

o Web Apps → Need continuous internet connection.

o Mobile Apps → Often work offline (with local storage or caching).

3. Device Features

o Web Apps → Limited to browser features.

o Mobile Apps → Can use GPS, camera, sensors, fingerprint, etc.

4. Platform

o Web Apps → Run on any device with a browser.

o Mobile Apps → Must be built separately for Android, iOS, etc.

5. User Experience (UX)

o Web Apps → Focus on navigation and multi-tasking.

o Mobile Apps → Focus on simple, fast flows (minimal clicks).

[Link] between flow Oriented Modelling and behaviour modelling

Aspect Flow-Oriented Modelling Behavioural Modelling

Shows how data flows and gets Shows how the system reacts to
Meaning
processed in the system. events over time.

Data movement and

Focus System states and their changes.
transformations.
Aspect Flow-Oriented Modelling Behavioural Modelling

Common Data Flow Diagrams (DFD), Control State Diagrams, Sequence Diagrams,
Tools Flow Diagrams. Activity Diagrams.

System Functional view – what functions Dynamic view – how the system
View the system performs. behaves in different situations.

Inputs, processes, outputs, and Events, states, and control

Deals With
data storage. transitions.

Type Static representation. Dynamic representation.

Flow of “Order” data → Validation → Order state: Created → Confirmed →

Example
Database → Invoice. Shipped → Delivered.

8. With an example explain how activity diagrams are used in requirements

modelling

9. Explain how to create a behavioural model for a software system

Behavioural Modelling in Software Systems

Definition:
Behavioural modelling shows how a system responds to events over time. It focuses
on states, events, and transitions rather than just data or processes.

Steps to Create a Behavioural Model

1. Identify System Events

o List all events that can occur in the system (e.g., user actions, external
signals, or system triggers).

o Example: In an online shopping system – login, add to cart, make

payment, cancel order.

2. Identify System States

o Determine the different states the system or objects can be in.

o Example: Order can be in Created, Confirmed, Shipped, or Delivered

states.

3. Identify Transitions Between States

o Define how events cause changes from one state to another.

 o Example: Event Payment Success changes state from Created →
Confirmed.

4. Draw State Diagrams or Sequence Diagrams

o State Diagrams: Show states, events, and transitions for a system or

object.

o Sequence Diagrams: Show how objects interact over time to handle

events.

5. Include Conditions and Actions

o Specify guard conditions (when transitions happen) and actions

performed during transitions.

o Example: If stock is available → confirm order; else → notify user.

6. Validate the Model

o Check if all possible events and states are included.

o Ensure it reflects real system behaviour and meets requirements.

10. How do you identify events using use cases

What is an Event?
An event is something that happens which the system must respond to. It could be:

• A user action (click, login, submit form)

• A system action (automatic update)

• A time-based trigger (daily report)

Steps to Find Events

1. Look at the Use Case Steps

o Check each action in the use case.

o Every action that makes the system do something is an event.

o Example: Use case Place Order → actions: login, select product, make
payment.

2. Check What the Actor Does

o Anything the user or external system does can be an event.

o Example: Clicking Submit Order → event: Submit Order.

 3. Check How the System Responds

o The system’s reactions to actions are also events.

o Example: Payment successful → event: Confirm Order.

4. Don’t Forget Alternatives and Errors

o Include events for mistakes or alternative paths.

o Example: Payment fails → event: Retry Payment.

5. Categorize Events

o External events: From users or other systems.

o Internal events: System-generated.

o Time-based events: Triggered by schedule or clock.

[Link] the use of state representations in requirements modelling

State Representations in Requirements Modelling

Definition:
A state representation shows the different conditions or situations an object or
system can be in, and how it changes from one state to another due to events.

Purpose / Use in Requirements Modelling

1. Capture Dynamic Behaviour

o Shows how a system or object behaves over time.

o Helps understand how the system reacts to different events.

2. Model System States Clearly

o Each state represents a specific condition of the system or object.

o Example: An order can be Created, Confirmed, Shipped, or Delivered.

3. Show Transitions Between States

o Defines events or actions that cause a change in state.

o Example: Event Payment Success changes order from Created →

Confirmed.

4. Identify Alternative and Exceptional Flows

 o Helps capture what happens in different scenarios, like errors or
cancellations.

o Example: Event Payment Failure → transition back to Pending Payment.

5. Aid in System Design and Validation

o Provides a visual view of system behaviour for developers and

stakeholders.

o Helps validate requirements to ensure all possible states and transitions

are considered.

[Link] are some common patterns used for requirements modelling

Common Patterns in Requirements Modelling

Patterns are standard ways to represent requirements so they are clear, reusable, and
easy to understand.

1. Actor-Goal Pattern

o Shows who wants what from the system.

o Example: Customer wants to Place Order.

2. Use Case Pattern

o Represents functional requirements as use cases with main and

alternative flows.

o Example: Place Order, Make Payment, Cancel Order.

3. Event-Response Pattern

o Shows what happens in the system when an event occurs.

o Example: Event: Payment Success → Response: Confirm Order.

4. State Pattern

o Represents different states of a system or object and how they change.

o Example: Order: Created → Confirmed → Shipped → Delivered.

5. Interaction Pattern

o Models communication between actors and system components.

o Example: Sequence of messages between Customer, Payment Gateway,

and Order System.

6. Data Flow Pattern

 o Shows how data moves and is processed in the system.

o Example: Customer order → Validation → Database → Invoice.

7. Constraint/Condition Pattern

o Specifies rules or conditions the system must follow.

o Example: Payment must be completed before shipping.

[Link] the role of design within the context of software engineering

Role of Design in Software Engineering

Definition:
Design is the process of planning and defining the structure, components,
interfaces, and behavior of a software system before implementation. It acts as a
blueprint that guides development.

Key Roles of Design

1. Bridging Requirements and Implementation

o Converts software requirements into a concrete plan for coding.

o Ensures the system meets both functional and non-functional

requirements.

2. Defining System Architecture

o Establishes how modules, components, and layers interact.

o Supports decisions on scalability, performance, and maintainability.

3. Reducing Complexity

o Breaks the system into manageable components.

o Makes understanding, development, and maintenance easier.

4. Supporting Modularity and Reusability

o Encourages modular design, allowing components to be reused.

o Simplifies updates or enhancements.

5. Facilitating Communication

o Provides visual models (like UML diagrams) for developers and

stakeholders.
 o Ensures a shared understanding of the system structure and behavior.

6. Early Identification of Issues

o Detects design flaws, inconsistencies, or missing requirements before

coding begins.

o Reduces cost and effort of fixing problems later.

7. Guiding Testing and Maintenance

o A clear design helps in creating test plans.

o Makes future maintenance and modifications easier.

[Link] the software design process in detail

Definition:
The software design process is the step-by-step approach of turning requirements
into a blueprint for building a software system. It ensures the system is structured,
efficient, and meets user needs.

Steps in the Software Design Process

1. Understand Requirements

o Study functional and non-functional requirements.

o Identify constraints, performance needs, and user expectations.

2. High-Level Design (System Architecture)

o Define the overall system structure.

o Decide on modules, components, and their interactions.

o Example: Layered architecture, client-server design.

3. Detailed Design (Low-Level Design)

o Specify the internal logic of each module.

o Define data structures, algorithms, and interfaces.

o Use pseudo-code or detailed diagrams for clarity.

4. Design Modeling

o Represent the system visually using models like:

▪ Class Diagrams: Structure and relationships.

 ▪ Sequence Diagrams: Interactions over time.

▪ Activity Diagrams: Workflows and processes.

▪ State Diagrams: Object states and transitions.

5. Design Review and Validation

o Check if the design meets all requirements.

o Identify design flaws, missing elements, or inconsistencies.

o Validate performance, scalability, and security.

6. Prototyping (Optional)

o Build a small prototype of critical modules.

o Helps validate design choices and user interface.

7. Documentation

o Prepare design documents for developers and stakeholders.

o Include module descriptions, interfaces, data flow, and diagrams.

[Link] between architectural design component level design and interface

design

Component-Level
Aspect Architectural Design Interface Design
Design

Shows the overall Defines how modules

Focuses on the
system structure and communicate with each
Definition internal design of
how major components other and with
each module.
interact. users/external systems.

Organization of the Detailed design of Inputs, outputs, and

system and individual modules, communication protocols
Focus
relationships between their logic, and data between modules or with
components. handling. users.

Can be high-level (module

Level High-level (macro view). Low-level (micro view). interfaces) or low-level
(GUI or API).

Ensure smooth
Purpose Ensure the system is Ensure modules work interaction between
scalable, correctly and meet modules and with users.
 Component-Level
Aspect Architectural Design Interface Design
Design

maintainable, and functional

well-structured. requirements.

Architecture diagrams, Module specifications, Interface specs, API

Output component diagrams, pseudo-code, definitions, screen layouts,
layered structures. flowcharts. message formats.

Web app: Client-Server Backend order Payment module interface:

architecture with module: Functions like Method signatures,
Example
frontend, backend, and createOrder(), input/output formats, or
database. updateOrder(). GUI screens.