Purpose in Software

Diagram Requirements Characteristics and Common

Type Engineering Differences Use Cases Symbols

- Shows interactions
between external entities - Elicit and define functional
(actors) and the system. - requirements. - Clarify system
Represents different use boundaries. - Aid in
cases and their communication between
Describes system relationships. - Emphasizes stakeholders. - Identify actors Actors, Use
Use Case functionality from a what the system will do and their relationships with Cases,
Diagram user's perspective from the user's viewpoint. the system. Relationships

- Detail the workflow and

behavior of a use case or
- Represents the flow of system. - Clarify complex
activities and actions within processes and their
a system or use case. - interdependencies. - Identify Activities,
Emphasizes the sequence bottlenecks, decision points, Actions,
Illustrates workflow and conditions of actions. - and parallel activities. - Aid in Decisions,
Activity within a system or a Can include decisions, understanding dynamic Control Flows,
Diagram specific use case concurrency, and loops. aspects of a system. Objects

- Analyze and understand data

- Depicts the flow of data flow and transformations in a
between processes, data system. - Identify data
stores, and external entities. sources, destinations, and
- Shows how data is storage. - Specify data inputs
transformed and processed and outputs. - Facilitate Processes, Data
within the system. - communication between Stores, Data
Data Flow Models the flow of data Focuses on data movement stakeholders regarding data Flows, External
Diagram within a system and processing. aspects of the system. Entities

- Define the structure of a

system in terms of classes and
their relationships. - Aid in the
- Illustrates classes, their creation of a detailed design
attributes, and and implementation. - Identify
relationships. - Emphasizes key entities and their
the static structure of the attributes. - Support the Classes,
Represents the static system. - Includes understanding of the static Attributes,
Class structure of a system, inheritance, associations, relationships within the Relationships,
Diagram including classes and multiplicity. system. Multiplicity

- Represents the physical - Provide a high-level view of

components/modules of a the system's architecture. -
Describes the highlevel system. - Focuses on the Identify and understand the Components,
Component components/modules organization and major components/modules. - Dependencies,
Diagram of a system dependencies of Clarify dependencies between Interfaces
 Purpose in Software
Diagram Requirements Characteristics and Common
Type Engineering Differences Use Cases Symbols

components. - Can include components. - Aid in system

libraries, executables, and design and modularization.
services.

- Illustrate specific instances

and relationships between
objects. - Aid in understanding
the state of the system at a
- Represents a snapshot of particular point in time. -
the system, showing Support detailed design and
Depicts instances of objects and their implementation decisions. -
classes and their relationships. - Emphasizes Provide a concrete view of the
Object relationships at a specific instances rather system based on specific Objects, Links,
Diagram specific point in time than classes. scenarios. Relationships
Elicitation Long Questions

Requirement Best Elicitation Minimum Number

Type Techniques of Techniques Reasoning
Interviews provide in-depth insights
from key stakeholders, while
workshops facilitate collaborative
Business Interviews, 2 (Interviews, discussions to align goals and
Requirements Workshops Workshops) objectives.
Interviews allow for detailed
discussions with stakeholders, and
Functional Interviews, 2 (Interviews, workshops enable collaborative
Requirements Workshops Workshops) definition of system functionalities.
Observations provide insights into user
Observations, 3 (Observations, behavior, focus groups capture diverse
User Focus Groups, Focus Groups, perspectives, and questionnaires
Requirements Questionnaires Questionnaires) gather structured feedback.
System Interface Analysis focuses on
understanding integration needs and
System System Interface 1 (System Interface data flow between the AI Chatbot Web
Integration Analysis Analysis) App and other systems.
User Interface Analysis is crucial for
User Interface User Interface 1 (User Interface defining the design and usability
Design Analysis Analysis) aspects of the AI Chatbot Web App.
Document Analysis aids in
understanding existing data structures
Data 1 (Document and processes, aligning with business
Requirements Document Analysis Analysis) data needs.
Surveys help gather information
related to non-functional aspects,
while benchmarking provides insights
Non-functional Surveys, 2 (Surveys, into industry standards and best
Requirements Benchmarking Benchmarking) practices for performance, security, etc.
What is the difference between requirement elicitation and specification?
Requirements analysis or elicitation is the process of actually gathering the requirements
from stakeholders. Requirements modeling or specification is the process of turning those
needs/statements/conversations into something that can be turned into code.

Difference between system and user requirements with examples?

User requirements define the results and qualities the user wants; system requirements
define what the system must do to achieve this. User requirements are owned by the users,
whereas system requirements are owned by the developers.
Three types of requirements

differences between products and projects in the context of software requirements

engineering:

Aspect Product Project

Has a long-term lifecycle with Has a defined start and end date with
Duration continuous updates. specific phases.
Primarily focuses on Focuses on achieving specific objectives
Focus delivering value to end-users within constraints.
Requirements may evolve Requirements are established at the
continuously to meet beginning and may be adjusted during
Requirements changing user needs and the project life cycle through formal
Management market demands. change control processes.
differences between risk management and project planning in the context of project
management:

Aspect Risk Management Project Planning

Involves defining the project scope,
Focuses on identifying and mitigating objectives, tasks, schedules, resources, and
Nature of potential risks and uncertainties that may other essential elements to guide project
Activity impact the project's success. execution.
Aims to anticipate, assess, and address Aims to establish a structured framework
potential issues before they occur to for organizing, coordinating, and executing
Purpose minimize their impact on the project. project activities to achieve its goals.
Ongoing process throughout the project
life cycle, requiring continuous Typically conducted at the beginning of the
monitoring and adjustment as new risks project to create a roadmap and guide the
Timing emerge. project team throughout its execution.

the differences between assumed and implied requirements:

Aspect Assumed Requirements Implied Requirements

Arises from assumptions made by the Arises from the context, domain
project team or stakeholders about knowledge, or industry standards,
necessary elements for project without being explicitly specified
Origin success. by stakeholders.
May be clearer but still requires
May lack clarity and require active careful interpretation and
communication and validation to validation to ensure alignment with
Clarity avoid misunderstandings. stakeholder expectations.
Involves understanding the
Requires efforts to uncover hidden context, domain knowledge, and
expectations through collaboration industry standards to infer
Identification with stakeholders. potential needs.

Assumed requirements are those that people expect without having explicitly expressed
them. What you assume as being obvious might not be the same as assumptions that
various developers make. Implied requirements are necessary because of another
requirement but aren't explicitly stated.
Classifying the customer input is just the beginning of the process to create good
requirements. You still need to assemble the information into clearly stated and well-
organized requirements collections.

User Interface (UI) – represents how end-users interact with a solution. 2. System-to-system
Interface – represents how a core system interacts and exchanges data and information with
sub-systems.