Software Engineering 1

SEC 2403
BSSE3-D

Engr. Syed Zahid Badshah

 Course Assessment
2

Marks Distribution
Total Total Marks / Total
Marks Head Frequency Exempted Frequency Marks/Head
Quiz 2 0 10 20
Final Paper 1 0 40 40
Mid Term Paper 1 0 25 25
Presentation 1 0 5 5
Report 1 0 10 10
Total Marks 100
• Report / presentation will be a group effort.
• You can work over an actual project for a company or can do a
research study over a certain topic. Everyone in the group will
present partially.
• Presentations are based over the report work. PPT is in the 12th
week with report submission.
 Requirements Management

• Starts at Baseline

• Implement Version Control

• Change Control
• Impact Analysis

• Track Status
• Trace requirements

Requirements Management – Requirement Attributes

oDate the requirement was created

oCurrent version number of the
requirement oAuthor who wrote the
requirement
oPriority
oStatus
oOrigin or source of the requirement
oRationale behind the requirement
oRelease number or iteration to which
the
requirement is allocated
oStakeholder to contact with questions or to

make decisions about proposed changes

oValidation method to be used or acceptance
criteria Requirements Management - Issues
 Requirements Management – Change Control
• All changes must follow the process. If a change request is not
submitted in accordance with this process, it will not be
considered.
• No design or implementation work other than feasibility
exploration will be performed on unapproved changes.
• Simply requesting a change does not guarantee that it will be
made. The project’s change control board (CCB) will decide
which changes to implement.
• The contents of the change database must be visible to all
project stakeholders.
• Impact analysis must be performed for every change.
• Every incorporated change must be traceable to an approved
change request.
• The rationale behind every approval or rejection of a change
request must be recorded.
Requirements Management – Change Attributes
Requirements
Management –
Change Control
Process
Requirements Management – Change Control
Documentation
Requirements Management – Change Dashboard

Requirements Management – Impact analysis procedure

The CCB Chair will ask one or more technical people (business
analysts, developers, and/or testers) to perform the impact
analysis for a specific change proposal.
Impact analysis involves three steps:
1. Understand the possible implications of making the change. A
requirement change often produces a large ripple effect,
leading to modifications in other requirements, architectures,
designs, code, and tests. Changes can lead to conflicts with
other requirements or can compromise quality attributes, such
as performance or security.
2. Identify all the requirements, files, models, and documents
that might have to be modified if the team incorporates the
requested change.
3. Identify the tasks required to implement the change, and
estimate the effort needed to complete those tasks
Requirements Management – Impact analysis Template
Requirements Management - Status
Requirements Management – Agile Projects
Requirements Management – Tracing Requirements
Requirements
Management –
Possible
Tracing Links
 Requirements Management –Tracing Importance

1. Finding missing requirements:

o Look for business requirements that don’t trace to any user requirements, and
user requirements that don’t trace to any functional requirements.

2. Finding unnecessary requirements:

o Look for any functional requirements that don’t trace back to user or business
requirements and therefore
o might not be needed.

3. Certification and compliance:

o You can use trace information when certifying a safety- critical product, o to
demonstrate that all requirements were implemented—although that doesn’t
confirm that they were implemented correctly!
 o Trace information demonstrates that requirements demanded for regulatory
compliance have been included and addressed, as is often needed for
applications for health care and financial services companies.
Requirements Management –Tracing Importance

4. Change impact analysis:

o Without trace information, there’s a good chance that you’ll overlook a system
element that would be affected if you add, delete, or modify a particular
requirement.

5. Maintenance:
o Reliable trace information facilitates your ability to make changes correctly and
completely during maintenance.
o When corporate policies or government regulations change, software systems
often must be updated.
 o A table that shows where each applicable business rule was addressed in the
functional requirements, designs, and code makes it easier to make the necessary
changes properly.

6. Project tracking:
o If you record the trace data during development, you’ll have an accurate record of
the implementation status of planned functionality.
o Absent links indicate work products that have not yet been created.
Requirements Management –Tracing Importance

7. Reengineering:
o You can list the functions in an existing system you’re replacing and
trace them to where they are addressed in the new system’s
requirements and software components.

9. Reuse:
 o Trace information facilitates the reuse of product components by
identifying packages of related requirements, designs, code, and
tests.

10.Testing:
o When a test fails, the links between tests, requirements, and code
point developers toward likely areas to examine for the defect.
Requirements Management –
Traceability Matrix Example

Table-1

Two Way Traceability Matrix

Table-2
Requirements Management –

Two Way Traceability Matrix

Requirements Management –
Suspect Links Tracking
 Requirements Management – Tracing Procedure

1. Educate the team and your management about the concepts and importance of
requirements tracing, your objectives for this activity, where the trace data is
stored, and the techniques for defining the links. Ask all participants to commit to
their responsibilities.

2. Select the link relationships you want to define from the possibilities shown in
Table-2 . Don’t try to do all of these at once! You’ll be overwhelmed.

3. Choose the type of traceability matrix you want to use: the single-matrix style
shown in Table-1 or several matrices like the one also shown in Table-2. Select a
mechanism for Links in the requirements chain storing the data: a table in a text
document, a spreadsheet, or (much better) a requirements management tool.

4. Identify the parts of the product for which you want to maintain traceability
information. Start with the critical core functions, the high-risk portions, or the
 portions that you expect will undergo the most maintenance and evolution over
the product’s life.

5. Identify the individuals who will supply each type of link information and the
person (most likely a BA) who will coordinate the tracing activities and manage
the data.
Requirements Management – Tracing Procedure
6. Modify your development procedures to remind developers to
update the links after implementing a requirement or an approved
change. The trace data should be updated soon after someone
completes a task that creates or changes a link in the requirements
chain.
7. Define the labeling conventions you will use to give each system
element a unique identifier so that the elements can be linked
together. Chapter 10, “Documenting the requirements,” described
several ways to label requirements.
8. As development proceeds, have each participant provide the
requested trace information as they complete small bodies of work.
Stress the advantage of ongoing accumulation of the trace data
over assembling it at a major milestone or at the end of the project.
9. Audit the trace information periodically to make sure it’s being kept
current. If a requirement is reported as implemented and verified,
yet its trace data is incomplete or inaccurate, your requirements'
tracing process isn’t working as intended.
Requirements Management – Tracing Feasibility
1. Cost vs. Benefit: Tracking requirements can be costly and time-consuming, so it’s important to
weigh whether it’s worth it for your project.

2. Knowledge Sharing: If team members have the necessary knowledge and share it effectively, you
might not need extensive tracking systems.

3. Team Decision: Only your team can determine if requirements tracing adds value to the project
compared to its costs.
4. Real-World Example: An attendee from an aircraft manufacturer shared that their requirements
documentation was six feet thick, showing the importance of traceability in high-stakes projects
like aviation.

5. Regulatory Requirements: Organizations like the FAA and FDA require traceability in aviation and
medical devices for safety and certification.

6. Importance of Tracing: Even if your product isn’t life-threatening, tracing business and user
requirements can help ensure alignment and identify unnecessary elements.

7. Strategic Consideration: A CEO questioned why tracing isn’t applied to strategic business systems,
highlighting its potential value.

8. Economic Decision: Evaluate the costs of requirements tracing against the risks of not using it, and
invest time where it will yield the best results.

END OF CLASS
 Requirement Analysis – Steps 1/4
1. Understand the Business Context:
• Gain a deep understanding of the business objectives, goals, and constraints behind
the project or system.
• Review background information, business goals, and high-level project objectives.
• Understand the challenges the organization faces and how the system or product will
address them.
• Identify any regulatory or compliance requirements impacting the project.
2. Identify Stakeholders Needs
• Identify key stakeholders and the needs of different user groups.
• List all relevant stakeholders (users, clients, business owners, technical teams).
• Conduct interviews or workshops to identify their expectations and pain points.
• Document their goals and what success looks like for each stakeholder.
3. Analyze the Existing System (if applicable)
• Understand the current system, process, or solution to identify improvements or
areas that need to be changed.
• Review existing systems or workflows to gather insights into what works and what
doesn’t.
 Requirement Analysis – Steps 2/4
• Identify current limitations, inefficiencies, or gaps that the new system needs to
address.
• Perform process mapping or system modeling to better visualize the current state.
4. Refine Requirements
• Clarify and refine the requirements gathered from stakeholders.
• Break down and clarify high-level requirements.
• Prioritize requirements based on importance, urgency, and impact.
• Identify any ambiguous or conflicting requirements and resolve them through further discussions.
• Ensure all requirements align with business goals and technical constraints.
5. Classify Functional and Non-Functional Requirements
• Classify and refine the functional and non-functional requirements for clarity.
• Functional Requirements: Ensure actions, interactions, or processes.
• Non-Functional Requirements: Check attributes like performance, scalability, reliability, security, etc.
• Document these in clear, measurable terms to avoid ambiguity.
6. Perform Gap Analysis
• Identify any gaps between the current system (if applicable) and the desired system.
 Requirement Analysis – Steps 3/4
• Analyze existing documentation, systems, and processes for missing functionality or improvements.
• Compare the desired outcome (as per stakeholder input) with the existing state to highlight discrepancies.
7. Verify Requirements with Stakeholders
• Ensure that the gathered and analyzed requirements accurately represent the process' needs.
• Conduct review sessions with stakeholders to confirm the requirements.
• Use prototypes, mockups, or wireframes where applicable to confirm understanding.
• Get feedback and adjust the requirements as necessary.
8. Create a Requirements Traceability Matrix (RTM)
• Track the progress of each requirement through the system's design, development, and testing phases.
• Map each requirement to a unique identifier and ensure traceability throughout the project lifecycle.
• Ensure that every requirement can be traced to design, implementation, and testing steps.
9. Document Assumptions, Constraints, and Dependencies
• Identify and document any assumptions, constraints, or dependencies that could impact the analysis.
• Record any assumptions about the system, users, technology, etc., that could affect requirements.
• Identify technical, operational, or regulatory constraints.
• Note any dependencies on other projects, systems, or third-party services.
 Requirement Analysis – Steps 4/4
10. Refine and Finalize the Requirement Analysis
• Ensure that the requirement analysis is comprehensive and clear.
• Review and refine the documented requirements to eliminate any ambiguities.
• Ensure the analysis covers all aspects of the problem and aligns with the goals of the business and
stakeholders.
• Prepare the final version of the requirements document for sign-off. Summary of Key Focus Areas in
Requirement Analysis:
• Business Understanding: Know the business goals and challenges.
• Stakeholder Communication: Engage stakeholders effectively to uncover needs and expectations.
• Clarification: Resolve ambiguities and prioritize conflicting or unclear requirements.
• Gap Identification: Compare the current state with the desired state and identify improvement.
• Verification: Continuously confirm with stakeholders to ensure the analysis aligns with their needs.
These steps focus on clarifying, refining requirements, which is the heart of the requirement analysis phase. The
goal is to create a well-understood, agreed-upon set of requirements that will guide the design and
implementation of the solution.
 Case Study
Requirement Engineering for a Mobile Application

Context:
A company wants to develop a mobile application for a personal finance
management system that helps users track:
• Expenses
• create budgets
• monitor their savings
• investments.

➢ The app should work on both iOS and Android platforms

➢ Provide users with real-time financial data, notifications, and an attractive

interface.
 Case Study
Requirement Engineering for a Mobile Application

Objective:
➢ The goal is to define the requirements engineering process for the mobile application.

➢ This includes identifying:

✓ stakeholders
✓ gathering functional
✓ non-functional requirements
✓ defining use cases
✓ addressing technical
✓ business constraints.
 Case Study
Requirement Engineering for a Mobile Application

Requirement Engineering Process Overview

The requirement engineering process follows five key phases:
1. Requirement Elicitation: Gathering requirements from stakeholders.
2. Requirement Analysis: Understanding and refining the requirements.
3. Requirement Specification: Documenting the functional and non-functional
requirements.
4. Requirement Validation: Ensuring the documented requirements meet the
stakeholders' needs.
5. Requirement Management: Managing changes to the requirements during the
project.
 Case Study Requirement Engineering for a Mobile Application

Breakdown of the Requirement Engineering Process 1/2

Requirement Elicitation
The first step involves gathering the initial requirements for the mobile app from all
stakeholders. The following methods will be used: A. Stakeholders Involved:
1.End Users (Customers): The primary users of the app.
2.Business Managers: Responsible for aligning the app with business goals.
3.Developers and Designers: Responsible for building the app.
4.Compliance Team: Ensures the app meets legal, security, and privacy requirements.
5.Marketing Team: Provides insight into user expectations and branding.
Breakdown of the Requirement Engineering Process 2/2
B. Elicitation Techniques:
 Case Study Requirement Engineering for a Mobile Application

1. Interviews and Surveys: Conduct interviews with potential users to understand their financial management needs
and preferences.
2. Workshops: Organize workshops with the development team and business managers to discuss goals and highlevel
requirements.
3. Competitor Analysis: Research existing personal finance apps to understand market expectations and potential
improvements.
4. Prototyping: Create early prototypes (low-fidelity wireframes) to get feedback from stakeholders about the desired
app functionality and user interface. C. Sample Questions for Elicitation:
1. What are the essential features that users expect from the finance app (expense tracking, budgeting, investment
tracking)?
2. What level of financial insights and reports should be generated?
3. How often would users like to receive notifications or alerts?
4. What security measures should be in place to protect sensitive data?
Requirement Analysis 1/2
 Case Study Requirement Engineering for a Mobile Application

Once the initial requirements are gathered, they need to be

analyzed and refined to ensure feasibility and alignment with the
project's scope. A. Key Tasks:

Prioritization: Not all features can be implemented at once, so

it's essential to prioritize requirements based on their business
value and complexity.
Dependency Mapping: Understand dependencies between
features, such as how expense tracking influences the budgeting
feature.
Feasibility Study: Conduct a technical and business feasibility
analysis to ensure that the app's core functionality can be
developed within the timeline and budget.
Requirement Analysis 2/2
 Case Study Requirement Engineering for a Mobile Application

B. Tools for Analysis:

• Use Case Diagrams: Help visualize user interactions with the system.

• Data Flow Diagrams (DFD): Show how financial data will flow through the
system.

• Entity-Relationship Diagrams (ERD): Help structure the database for tracking

expenses, budgets, and investments.
 Case Study Requirement Engineering for a Mobile Application

Requirement Specification 1/3

This phase involves creating a clear and detailed requirements document, which will serve as a reference for the
development and testing teams.
A. Functional Requirements: These specify what the system should do. For a finance app, functional requirements might
include:
User Authentication:
• Users should be able to sign up and log in using email, phone, or third-party services (Google, Apple).
• Users can reset their password or use biometric login (fingerprint/face recognition).
Expense Tracking:
• Users can manually enter expenses or sync them with bank accounts.
• Expenses can be categorized (e.g., Food, Transportation, Rent) for better tracking.
• Provide graphical reports (pie charts, bar graphs) of spending by category.
Budgeting:
• Users can set monthly budgets for various categories.
• The app will send notifications if users are nearing their budget limit.
 Case Study Requirement Engineering for a Mobile Application

Requirement Specification 2/3

Investment Monitoring:
• Users can add investment portfolios to track stocks, mutual funds, etc.
• Provide real-time or daily updates on investment performance.
Notifications and Alerts:
• Push notifications for bill payments, low balances, or budget overages.
• Periodic summary reports (daily, weekly, monthly) sent via email or in-app.
B. Non-Functional Requirements: These specify how the system should behave.
Performance:
• The app should load data within 2 seconds for typical use cases (expense input, budget overview).
Security:
• All financial data must be encrypted in transit (SSL) and at rest.
• Two-factor authentication (2FA) must be enabled for sensitive actions (e.g., account settings changes).
 Case Study Requirement Engineering for a Mobile Application

Requirement Specification 3/3

B. Non-Functional Requirements (continued):
Usability:
• The user interface should be intuitive and mobile-friendly, supporting various screen sizes (smartphones,
tablets).
Availability:
• The app should be available 99.9% of the time, with scheduled maintenance periods communicated to
users.
C. Use Case Diagram:
Will create a Use Case Diagram showing interactions between:
• Actors: Users, Admins, and External Services (Bank APIs).
Use Cases:
 Case Study Requirement Engineering for a Mobile Application

• Sign Up, Login, Add Expense, Generate Reports, Set Budget, View Investment Summary, Receive
Notifications.
Requirement Validation
The collected requirements are validated with stakeholders to ensure that they
meet the business and user needs.

A. Validation Techniques:
• Requirements Review: Organize review meetings with stakeholders, including
endusers and business managers, to validate the documented requirements.
• Prototyping: Provide early interactive prototypes to stakeholders for feedback.
• Test Case Design: The testing team can begin designing test cases based on the
requirements to ensure each feature works as expected during development.

B. Key Questions for Validation:

1. Do the functional requirements cover all core business goals?
2. Are the non-functional requirements aligned with user expectations for performance
and security?
 Case Study Requirement Engineering for a Mobile Application

3. Is the proposed budget feasible within the existing timelines?

 Case Study Requirement Engineering for a Mobile Application

Case Study Requirements Management

During the development lifecycle, requirements may change due

to evolving business needs, technology updates, or feedback from
beta testing. Managing these changes is critical to avoid scope
creep.

A. Tasks:
• Version Control: Maintain a version history of the requirements
document to track changes.
• Change Control Process: Establish a formal process to assess
and approve changes in requirements (e.g., adding new
features or removing existing ones).
 Case Study Requirement Engineering for a Mobile Application

• Traceability Matrix: Ensure all requirements are mapped to

their respective use cases, development tasks, and test cases
to track progress.
Challenges and Solutions in Requirement Engineering

A. Challenges:
• Ambiguity in Requirements: Stakeholders may provide vague requirements or conflicting opinions.
• Solution: Use precise and measurable language in requirements documents and conduct multiple review cycles
with stakeholders.
• Frequent Changes in Requirements: In mobile app projects, requirements can frequently change due to new
technology trends or market competition.
B. Solution:
• Implement agile methodologies (Scrum, Kanban) to accommodate changing requirements in an iterative manner.
C. User Expectations:
• Balancing (trade-off) the desires of users for more features with the technical and business limitations.
 Case Study Requirement Engineering for a Mobile Application

• Solution: Prioritize the MVP (minimum viable product) features and collect feedback early in the development
process.

Conclusion

Requirement engineering is a fundamental process for the successful development of

any mobile application.

By properly gathering, analyzing, documenting, and validating the requirements, the

project team ensured that the final product aligns with user needs and business goals.

This structured process also helped mitigate risks, manage changes effectively, and
deliver a high-quality mobile application.
Summary - Requirement engineering Process Followed
. Requirement Elicitation [VSD, Business vs Technical]
 Case Study Requirement Engineering for a Mobile Application
• Stakeholders, Elicitation Techniques [8], Sample Questions for Elicitation (Ask AI)
Requirement Analysis

• Key Tasks (Prioritization, Dependency Mapping, Feasibility Study [10 steps]; Tools for Analysis, Use Case,
DFD, ERD – 10 models)
Requirement Specification
• Functional Requirements, Non-Functional Requirements, Use cases (Diagrams)
Requirement Validation
• Validation Techniques (10) and Key questions for Validation (Ask AI)
Requirements Management

• Tasks (Version Control, Change Control Process, Traceability Matrix)

Challenges and Solutions
• Challenges, Solutions, balancing user expectations
Conclusion