Mod 2

1. a) Explain the nature and characteristics of good SRS?

A Software Requirements Specification (SRS) is a formal document that clearly

describes what the software system should do and the constraints under which it
must operate. It acts as a contract between the customer and the developer.

Nature of SRS
The nature of SRS explains how the document is used and what it represents.

1. User and Developer Oriented

o SRS is written so that customers, users, developers, and testers can
understand it.
o It bridges the gap between customer needs and technical
implementation.
2. Descriptive, Not Design-Oriented
o SRS describes what the system should do, not how it should be
implemented.
o Design details are intentionally avoided.
3. Complete Reference Document
o It serves as the single source of truth for requirements.
o All future activities like design, coding, testing, and maintenance depend
on it.
4. Baseline for Development
o Once finalized, SRS acts as a baseline.
o Any change must be properly reviewed and documented.

Characteristics of a Good SRS

A good SRS must have the following essential characteristics:

1. Correct

• Every requirement stated must reflect the actual needs of the customer.
• No incorrect or unnecessary requirements should be included.

2. Unambiguous

• Each requirement should have only one interpretation.

• Simple language, clear terms, and precise statements must be used.

3. Complete

• All functional requirements, non-functional requirements, and constraints

should be included.
 • No important requirement should be missing.

4. Consistent

• There should be no conflicts between requirements.

• Terminology and units should be used consistently throughout the document.

5. Verifiable (Testable)

• Every requirement should be written in a way that it can be tested or verified.

• Avoid vague terms like fast, user-friendly, or efficient without measurable criteria.

6. Feasible

• Requirements must be realistic and achievable within given time, budget, and
technology constraints.

7. Modifiable

• The SRS should be well structured so that changes can be made easily without
affecting the entire document.

8. Ranked for Importance and Stability

• Requirements should be prioritized based on importance and likelihood of

change.
• Helps in planning and managing changes effectively.

2. b) Describe requirement engineering process?

Requirement Engineering is a systematic process of identifying, analyzing,

documenting, validating, and managing software requirements throughout the
software development life cycle.

Its main aim is to ensure that the right system is built according to user needs.

Phases of Requirement Engineering Process

The Requirement Engineering process consists of the following major phases:

1. Feasibility Study

Description:

• Conducted to determine whether the proposed system is practical and worth

developing.
Types of feasibility:

• Technical feasibility – availability of technology

• Economic feasibility – cost vs benefit
• Operational feasibility – user acceptance

Example:
Checking whether a college can afford an online examination system and whether
staff can use it.

2. Requirement Elicitation

Description:

• Process of collecting requirements from stakeholders.

Methods used:

• Interviews
• Questionnaires
• Observation
• Brainstorming

Example:
Talking to teachers and students to know features like:

• Online test submission

• Automatic evaluation

3. Requirement Analysis

Description:

• Collected requirements are analyzed, refined, and prioritized.

• Conflicts and ambiguities are removed.

Activities involved:

• Identifying functional and non-functional requirements

• Resolving inconsistencies
• Checking feasibility

Example:
Deciding system response time and maximum number of users.

4. Requirement Specification

Description:
 • Requirements are clearly documented in a formal document called SRS
(Software Requirements Specification).

Contents of SRS:

• Functional requirements
• Non-functional requirements
• System constraints

Example:
SRS specifies:

• “The system shall allow students to submit assignments online.”

5. Requirement Validation

Description:

• Ensures that requirements are correct, complete, consistent, and realistic.

Techniques used:

• Reviews
• Walkthroughs
• Prototyping
• Test case generation

Example:
Users review SRS to confirm all required features are included.

6. Requirement Management

Description:

• Managing requirements throughout the project life cycle.

• Handles requirement changes effectively.

Activities include:

• Version control
• Change impact analysis
• Traceability

Example:
Adding a new feature like mobile app access after initial approval.
Requirement Challenges
Requirements engineering faces many challenges that make it difficult to identify,
document, and manage software requirements effectively. Some common requirement
challenges are explained below:

1. Requirements Are Difficult to Uncover

• It is always difficult, but not impossible, to identify all requirements at the

beginning.
• Some activities may have been done manually earlier, while others may be new
and never done before.
• Users themselves may not clearly know what they want from the system.

Example:
In an office automation system, users may initially forget to mention report generation
needs.

2. Changing Requirements

• Users cannot provide a complete and final list of requirements at the outset.
• As users start interacting with the system, they understand their needs better,
leading to new or changed requirements.
• Such fluid requirements are harmful for projects that are already committed in
terms of cost and schedule.

Example:
After seeing a prototype, a user may ask for additional security features.

3. Over-Reliance on CASE Tools

• CASE (Computer Aided Software Engineering) tools are helpful but should not
replace human understanding.
• Overdependence on tools may lead to unrealistic or exaggerated
requirements.
• Proper understanding of requirement engineering principles and techniques
is more important.

Example:
Automatically generated diagrams may look perfect but may not reflect real user needs.

4. Tight Project Schedule

• Due to poor planning or unreasonable customer demands, projects may start

with insufficient time.
• Sometimes the allocated time is reduced while the project is already in progress.
• Pressure for early design and coding without proper requirement analysis often
leads to project failure.
Example:
Skipping requirement validation to meet deadlines can result in wrong software
development.

5. Communication Barriers

• Users and developers often have different vocabularies, backgrounds, and

perspectives.
• Users prefer natural language, while developers need precise and technical
specifications.
• Requirement engineering is a communication-intensive activity, and
misunderstandings are common.

Example:
A user says “fast system,” while the developer needs a measurable response time.

6. Market-Driven Software Development

• Software is developed for anonymous customers, not a single known user.

• The goal is to attract users and encourage them to buy upgrades.
• It becomes difficult to identify and prioritize requirements that satisfy all users.

Example:
Mobile apps are updated frequently based on market trends and user feedback.

7. Lack of Resources

• There may be limited budget, manpower, or technology available.

• It may not be possible to implement all customer-requested features.
• This forces prioritization and compromise.

Example:
Advanced AI features may be dropped due to cost constraints.

Types of Requirements
1. Known Requirements

• Requirements that the stakeholder already knows and expects to be

implemented.
• Clearly stated during discussions.
Example:
User wants a login and logout feature.

2. Unknown Requirements

• Requirements forgotten by the stakeholder.

• Not needed immediately or required by another stakeholder.

Example:
Backup and recovery features mentioned later.

3. Undreamt Requirements

• Requirements the stakeholder cannot imagine due to limited domain

knowledge.
• Usually suggested by analysts or developers.

Example:
Auto-scaling feature in cloud-based systems.

4. Functional Requirements

• Describe what the software should do.

• Related to features and services of the system.
• Based on customer expectations.

Example:
System shall generate monthly reports.

5. Non-Functional Requirements

• Describe how well the system performs its functions.

• Also called quality requirements.

Examples:

• Performance
• Security
• Reliability
• Usability

6. Architectural Requirements

• Define the overall structure of the system.

• Include:
o Component naming
o Compatibility
o Interfaces
o Upgradability
Example:
System should support modular upgrades.

7. Constraints

• Limitations or restrictions on system design.

• Must be followed during development.

Examples:

• Legal requirements
• Coding standards
• Hardware/software limitations

8. User Requirements

• Written in simple language for users.

• Describe external behavior of the system.
• Include functional and non-functional requirements.

Example:
User should be able to register easily.

9. System Requirements

• Detailed and technical requirements.

• Derived from user requirements.
• Used by developers and designers.

Example:
Database schema and validation rules.
3. a) Describe analysis of requirements with various techniques
used for requirement analysis process?

Requirement Analysis is the process of studying, refining, and understanding user

requirements to clearly define what the software system should do.
It is performed after requirement elicitation and before system design.

Objectives

• Understand user needs clearly

• Remove ambiguity and conflicts
• Check feasibility
• Prepare a clear Software Requirements Specification (SRS)

Requirement Analysis Process

The requirement analysis process includes:

• Classifying requirements (functional / non-functional)

• Prioritizing requirements
• Identifying inconsistencies and missing requirements
• Modeling requirements
• Validating requirements

Techniques Used in Requirement Analysis

1. Interviews

• Direct discussion with users and stakeholders

• Can be structured or unstructured
• Helps understand detailed expectations

Example:
Interviewing a librarian to know book issue and return rules.

2. Questionnaires

• Written questions given to many users

• Useful when users are geographically distributed
• Saves time and cost

Example:
Surveying students about features in an online learning system.

3. Document Analysis

• Studying existing documents, forms, manuals, and reports

• Helps understand current system and business rules
Example:
Analyzing old payroll records to design a payroll system.

4. Use Case Analysis

• Describes system behavior through user–system interactions

• Shows step-by-step functionality

Example:
ATM use case: insert card → enter PIN → withdraw cash.

6. Prototyping

• A mock-up or working model of the system

• Helps users visualize the system and give feedback early

Example:
Showing a sample login screen to users.

7. Brainstorming

• Group discussion involving users and developers

• Encourages creative and innovative ideas

Example:
Suggesting features like voice search in a shopping app.

8. Feasibility Analysis

• Checks whether requirements are practical

Types:

• Technical feasibility
• Economic feasibility
• Operational feasibility

Example:
Checking if the system can support 10,000 users.

9. Requirement Modeling

• Representing requirements using diagrams

Tools:

• Data Flow Diagrams (DFD)

• UML diagrams
Example:
DFD showing data input, processing, and output.

Techniques Used in Requirement Analysis

STEPS IN REQUIREMENT ANALYSIS

1. Draw the context Diagram:

• Defines boundaries and interfaces of the proposed system with the external
world by identifying the entities outside the proposed system those interact with
the system

2. Development of a Prototype (optional):

A prototype is a preliminary working model of the system that is created quickly and at
low cost to understand user needs better.
It is not the final system, but only a sample version used for feedback.

• To understand what the customer really wants

Often users cannot fully explain their requirements.
By showing them a working model, they can say:
• “I need this button here”

• “This feature is missing”

• “This design is wrong”

This helps the development team refine the system.

• Helps identify unclear or uncertain requirements
When developers or users are not fully sure about:
• Workflows

• Inputs/outputs

• Screen designs

• System behavior

A prototype helps visualize the proposed system so both sides can understand it
easily.
• Helps in continuous improvement
The prototype is shown to the customer → They give feedback → Developers
modify it → Feedback again → Improvement continues until the customer is
satisfied.
This makes requirements more accurate.

3. Requirement Modeling

Requirement Modeling is the process of visually representing what the system must do.
It uses diagrams to show functions, data, users, and relationships.
This helps us to:
• Understand the system clearly

• Detect incorrect, missing, inconsistent, or extra requirements

• Communicate the system’s structure easily

4. Finalizing the Requirements (Simple Explanation)

Once we finish modeling the requirements using diagrams like

DFD, ERD, data dictionary, context diagram, etc., we get a clear,
corrected picture of how the system behaves.
At this stage:
• All inconsistencies are fixed

• All ambiguous requirements are clarified

• All missing requirements are added

• All wrong or extra requirements are removed

Now we convert these final, verified requirements into a standard document called:

4 . b) Describe the role of good SRS in requirement documentation

process?

A Software Requirements Specification (SRS) is a formal document that clearly

describes what the software system should do and the constraints under which it
must operate.
It plays a vital role in documenting requirements accurately

Roles of a Good SRS (with Examples)

1. Single and Complete Reference Document

• A good SRS contains all approved requirements in one document.

• Prevents confusion caused by oral discussions or emails.

Example:
Instead of repeatedly asking the customer about login rules, developers refer to the SRS.

2. Improves Communication Between Stakeholders

• Customers, developers, testers, and managers use SRS as a common

communication medium.
• Reduces misunderstandings due to different interpretations.

Example:
Customer says “secure login”; SRS clearly specifies password length and encryption
method.
3. Provides Clear Understanding of System Functionality

• Clearly defines system features and behavior.

• Helps stakeholders understand system scope.

Example:
SRS states that the system shall allow online payment, but shall not support cash
payment.

4. Foundation for Design and Development

• Designers and programmers use SRS as the base document.

• Ensures that development is aligned with user needs.

Example:
If SRS specifies “automatic email notification,” developers include email services in
design.

5. Basis for Testing and Verification

• Test cases are prepared using requirements in SRS.

• Helps verify whether software meets user expectations.

Example:
If SRS says response time must be less than 2 seconds, testers check this condition.

6. Helps in Requirement Validation

• Stakeholders review the SRS to ensure requirements are:

o Correct
o Complete
o Consistent
o Feasible

Example:
Customer reviews SRS and confirms all required reports are included.

7. Controls Changes in Requirements

• Once finalized, SRS acts as a baseline document.

• Any change must go through formal approval.

Example:
Adding a new mobile app feature requires updating the SRS and approval.

8. Supports Project Planning and Estimation

• Project managers use SRS to estimate:

o Cost
 o Schedule
o Resources

Example:
Knowing all features from SRS helps estimate development time accurately.

9. Helps in Maintenance and Future Enhancements

• During maintenance, SRS helps developers understand system behavior.

• Useful for new team members.

Example:
A new developer refers to SRS to understand report generation logic.

10. Legal and Contractual Document

• Acts as a formal agreement between customer and developer.

• Useful in resolving disputes.

Example:
If a feature dispute arises, both parties refer to the SRS.