(SRS) SOFTWARE REQUIREMENT SPECIFICATION(SRS) 1. Topics to be discussed.. What is an SRS? Purpose of an SRS Who reads the SRS? Who writes the SRS? Characteristics.

Slides:



Advertisements
Similar presentations
Design by Contract.
Advertisements

Ch 3: Unified Process CSCI 4320: Software Engineering.
CS 411W - Notes Product Development Documentation.
Characteristics of a good SRS
Requirements Analysis CS 414 – Software Engineering I Donald J. Bagert Rose-Hulman Institute of Technology January 7, 2003.
Use-case Modeling.
The Unified Software Development Process - Workflows Ivar Jacobson, Grady Booch, James Rumbaugh Addison Wesley, 1999.
Analysis Stage (Phase I) The goal: understanding the customer's requirements for a software system. n involves technical staff working with customers n.
Business Area Analysis Focus: Domain View (selected business area) Goals: –Isolate functions and procedures that allow the area to meet its goals –Define.
SE 555 Software Requirements & Specification Requirements Validation.
1 Software Requirements Specification Lecture 14.
1 REQUIREMENTS ENGINEERING and SYSTEMS ANALYSIS Elements and Definitions.
1 CMPT 275 Software Engineering Requirements Analysis Process Janice Regan,
S R S S ystem R equirements S pecification Specifying the Specifications.
Gregor v. Bochmann, University of Ottawa Based on Powerpoint slides by Gunter Mussbacher (2009) with material from: IEEE Standard, Daniel Amyot.
Software Requirement Specification(SRS)
SOFTWARE DEVELOPMENT DOCUMENTATION. INTRODUCTION Documentation can be tied into the entire software development cycle. Unfortunately, documentation is.
DCT 1123 PROBLEM SOLVING & ALGORITHMS INTRODUCTION TO PROGRAMMING.
The Software Development Life Cycle: An Overview
SOFTWARE REQUIREMENTS SPECIFICATION (SRS)
S/W Project Management
1 Building and Maintaining Information Systems. 2 Opening Case: Yahoo! Store Allows small businesses to create their own online store – No programming.
Software Requirements Specification (SRS) Complete description of external behavior of software system Complete description of external behavior.
Typical Software Documents with an emphasis on writing proposals.
Software Engineering 2003 Jyrki Nummenmaa 1 REQUIREMENT SPECIFICATION Today: Requirements Specification Requirements tell us what the system should.
SE-02 SOFTWARE ENGINEERING LECTURE 3 Today: Requirements Analysis Requirements tell us what the system should do - not how it should do it. Requirements.
Topics Covered: Software requirement specification(SRS) Software requirement specification(SRS) Authors of SRS Authors of SRS Need of SRS Need of SRS.
Lecture 16 March 22, 2011 Formal Methods CS 315 Spring Adapted from slides provided by Jason Hallstrom and Murali Sitaraman (Clemson)
Software Inspections. Defect Removal Efficiency The number of defects found prior to releasing a product divided by The number of defects found prior.
Negotiation and Specification Process
ECE450 – Software Engineering II
Computer Science School of Computing Clemson University Introduction to Formal Specification Murali Sitaraman Clemson University.
1 Lecture 5.2.b: Requirements Specifications (IEEE 830) Dr. John MacCarthy UMBC CMSC 615 Fall, 2006.
Standard SRS Copyright, 2001 © Jerzy R. Nawrocki Requirements Engineering Lecture.
Software Requirements Engineering CSE 305 Lecture-2.
CPSC 873 John D. McGregor Session 4 Requirements V & V - continued.
Software Engineering – University of Tampere, CS DepartmentJyrki Nummenmaa REQUIREMENT SPECIFICATION Today: Requirements Specification.
IS 466 ADVANCED TOPICS IN INFORMATION SYSTEMS LECTURER : NOUF ALMUJALLY 22 – 10 – 2011 College Of Computer Science and Information, Information Systems.
Lecture 7: Requirements Engineering
9/01RUT1 NASA OSMA SAS '01 R equirements U se case T ool James R. McCoy SRS Information Services NASA Software Assurance Technology Center
1 15 quality goals for requirements  Justified  Correct  Complete  Consistent  Unambiguous  Feasible  Abstract  Traceable  Delimited  Interfaced.
1 Software Requirements l Specifying system functionality and constraints l Chapters 5 and 6 ++
Capturing the requirements  Requirement: a feature of the system or a description of something the system is capable of doing in order to fulfill the.
Chapter 4 Software Requirements
1 Quality Attributes of Requirements Documents Lecture # 25.
Software Development A Proposed Process and Methodology.
OHTO -01 SOFTWARE ENGINEERING LECTURE 3 Today: Requirements Analysis Requirements tell us what the system should do - not how it should do it.
Chapter 2 Object-Oriented Paradigm Overview. Getting Acquainted with the Class Project Read the requirements specification carefully Make note of any.
Requirement Engineering. Recap Elaboration Behavioral Modeling State Diagram Sequence Diagram Negotiation.
Week 3: Requirement Analysis & specification
第 11 組 MIS 報告. Phases of any information system ~ recognition of a business problem or opportunity ~ recognition of a business problem or opportunity.
Software Requirements Specification (SRS)
Winter 2007SEG2101 Chapter 31 Chapter 3 Requirements Specifications.
System Requirements Specification
Software Requirements Specification Document (SRS)
Requirement engineering & Requirement tasks/Management. 1Prepared By:Jay A.Dave.
21/1/ Analysis - Model of real-world situation - What ? System Design - Overall architecture (sub-systems) Object Design - Refinement of Design.
Software Engineering Lecture 10: System Engineering.
Requirement Elicitation Review – Class 8 Functional Requirements Nonfunctional Requirements Software Requirements document Requirements Validation and.
Visual Basic.NET Comprehensive Concepts and Techniques Chapter 1 An Introduction to Visual Basic.NET and Program Design.
Requirement Specification SRS document is a contract between the development team and the customer How do we communicate the Requirements to others? Firm.
 System Requirement Specification and System Planning.
Chapter 2 Object-Oriented Paradigm Overview
SYSTEM ANALYSIS AND DESIGN
System Requirements Specification
UNIT II.
Requirement Documentation &
SOFTWARE REQUIREMENT SPECIFICATION
Requirement Analysis.
Software Reviews.
Presentation transcript:

(SRS) SOFTWARE REQUIREMENT SPECIFICATION(SRS) 1

Topics to be discussed.. What is an SRS? Purpose of an SRS Who reads the SRS? Who writes the SRS? Characteristics of an SRS Parts of SRS 2

What is an SRS? It is a document that you prepare: – After customer gives you their system specifications – before you design the system BACK 3

What is the purpose of an SRS? “ The SRS precisely defines the software product that will be built.” The SRS is your “response to the customer’s System Specification and tells a potential customer how you intend to solve their problem.” “The [SRS] specifies the requirements and the methods to be used to ensure that each requirement has been met.” 4

1.“It provides feedback to the customer.” 2.“It decomposes the problem into component parts.” 3.“It serves as an input to the design specification.” 4.“It serves as a product validation check.” BACK 5

Who reads the SRS? The purpose of an SRS is to communicate with the customer:  The SRS must make clear to the customer whether you have understood their system specification correctly and completely. SRS is written in plain language (not a formal language). 6

The purpose of an SRS is to communicate with the designers:  SRS must be detailed enough that the designers can construct a design for the system from this document. BACK 7

Who writes the SRS? Developers – Architects – Programmers Technical writers Customer may be involved BACK 8

Basis for User Manual The SRS can serve as the basis for a User Manual for the software: – Use case descriptions in SRS describe required functionality of the system, from the perspective of a user. – This can be extended to become a description of how to carry out these required tasks with the finished system. BACK 9

Characteristics of a good SRS 1.Correct 2.Unambiguous 3.Complete 4.Consistent 5.Ranked for importance and/or stability 6.Verifiable 7.Modifiable 8.Traceable BACK 10

Parts of an SRS – Purpose delineate purpose of SRS intended audience for SRS – Scope identify software to be produced by name explain what will (not) do describe application of (benefits, objectives) 11

– Definitions/acronyms/abbreviations – References list documents referenced by name and source – Overview brief description of rest of SRS organization of SRS BACK 12

THANK YOU BACK 13