●​ Participants write down requirements

anonymously
Requirement Analysis ●​ Requirements are shared & reviewed by others
for feedback
●​ Most challenging phase: clearly define what to ●​ Process is iterated until a consensus is reached
build ●​ Useful for gathering expert opinion and reducing
●​ Requirement Engineering = systematic use of bias
methods & tools to describe:
○​ What the system should do (behavior)
○​ Constraints under which it must operate FAST (Facilitated Application Specification
Technique)
Difficulties in Requirement Engineering ●​ Joint team of customers and developers
collaborate
●​ Hard to Uncover: Users rarely provide complete ●​ Participants list:
requirements upfront ○​ What surrounds, is produced by, and
●​ Changing Requirements: Needs evolve during used by the system
development ○​ Services, constraints, performance
●​ Tight Schedules: Limited time for thorough criteria
analysis ●​ Lists are broken into smaller parts and handled
●​ Communication Gaps: Developers vs. users = by sub-teams
different vocab & mindset ●​ Promotes shared understanding and structured
●​ Resource Limits: Can’t always build everything requirement gathering
users want
QFD (Quality Function Deployment)
Types of Requirements
●​ Focuses on the voice of the customer
●​ Known Requirements: Clearly stated by ●​ Each requirement is rated by the customer for
stakeholders importance
●​ Unknown Requirements: Forgotten or not ●​ Priority scale (1 to 5):
currently relevant ○​ 5 – Very important
●​ Undreamt Requirements: Not imagined due to ○​ 4 – Important
limited domain knowledge ○​ 3 – Nice to have
○​ 2 – Not important
Steps in Requirement Analysis ○​ 1 – Unrealistic / needs clarification
●​ Helps align development with customer
priorities
1.​ Requirement Elicitation – Gather requirements
from stakeholders
2.​ Requirement Analysis – Identify conflicts, Use Case Approach
defects, inconsistencies
3.​ Requirement Documentation – Record refined ●​ Structured, narrative descriptions of user
requirements in detail requirements
4.​ Requirement Review – Validate and improve the ●​ Describes sequence of events from the user's
quality of the SRS perspective
●​ Use Case Diagrams: Graphical views of system
Requirement Elicitation Methods interactions
●​ Often supported by Activity Diagrams to show
workflows
●​ Most critical & error-prone phase; needs strong
developer–customer collaboration
Requirement Analysis
Interview (Requirement Elicitation)
●​ Analyzes gathered requirements to find conflicts,
inconsistencies, or gaps
●​ Helps developers and stakeholders
understand each other ●​ Focus shifts from collection to clarification and
validation
●​ Types:
●​ Uses tools like:
○​ Open-ended: No fixed agenda; ask
broad, context-free questions ○​ DFD (Data Flow Diagram)
○​ Structured: Pre-defined questions and ○​ CFD (Control Flow Diagram)
flow ○​ ER Diagram (Entity-Relationship)

Brainstorming (Requirement Elicitation) DFD (Data Flow Diagram)

●​ Group discussion to quickly generate ideas ●​ Graphical view of data movement within a system
●​ Encourages creative thinking and participation ●​ Shows data sources, flows, processes, and storage
●​ No criticism; all ideas welcomed, no matter how ●​ Helps in understanding system requirements and
unusual transformations
●​ Widely used in modern organizations
Components:
Delphi Technique (Requirement Elicitation)
●​ Process (Function)
●​ Data Store
 ●​ External Entity ○​ Attributes: Properties or details related
●​ Data Flow to entities (e.g., employee name, product
price).
DFD Levels:
Decision Table
●​ 0-Level: Entire system as one process
●​ 1-Level: Major system functions ●​ Purpose: Visual representation to specify actions
●​ 2-Level: Detailed breakdown of 1-Level processes based on conditions
●​ Use: Helps manage complex input
Control Flow Diagram (CFD) / Flow Chart combinations and their corresponding outputs
●​ Role in Requirements & Testing:
●​ Graphical representation of control flow ○​ Useful in requirements management
during program execution ○​ Helps define business rules
●​ Uses symbols to represent processes, decisions, ○​ Essential in test design, providing a
and data flows structured way for developers and testers
●​ Helps visualize logical flow and sequence of to handle scenarios
operations
ISO 9000 in Software Engineering
Flowchart Symbols:
ISO 9000 provides international standards for quality
1.​ Oval (Start/End) management and assurance in software engineering. It
○​ Represents start or end of a process. focuses on implementing effective processes to ensure
2.​ Rectangle (Process) high-quality software products.
○​ Represents a process or action, such as
calculations or operations.
Key Components of ISO 9000:
3.​ Parallelogram (Input/Output)
○​ Represents input or output operations,
like entering data or displaying results. 1.​ Quality Management System (QMS):
4.​ Diamond (Decision) ○​ Defines policies and objectives for
○​ Represents a decision or branching point quality.
(yes/no or true/false). ○​ Documentation of procedures and
5.​ Arrow (Flowline) processes.
○​ Indicates the direction of flow or ○​ Monitoring and measuring processes,
movement of control in the process. plus corrective actions.
6.​ Circle (Connector) 2.​ Management Responsibility:
○​ Used for connecting different parts of the ○​ Top management commitment to quality.
flowchart, especially when the chart is too ○​ Establishment of a quality policy.
large to fit on one page ○​ Resource allocation and regular QMS
review.
3.​ Resource Management:
Data Dictionary ○​ Provision of resources (human,
infrastructure, work environment).
●​ Purpose: Repository for data item details in ○​ Competence and training of personnel.
DFDs, ensuring consistent definitions between ○​ Maintenance and improvement of
customers and developers infrastructure.
●​ Content: 4.​ Product Realization:
○​ Data item name, aliases, and purpose ○​ Requirements determination and
●​ Relationships & Range: communication.
○​ Records relationships and value ○​ Product design and development.
ranges (e.g., marks 0-100) ○​ Verification, validation, testing, and
●​ Data Flows & Structures: post-delivery support.
○​ Tracks how processes interact with data 5.​ Measurement, Analysis, and Improvement:
items and their structure ○​ Monitoring processes and products.
●​ Role in Requirements: ○​ Internal audits to ensure compliance.
○​ Critical in defining customer data and ○​ Corrective and preventive actions.
ensuring clear communication between ○​ Continual improvement of QMS.
developer and customer
ISO 9000 Principles:
Entity Relationship Diagram (ER Diagram)
●​ Customer focus
●​ Purpose: A conceptual design method that ●​ Leadership
represents the real-world view of data. ●​ Process approach
●​ Focus: Helps software designers specify an ●​ Continual improvement
enterprise schema for logical database structure.
●​ Main Constructs:
○​ Entities: Objects or things of interest ISO 9001:2015 – Quality Management
(e.g., Person, Product). Systems:
○​ Relationships: Associations between
entities (e.g., employee works for ●​ Applies to any organization size and industry.​
department).
●​ Focuses on customer satisfaction, regulatory
compliance, and improvement.
 ●​ Covers context, leadership, planning, support, ○​Training programs ensure staff has
operation, evaluation, and improvement. necessary skills and knowledge.
○​ Implementation of risk management
practices.
ISO/IEC/IEEE 90003:2018 – Software 4.​ Managed (Quantitative measurement):
Engineering: ○​ Organization sets quantitative goals for
both product and process.
●​ Provides guidance for applying ISO 9001:2015 ○​ Processes are now predictable with
to software engineering. respect to time and cost.
●​ Focuses on software development, supply, ○​ Performance metrics are collected and
acquisition, operation, and maintenance. analyzed.
●​ Applies to various software development 5.​ Optimized (Continuous process
methodologies. improvement):
○​ Focus is on analyzing defects to identify
root causes.
Benefits of ISO 9000 in Software ○​ The organization continuously
Engineering: improves its processes.
○​ Goal is to prevent defects and improve
●​ Improved customer satisfaction project performance.
●​ Enhanced process efficiency and effectiveness
●​ Reduced risk of software failures and defects
●​ Increased marketability and competitiveness
Key Practices for Improving
Maturity:
Implementation Steps for ISO 9000:
●​ Moving from ad hoc practices to defined
processes and ultimately to optimized
1.​ Obtain top management commitment.
performance.
2.​ Establish a quality management system
●​ Continuous training and process refinement at
(QMS)
each level.
3.​ Train and educate employees.
●​ Use of quantitative measurement at higher
4.​ Document processes, procedures, and policies.
maturity levels to track progress and outcomes.
5.​ Monitor, measure, and analyze processes.
6.​ Implement improvements and corrective
actions.
7.​ Conduct internal audits.
8.​ Seek third-party certification (ISO 9001).

CMM Overview:
●​ CMM is a strategy for improving the software
process to generate quality software.
●​ It’s based on a study funded by the U.S.
Department of Defense, aimed at improving
software development practices.
●​ Maturity refers to the degree of formality and
optimization of processes in an organization,
ranging from ad hoc practices to actively
optimized processes.
●​ Purpose: CMM is used to assess the maturity of
an organization’s software processes and guide the
improvement of these processes.

CMM Levels:
1.​ Initial (Process is unpredictable and poorly
controlled):
○​ Software development is ad hoc, with no
formal planning or management.
○​ Process is unpredictable regarding time
and cost.
○​ Dependent on the skills and experience of
the current staff.
2.​ Repeatable (Basic project management):
○​ New projects are planned and managed
based on experience with similar
projects.
○​ Realistic plans are developed based on
the performance of previous projects.
3.​ Defined (Process standardization):
○​ Software development processes are
documented and standardized across the
organization.