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
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.
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.
