3. Requirements analysis
Definition
Requirement
elicitation involves
interacting with clients, users, and other stakeholders to collect all the
necessary information that defines what the system should do, how it should
behave, and any constraints or expectations.
Goals of Requirement Elicitation
·
Understand stakeholder
needs.
·
Identify
functional and non-functional requirements.
·
Detect
constraints (technical, business, regulatory).
·
Resolve
conflicting requirements.
SRS – Software Requirements
Specification
An SRS (Software Requirements
Specification) is a detailed document that describes the functional
and non-functional requirements of a software system. It acts as a contract
between stakeholders (clients, users) and the development team.
An
SRS is a document that clearly defines what a software
system should do and how it should behave. It’s used
by developers, testers, and stakeholders to stay on the same page.
Why SRS is Important
·
Avoids confusion
·
Helps in planning
and development
·
Serves as a
contract between client and developers
1) Introduction
2) Purpose of the system
3) Scope
4) Definitions
5) Overall Description
6) What the system will do
7) User types
8) Constraints (e.g. platform, rules)
9) Specific Requirements
10)
Functional
Requirements – What the system
should do (features)
a. Example: “User can log in using email and password.”
11)
Non-Functional
Requirements – How the system
performs (speed, security, etc.)
a. Example: “System responds within 2 seconds.”
12)
Interface
Requirements – UI, hardware,
software, network interfaces
Developing Use Cases
Use cases describe how users (actors) interact
with a system to achieve a specific goal. They’re essential
for understanding system behavior and defining functional requirements.
Purpose of Use Cases
·
Capture user
interactions
·
Define system
functionality
·
Guide design
and testing
·
Improve
communication between stakeholders and developers
Key Terms
·
Actor: A user or external system that interacts with the
system
(e.g., Customer, Admin, Payment Gateway)
·
Use Case: A specific action or goal the actor wants to achieve
(e.g., “Place Order”, “Login”, “View Profile”)
What is an Analysis Model?
An Analysis Model is a
visual and structured way to represent system requirements,
created after gathering them. It helps translate what the system should
do into a format that's ready for design and development.
Key Components
1.
Use Case
Diagram – Shows system functions
and users
2.
Class
Diagram – Defines system
entities and their relationships
3.
Activity
Diagram – Describes workflows or
processes
4.
Sequence
Diagram – Shows interaction
between components over time
5.
State
Diagram – Shows how objects
change states
6.
ER
Diagram – Describes the database
structure
7.
Data
Dictionary – Lists all data
elements and their meanings
Key Elements of an Analysis Model
1.
Use Case
Diagram – Shows user
interactions with the system
2.
Class
Diagram – Defines system
entities and relationships
3.
Activity
Diagram – Represents workflows
or processes
4.
Sequence
Diagram – Shows object
interactions over time
5.
State
Diagram – Displays object state
changes
6.
ER
Diagram – Models data and
database relationships
7.
Data
Dictionary – Lists and defines
all data elements
8.
Business
Rules – System rules and
constraints
9.
Use Case
Descriptions – Detailed steps
for each use case
What is an Analysis Pattern?
An Analysis Pattern is a reusable
solution to a common problem found during the analysis phase
of software development. These patterns capture best practices
in modeling real-world concepts and problems, especially in business domains.
Agile Requirements Engineering (ARE)
ARE is the
process of gathering and managing requirements in an Agile way—iteratively,
flexibly, and collaboratively, instead of defining everything up front like
in Waterfall.
Key Concepts
- User Stories: Short, simple descriptions of a
feature (e.g., "As a user, I want...").
- Product Backlog: A prioritized list of user
stories or requirements.
- Backlog Refinement: Regular updates to clarify and
prioritize items.
- Acceptance Criteria: Defines when a story is
"done".
- Definition of Ready/Done: Ensures clarity before starting
and quality after finishing.
Negotiating Requirements in Agile (Quick Summary)
Goal: Align stakeholders and the team on what
to build, when, and why, within time and resource limits.
Why It's Important:
- Needs and priorities change.
- Time and budget are limited.
- Different people have different
expectations.
Key Techniques:
- User Stories – Focus on user needs.
- Backlog Refinement – Regularly discuss and adjust
requirements.
- Prototypes – Align expectations visually.
- Trade-offs – Balance scope, time, and
quality.
Validating
requirements ensures that the documented needs match what users actually want and can be
realistically built.
Goal:
Confirm that requirements
are correct, clear, and valuable before development begins.
Purpose:
Ensure requirements are correct, clear, and valuable before development.
How to Validate:
- Review with stakeholders
- Define acceptance criteria
- Use prototypes/mockups
- Check feasibility
- Test with examples (e.g., Given-When-Then)
Assignment
Question
1) Explain
the concept of Use Case Modeling in requirement analysis
2) What
is requirement analysis?
3) Explain
SRS (Software Requirements Specification) in detail
4) Explain
UML (Unified Modeling Language) in detail
5) What
are elements of analysis modeling?
6) What
is analysis pattern?
7) Explain
Agile requirement Engineering
8) What
is validating requirement?
Hi. I’m Designer of Blog Magic. I’m CEO/Founder of ThemeXpose. I’m Creative Art Director, Web Designer, UI/UX Designer, Interaction Designer, Industrial Designer, Web Developer, Business Enthusiast, StartUp Enthusiast, Speaker, Writer and Photographer. Inspired to make things looks better.
0 comments:
Post a Comment