SRS & REP

1. Welcome to our Presentation

2. SRS & REP
Presented By:
 Rashid Ali (20-Arid-4415)
Presented To:
 Mam Tayyaba Tariq

3. Contents
– What is SRS Document:
– Types of Requirements:
– SRS Structure
– characteristics of a great SRS
– Why is Getting Good Requirements Hard?
– Requirement Engineering
– Requirement Engineering process

4. What Is a SRS Document?
– SRS is a description of a software system to be developed.
– It lays out functional and non-function requirements of the software to be
developed.
– It may include a set of use cases that describe user interactions that the
software must provide to the user for perfect interactions.

5. Types of Requirements
– Functional requirements
– Statements of services 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.
– User Requirements
– Easy & Simple to operate
– Quick Response
– Effectively handling operational error
– Customer Support

6. SRS Structure
– Introduction:
– Purpose
– Intended Audience
– Scope
– Definitions
– Reference

7. Overall Description:
– User Interface
– System Software
– Constraints, assumption and dependencies
– User Characteristics

8. System Features And Requirement
– Functional Requirement
– Use Cases
– External Interface Required
– Logical Database Requirement
– Non-functional Requirement

9. Deliver For Approval
– Once you have added enough details to the SRS to describe what the system is
supposed to do, it is time to have the stakeholders approve the document.
– You will most likely have to make a presentation to the people involved in
the development process. They may ask for changes, and you will have to
update the SRS document based on stakeholder feedback before final approval.
– This is a good sign. It means developers and stakeholders are making the
document more precise, so the project is less like to go off track.

10. What are the characteristics of a great
SRS in software engineering?
– Clear and Unambiguous
– standard structure
– has only one possible interpretation
– Not more than one requirement in one sentence
– Correct
– A requirement contributes to a real need
– Understandable
– A reader can easily understand the meaning of the requirement
– Verifiable
– A requirement can be tested

11. Continue…
– Complete
– Contains all required information
– Consistent
– Does not conflict with other requirements
– Traceable
– Has unique identity, cannot be broken into parts

12. Why is Getting Good
Requirements Hard?
– Stakeholders don’t know what they really want.
– Stakeholders express requirements in their own terms.
– Different stakeholders may have conflicting requirements.
– Organisational and political factors may influence the system
requirements.
– The requirements change during the RE process. New stakeholders
may emerge and the business environment change.

13. Requirement Engineering
– Requirement Engineering means that requirements for a product
are defined, managed and tested systematically

14. Requirements Engineering
Process
Requirements
Management
Validation
Inception
Elicitation
Elaboration
Negotiation
Specification

15. Requirements Engineering
Process
– Inception —Establish a basic understanding of the problem and
the nature of the solution.
– Elicitation —Draw out the requirements from stakeholders.
– Elaboration (Highly structured)—Create an analysis model
that represents information, functional, and behavioral aspects of
the requirements.
– Negotiation—Agree on a deliverable system that is realistic for
developers and customers.

16. Continue…
– Specification—Describe the requirements formally or
informally.
– Validation —Review the requirement specification for errors,
ambiguities, omissions, and conflicts.
– Requirements management — Manage changing
requirements.