Unit 3: Software requirement

specification and modeling

3.1 Requirements and its types
• Requirements are descriptions of the services that a software system
must provide and the constraints under which it must operate.
• Requirements can range from high-level abstract statements of
services or system constraints to detailed mathematical functional
specifications.
Level of the requirements
• High level: Business requirement
• Business view: Why is the project needed?
• Mid level: User requirements
• User view: What do users need the system do?
• Detailed: System requirements
• System view: What does the system need to do?
Requirements and its types
• User requirements:-Statements in natural language plus diagrams of
the services that the systems provides and its operational constraints.
It is written for customers.
• System requirements:- A structured document setting out detailed
descriptions of the system services. It is written as a contract between
client and contractor.
• Software specification A detailed software description which can
serve as a basis for a design or implementation. It is written for
developers.
Requirements and its types
• Business requirements
• These include high-level statements of goals, objectives, and needs.
• Stakeholder requirements
• The needs of discrete stakeholder groups are also specified to define what
they expect from a particular solution.
• Transition requirements
• An additional group of requirements defines what is needed from an
organization to successfully move from its current state to its desired state
with the new product.
Requirements and its types
• Solution requirements: Solution requirements describe the
characteristics that a product must have to meet the needs of the
stakeholders and the business itself.
• Non-functional requirements describe the general characteristics of a system.
They are also known as quality attributes.
• Functional requirements describe how a product must behave, what its
features and functions.
Functional Requirements
• These are the requirements that the end user specifically
demands as basic facilities that the system should offer.
• All these functionalities need to be necessarily incorporated into
the system as a part of the contract.
• These are represented or stated in the form of input to be given
to the system, the operation performed and the output expected.
• They are the requirements stated by the user which one can see
directly in the final product, unlike the non-functional
requirements.
• It describes, what are the features that we need to design for this
system?
Non-functional Requirements
• These are the quality constraints that the system must
satisfy according to the project contract.
• The priority or extent to which these factors are
implemented varies from one project to another.
• They are also called non-behavioral requirements. They
deal with issues like: Portability, Security,
Maintainability, Reliability, Scalability, Performance,
Reusability, Flexibility, etc.
Non-functional requirements
• Non-functional requirements describe how a system must behave and
establish constraints of its functionality.
• This type of requirements is also known as the system’s quality
attributes
• Huge Impact on end user expirience
Typical non-functional requirements
• Usability - Efficiency of use, Intuitiveness
• Security - authorization, data privacy
• Reliability – recovery, failover,
• Performance - responsiveness of the system,
• Availability - up/down, notification,
• Scalability - more data/users without negative influence on its
performance
Difference between Functional and
Non-functional requirements
• Functional requirement defines a system or its component but
non-functional requirement defines the quality attribute of a software system.
• Functional requirement is specified by users but non functional
requirement is specified by technical people like software
developers, technical leaders.
• Functional requirement in mandatory but non-functional
requirement is not mandatory.
• Functional requirement is captured in use cases but non-
Functional requirement is captured as quality attributes.
• Functional requirement is easy to define but non- Functional
requirement is difficult to define.
Examples
• Example of functional requirements:
1) Authentication of user whenever he/she logs into the
system.
2) System shutdown in case of a cyber attack.
3) A Verification email is sent to user whenever he/she
registers for the first time on some software system.
• Example of non-functional requirements:
1) Emails should be sent with a latency of no greater than 12
hours from such an activity.
2) The processing of each request should be done within 10
seconds
3) The site should load in 3 seconds when the number of
simultaneous users are > 10000
Functional, non-functional and
domain requirements
• Functional requirements:- Statements of services that the system
should provide, how the system should react to particular inputs and
how the system should behave in particular situations.
• Non-functional requirements:- Constraints on the services or
functions offered by the system such as timing constraints, constraints
on the development process, standards, etc.
• Domain requirements:- Requirements that come from the application
domain of the system that reflect the characteristics of that domain. It
may be functional or non-functional.
3.2 Requirements modeling
approaches
• Requirements modeling plays a crucial role in the development of
software systems by providing a clear representation of user needs
and system functionality.
• By modeling we can improve communication, reduce errors, and
streamline the development process and it capture, analyze, and
management the requirements, facilitating better collaboration and
communication throughout the project lifecycle.
• It helps stakeholders understand the system’s functionality and
ensures alignment between the business and technical teams.
Requirements modeling approaches
• Requirements modeling uses a combination of text and diagrammatic
forms to depict requirement in a way that is relatively easy to
understand and straightforward to review for correctness,
completeness and consistency.
• A software engineer (or analyst) builds the model using requirements
elicited from the customer.
• To validate software requirements, one need to examine them from a
number of different points of view: (next Slide)
Requirements modeling approaches
• Scenario-based models of requirements from the point of view of
various system “actors”
• Data models that depict the information domain for the problem
• Class-oriented models that represent object-oriented classes
(attributes and operations) and the manner in which classes
collaborate to achieve system requirements
• Flow-oriented models that represent the functional elements of the
system and how they transform data as it moves through the system
• Behavioral models that depict how the software behaves as a
consequence of external “events”
Requirements modeling approaches
• Structured analysis- considers data and the processes that transform
the data as separate entities. Data objects are modeled in a way that
defines their attributes and relationships.
• Object-oriented analysis-It focuses on the definition of classes and the
manner in which they collaborate with one another to effect
customer requirements. UML and the Unified Process are
predominantly object oriented.
3.3 Requirements Engineering
• It is the process of establishing the services that the customer
requires from the system and the constraints under which it is to be
developed and operated.
• Requirements may serve a dual function:
As the basis of a bid for a contract
As the basis for the contract itself
3.4 Requirement Elicitation
• It's a process of interacting with customers and end-users to find out
about the domain requirements, what services the system should
provide, and the other constraints.
• It is the process of gathering and defining the requirements
for a system that ensure the system development process
is based on a clear and comprehensive understanding of
the customer’s needs and requirements.
• It is the most difficult, most error-prone, and most
communication-intensive activity in Software engineering
and is a critical part performed at the beginning of the
project.
Requirement Elicitation
• The output of the requirements elicitation process is a
set of clear, concise, and well-defined requirements that
serve as the basis for the design and development of
the software system.
• Requirements elicitation is difficult because just
questioning users and customers about system needs
may not collect all relevant requirements.
• Many methods can be used to elicit requirements.
Importance of Requirements Elicitation

• Compliance with Business Objectives

• User Satisfaction
• Time and Money Savings
• Compliance and Regulation Requirements
• Traceability and Documentation
3.5 Collaborative requirement
gathering
• Collaborative requirements gathering involves collaboration among all
stakeholders, including users, developers, and business analysts
working together to identify problems, propose solutions, and
negotiate different approaches to define the core requirements of a
solution.
• This process is crucial for ensuring that the final product or service
meets the needs and expectations of all stakeholders
• This method It uses workshops, brainstorming sessions, and focus
groups to identify and refine requirements collectively.
Collaborative requirement
gathering-Processes
1. Defining the scope and stakeholders.
2. Engaging in Collaborative Discussions
3. Documenting and Managing Requirements
1. Defining the Scope and
Stakeholders
• Identify Stakeholders: Determine who will be impacted by the project
and who has a interest in its outcome. This includes end-users, project
sponsors, project team members, and anyone else who has a stake in
the project.
• Establish Clear Communication: Set up clear communication channels
and protocols for all stakeholders to ensure effective collaboration
and information sharing.
• Define the Project Goal: Clearly articulate the objectives of the project
and the desired outcome to guide the requirements gathering
process.
2. Engaging in Collaborative
Discussions
• Meetings and Workshops: Conduct meetings and workshops where
developers and customers can discuss the problem, brainstorm
potential solutions, and refine requirements.
• Prototyping and Modeling: Use prototypes and models to visualize
the proposed solutions and allow for early feedback from
stakeholders.
• Iterative Approach: Follow an iterative approach, where requirements
are refined and adjusted throughout the development process based
on feedback and emerging insights,
3. Documenting and Managing
Requirements
• Requirements Documentation: Create clear and concise
documentation that captures all the gathered requirements, including
functional and non-functional requirements.
• Requirements Tracking: Use a system to track the status of
requirements, such as whether they are approved, in progress, or
rejected.
• Version Control: Implement version control for the requirements
documents to ensure that everyone is working with the latest version
and to track changes over time.
Key techniques in Collaborative
Requirement Gathering
• Brainstorming: Generate a wide range of ideas and potential
solutions collaboratively.
• Interviews: Conduct structured interviews with stakeholders to gather
detailed information and understanding.
• Surveys: Use surveys to collect quantitative data and feedback from a
wider audience.
• Document Analysis: Review existing documents and reports to
identify relevant information.
• Workshops: Facilitate collaborative workshops where stakeholders
can discuss and refine requirements together.
3.6 Requirement Analysis
• Requirement analysis is significant and essential activity after
elicitation.
• Here, we analyze, refine, and scrutinize the gathered
requirements to make consistent and unambiguous
requirements.
• This activity reviews all requirements and may provide a
graphical view of the entire system.
Requirement Analysis
• After the completion of the analysis, it is expected that the
understandability of the project may improve significantly.
• Interaction with the customer can be used to clarify points of
confusion and to understand which requirements are more
important than others.
Processes in Requirement Analysis
• Requirements discovery-Interacting with stakeholders to discover
their requirements. Domain requirements are also discovered at this
stage.
• Requirements classification and organization-Groups related
requirements and organizes them into coherent clusters.
• Prioritization and negotiation-Prioritizing requirements and resolving
requirements conflicts.
• Requirements documentation-Requirements are documented and
input into the next round.
3.7 Negotiating Requirements
• Negotiation refers to the process of reaching agreements among
stakeholders about software requirements, design decisions,
timelines, resources, or any other aspects of a project.
• Negotiating requirements in software engineering is a critical process
for ensuring a successful project.
• It involves understanding stakeholder needs, prioritizing
requirements, and reconciling conflicts to create a feasible and
desirable product.
• Effective negotiation is essential for aligning expectations, managing
resources, and ultimately achieving project goals.
Negotiating Requirements
• This phase emphasizes discussion and exchanging conversation on
what is needed and what is to be eliminated.
• In the negotiation phase, negotiation is between the developer and
the customer and they dwell on how to go about the project with
limited business resources.
• Customers are asked to prioritize the requirements and make
guesstimates on the conflicts that may arise along with it.
• Risks of all the requirements are taken into consideration and
negotiated in a way where the customer and developer are both
satisfied with reference to the further implementation.
Negotiating Requirements
• Availability of Resources.
• Delivery Time.
• Scope of requirements.
• Project Cost.
• Estimations on development.
3.8 Requirement Documentation
and Validation
• The requirements engineer gathers all the requirements and develops
a working model.
• The models used in this phase include ER (Entity Relationship)
diagrams, DFD (Data Flow Diagram), Activity diagrams, etc.
• A software specification document is submitted to the customer in a
language that he/she will understand, to give a glimpse of the
working model.
Requirement Documentation and
Validation
• Requirement validation is concerned with demonstrating that the
requirements define the system that the customer really wants.
• Requirements error costs are high so validation is very important
(Fixing a requirements error after delivery may cost up to 100 times
the cost of fixing an implementation error).
• Check that all the requirements have been stated and met correctly
• Check that errors have been debugged and corrected.
• Check that work product is built according to the standards.
Need of Requirement Document
• “If a company wishes to let a contract for a large software
development project it must define its needs in a sufficiently abstract
way that a solution is not pre defined. The requirements must be
written so that several contractors can bid for the contract, offering,
perhaps, different ways of meeting the client organi sation’s needs.
Once a contract has been awarded, the contractor must write a
system definition for the client in more detail so that the client
understands and can validate what the software will do. Both of these
documents may be called the requirements document for the
system.”
User of Requirement Document
• System customers-Specify the requirements and read them back to
check that they meet their needs; specify changes to the requirements
• Development Managers-Use the requirements document to plan a bid
for the system and to plan the system development process
• Implementation Programmers-Use the requirements to understand
what system is to be developed
• Test programmers-Use the requirements to develop validation tests for
the system
• Maintenance programmers Use the requirements to help understand
the system and the relationships be tween its parts.
Requirements checking for Validity

• Validity->Does the system provide the functions which best support

the customer’s needs?
• Consistency->Are there any requirements conflicts?
• Completeness->Are all functions required by the customer included?
• Realism=>Can the requirements be implemented given available
budget and technology?
• Verifiability->Can the requirements be checked?
3.9 Requirements management
• Requirements management is a set of activities where the entire
team takes part in identifying, controlling, tracking, and establishing
the requirements for the successful and smooth implementation of
the project.
• It is the process of managing changing requirements during the
requirements engineering process and system development.
• Requirements management involves communication between the
project team members and stakeholders, and adjustment to
requirements changes throughout the course of the project.
Requirement Management
• To prevent one class of requirements from overriding another, constant
communication among members of the development team is critical.
• The activities in requirement management are:
• Recognizing the need for change in the requirements
• Establishing a relationship amongst stakeholders and involving them in the
requirements engineering process
• Identifying and tracking requirements attributes.
• Requirements management enables the development team to identify,
control, and track requirements and changes that occur as the software
development process progresses.
Scenario, Data, Class and flow
oriented modeling
• Use Case Modeling-Use case diagram
• Data model-ER Diagram
• Class based modeling-Class diagram
• Flow oriented modeling-DFD
Flow Oriented Modeling
• It is old, but most widely used requirements analysis notations in use
today.
• The data flow diagram (DFD) is the representation of Flow-oriented
modeling.
• The purpose of data flow diagrams is to provide a semantic bridge
between users and systems developers.
• The DFD takes an input-process-output view of a system. That is, data
objects flow into the software, are transformed by processing
elements, and resultant data objects flow out of the software.
Flow Oriented Modeling
• Data objects are represented by labeled arrows, and transformations
are represented by circles (also called bubbles).
• The DFD is presented in a hierarchical fashion.
• That is, the first data flow model (sometimes called a level 0 DFD or
context diagram) represents the system as a whole.
• Subsequent data flow diagrams refine the context diagram, providing
increasing detail with each subsequent level.
Creating Data flow model
• The data flow diagram enables you to develop models of the
information domain and functional domain.
• The DFD is refined into greater levels of detail where you perform an
implicit functional decomposition of the system.
• At the same time, the DFD refinement results in a corresponding
refinement of data as it moves through the processes that embody
the application.
Guideline to draw DFD
1. The level 0 data flow diagram should depict the software/system as
a single bubble;
2. Primary input and output should be carefully noted;
3. Refinement should begin by isolating candidate processes, data
objects, and data stores to be represented at the next level;
4. All arrows and bubbles should be labeled with meaningful names;
5. Information flow continuity must be maintained from level to
level,2 and
6. One bubble at a time should be refined.
Context diagram-Safe Home
Security System
Level 1 DFD for Home Security
System
Level 2 DFD-monitor sensor process
Scenario Based Modeling
• Scenario-based modeling is one of the sub-stages of requirements
modeling which shows how the user interacts with the system and
the specific sequence of activities that occur as the software is used.
• It is the first stage of requirements modeling, it identifies the primary
use cases for the proposed software system or application, to which
later stages of requirements modeling will refer.
• A use case captures the interactions that occur between producers
and consumers of information and the system itself.
• A use case describes a specific usage scenario in straightforward
language from the point of view of a defined actor.
Creating Data Flow Diagrams
Lemonade Stand Example
 Creating Data Flow Diagrams
Example Steps:
The operations of a simple lemonade 1. Create a list of activities
stand will be used to demonstrate the • Old way: no Use-Case Diagram
creation of dataflow diagrams.
• New way: use Use-Case Diagram
2. Construct Context Level DFD
(identifies sources and sink)
3. Construct Level 0 DFD
(identifies manageable sub processes )
4. Construct Level 1- n DFD
(identifies actual data flows and data stores )
 Creating Data Flow Diagrams
Example 1. Create a list of activities

Think through the activities that take

place at a lemonade stand.

Customer Order
Serve Product
Collect Payment
Produce Product
Store Product
 Creating Data Flow Diagrams
Example 1. Create a list of activities

Also think of the additional activities

needed to support the basic activities.

Customer Order
Serve Product
Collect Payment
Produce Product
Store Product
Order Raw Materials
Pay for Raw Materials
Pay for Labor
 Creating Data Flow Diagrams
Example 1. Create a list of activities

Group these activities in some logical

fashion, possibly functional areas.

Customer Order
Serve Product
Collect Payment

Produce Product
Store Product

Order Raw Materials

Pay for Raw Materials

Pay for Labor

 Creating Data Flow Diagrams
Example 2. Construct Context Level DFD
(identifies sources and sink)
Create a context level diagram
identifying the sources and sinks Context Level DFD
(users).
Sales Forecast
Order 0.0
CUSTOMER Lemonade Production Schedule EMPLOYEE
Customer Order Product Served System Pay
Serve Product Payment Time Worked
Collect Payment Received Goods
Payment
Purchase Order
Produce Product
Store Product VENDOR

Order Raw Materials

Pay for Raw Materials

Pay for Labor

 Creating Data Flow Diagrams
Example 3. Construct Level 0 DFD
Create a level 0 diagram identifying (identifies manageable sub processes )
the logical subsystems that may exist. Level 0 DFD
1.0
Sale
Customer Order Sales Forecast
Customer Order
Product Ordered
Serve Product
Payment
Collect Payment 2.0 Production
CUSTOMER EMPLOYEE
Production Schedule
Product Served
Produce Product
Inventory
Store Product Received Goods

3.0
VENDOR Order
Purchase Order Procure-ment
Order Raw Materials Decisions
Pay for Raw Materials Payment
Pay Time Worked

Pay for Labor 4.0

Payroll
 Creating Data Flow Diagrams
Example 4. Construct Level 1- n DFD
Create a level 1 decomposing the (identifies actual data flows and data stores )
processes in level 0 and identifying Level 1 DFD
data stores.
CUSTOMER
Customer Order
Request for Forecast
Customer Order ORDER

Serve Product 1.1

Record Order
Collect Payment
1.3
Severed Order Produce Sales
Forecast
Produce Product Payment Sales Forecast
Store Product
1.2
Receive PAYMENT
Payment
Order Raw Materials
Pay for Raw Materials

Pay for Labor

 Creating Data Flow Diagrams
Example 4. Construct Level 1 (continued)
Create a level 1 decomposing the
processes in level 0 and identifying Level 1 DFD
data stores.
Product Order
ORDER
Customer Order 2.1
Serve Quantity Severed
Serve Product Product
Collect Payment
Production RAW MATERIALS
Schedule
Produce Product 2.2
Store Product Produce Quantity Used
Product

INVENTORTY
Order Raw Materials Production Data
Pay for Raw Materials
2.3 Quantity Produced & Location
Store Stored
Pay for Labor Product
 Creating Data Flow Diagrams
Example 4. Construct Level 1 (continued)
Create a level 1 decomposing the
processes in level 0 and identifying Level 1 DFD
data stores. Order Decision
3.1 PURCHASE ORDER
Produce
Purchase
Customer Order Order Quantity On-Hand
Serve Product Quantity RAW MATERIALS
Collect Payment Received
Received Goods
3.2
Produce Product Receive
Items
Store Product RECEIVED ITEMS
Payment Approval
Order Raw Materials
VENDOR
Pay for Raw Materials 3.3
Pay Vendor

Pay for Labor

Payment
 Creating Data Flow Diagrams
Example 4. Construct Level 1 (continued)
Create a level 1 decomposing the
processes in level 0 and identifying Level 1 DFD
data stores. Time Worked
TIME CARDS
4.1
Record Time
Customer Order Worked Employee ID
Serve Product EMPLOYEE
Collect Payment
Payroll Request
4.2
Unpaid time cards
Produce Product Calculate
Payroll
Store Product PAYROLL

Payment Approval
Order Raw Materials
Pay for Raw Materials 4.3
Pay
Employee
PAYMENTS
Pay for Labor
Payment
 Process Decomposition
1.2
1.0 1.1
Receive
Sale Record Order
Payment

2.1 2.2 2.3

2.0
Serve Produce Store
Production
Product Product Product

0.0
Lemonade
System
3.1
3.2
3.0 Produce 3.3
Receive
Procure-ment Purchase Pay Vendor
Items
Order

4.1 4.2 4.3

4.0
Record Time Calculate Pay
Payroll
Worked Payroll Employee

Context Level Level 0 Level 1

 DFD Example: Bus Garage Repairs
• Buses come to a garage for repairs.
• A mechanic and helper perform the repair, record the reason for the
repair and record the total cost of all parts used on a Shop Repair Order.
• Information on labor, parts and repair outcome is used for billing by the
Accounting Department, parts monitoring by the inventory
management computer system and a performance review by the
supervisor.
DFD Example: Bus Garage Repairs (cont’d)

• External Entities: Bus, Mechanic, Helper, Supervisor, Inventory

Management System, Accounting Department, etc.
• Key process (“the system”): performing repairs and storing
information related to repairs
• Processes:
• Record Bus ID and reason for repair
• Determine parts needed
• Perform repair
• Calculate parts extended and total cost
• Record labor hours, cost
DFD Example: Bus Garage Repairs (cont’d)
• Data stores:
• Personnel file
• Repairs file
• Bus master list
• Parts list
• Data flows:
• Repair order
• Bus record
• Parts record
• Employee timecard
• Invoices
Requirement Modeling for web apps
• Requirements analysis does take time, but solving the wrong problem
takes even more time.
• It only demands an analysis of those requirements that affect only
that part of the WebApp.
• The degree to which requirements modeling for WebApps is
emphasized depends on the following factors: (Next Slide)
Requirement Modeling for web apps
• Size and complexity of WebApp increment.
• Number of stakeholders.
• Size of the WebApp team.
• Degree to which members of the WebApp team have worked
together.
• Degree to which the organization’s success is directly dependent on
the success of the design of a specific part of the WebApp.
Requirements Modeling Input
• The requirements model provides a detailed indication of the true
structure of the problem and provides insight into the shape of the
solution.
• Requirements analysis refines this understanding by providing
additional interpretation.
• As the problem structure is delineated as part of the requirements
model.
Requirements Modeling Output
• Requirements analysis provides a disciplined mechanism for
representing and evaluating WebApp content and function, the
modes of interaction that users will encounter, and the environment
and infrastructure in which the WebApp resides.
• Each of these characteristics can be represented as a set of models
that allow the WebApp requirements to be analyzed in a structured
manner.
• While the specific models depend largely upon the nature of the
WebApp.
Classes of Models
• There are five main classes of models:
1. Content model
2. Interaction model
3. Functional model
4. Navigation model and
5. Configuration model.
Classes of Models
• Content model—identifies the full spectrum of content to be provided by
the WebApp. Content includes text, graphics and images, video, and audio
data.
• Interaction model—describes the manner in which users interact with the
WebApp.
• Functional model—defines the operations that will be applied to WebApp
content and describes other processing functions that are independent of
content but necessary to the end user.
• Navigation model—defines the overall navigation strategy for the WebApp.
• Configuration model—describes the environment and infrastructure in
which the WebApp resides.
Importance of SRS
• It is a document in which all the user requirements are mentioned in
a structural manner.
• SRS is a kind of agreement between the customer and the company,
which contains complete information about the requirement desired
by the customer and the product made by the company.
• In other words, SRS is a document which describes what will be the
features of the software and what will be its behavior, what kind of
performance it will perform.
Characteristics of SRS
• Complete: The SRS should be complete i.e. all the software requirements
should be mentioned in the SRS.
• Correct: It should be correct i.e. it should be according to the needs of the
customer.
• Clear: It should be clear. The requirements of the software should be clearly
declared.
• Accurate: It should have accuracy. If this is not accurate then the software
cannot be developed.
• Consistent: It should be consistent from beginning to end so that users can
easily understand the requirements. And consistency can be achieved only
when there is no contradiction between the two requirements.
Characteristics of SRS
• Verifiable: It should be verifiable. The requirements are verified by experts
and testers.
• Modifiable: All the requirements specified in the SRS document should be
modifiable. This can happen only when the structure of SRS is balanced.
• Traceable: It should be traceable, that is, each requirement in it should be
identified differently. Each requirement should have its own identity.
• Testable: It should be testable i.e. it should be capable of being tested in
any way.
• Unambiguous: It can be unambiguous only when all the requirements have
only one meaning. That is, there should be only one interpretation.
Importance of SRS
• Clarity and Understanding: The SRS provides a common
communication channel between stakeholders, so that everyone
agrees as to what the project aims at. It reduces ambiguity and the
risks of misunderstandings among team members in clearly defining
requirements.
• Basis for Project Planning: The planning for software development
projects must be particularly detailed. The SRS is the required
information for project managers to define realistic timelines, assign
appropriate resources and set milestones. It provides a basis for
planning projects, which allows teams to accurately estimate costs
and schedules.
Importance of SRS
• Guidance for Development Teams: The SRS is used to guide developers
in their understanding of the functional specifications and how the
software will be designed. The document offers an overview of the
system architecture, user interfaces and data structures which enable
developers to build a system that meets with client expectations.
• Facilitates Testing and Quality Assurance: SRSs are used as references
by quality assurance and testing teams, which use them to design test
cases verifying that the software conforms with what was specified.
Because testing has well-specified requirements, it becomes much
more of a systematic procedure and the chance that an important
functionality is overlooked are reduced.
Importance of SRS
• Change Management: During projects, changes are unavoidable. The
SRS thus provides a baseline from which any proposed changes can be
judged. This guarantees that changes are thoroughly recorded,
approved and properly implemented--without scope creep.
• Client and Stakeholder Satisfaction: The SRS is a contract between
the development team and their client or stakeholders. This boosts
client satisfaction and trust if the final product meets what was
documented. Moreover, such clear documentation provides a
foundation for resolving disputes or disagreements over the course of
development.
Importance of SRS
• Risk Mitigation: The earlier in the software development life cycle
you can spot potential risks, the better. The SRS helps in risk
assessment by specifying dependencies, constraints and possible
risks. This makes the development process smoother for project
managers who can then come up with strategies to prevent risk.
• Enhanced Collaboration: Software development requires
collaboration. The SRS has team spirit Working together with cross-
functional teams, it forms a single vision and shared understanding of
the project. As a result, the development process becomes more
integrated and efficie
Assignment 3
• Define software requirements. Discuss about its types with examples.
• Explain requirement modeling approaches used during requirement
modeling.
• Explain requirement modeling process in detail.
• What do you mean by collaborative requirement modeling. List out
about its importance.
• What is DFD? Discuss about importance of DFD and explain how you
construct DFD with example.
• Why requirement modeling for WebApps is different? Discuss the
process of requirement modeling for WebApps.
• Discuss about the importance of SRS in Software Engineering.