Leture-w2-1

Leture-w2-1 - SE 210: Software Specification and Design I...

Info iconThis preview shows pages 1–10. Sign up to view the full content.

View Full Document Right Arrow Icon
SE 210: Software Specification and Design I Yuan An, Ph.D. yuan.an@ischool.drexel.edu Fall 2007 Lecture 4  on Oct. 1, 2007
Background image of page 1

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
2 Last Week Software Requirements High Cost of Requirement Errors Managing Requirements Software Development Process Model Five Steps in Problem Analysis Today: IEEE Std 830-1998 Introduction to UML
Background image of page 2
3 Software Requirements Specification (SRS) How do we communicate the requirements to others? Purpose of SRS: Communicate an understanding of the requirements: agreement between the customers and the suppliers on what the  software product is to do. Explanation about the application domain and the system to be  developed.
Background image of page 3

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
4 SRS Purpose of SRS: contractual May be legally binding Provide a baseline for testing, validation and verification Facilitate transfer Server as a basis for supporting requirements change and  software enhancement.
Background image of page 4
5 SRS: Audience Customers, users, purchasers Systems analysts, requirements analysts Software developers, programmers Have to implement the requirements Testers Determine that the requirements have been met Project managers Measure and control the development processes.
Background image of page 5

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
6 No Perfect SRS a m b ig uo us inc o ns is te nt re dunda nt No t unde rs ta nda b le inc o m ple te e xpa nd c o nde ns e fo rm a lize re s o lve re duc e Add e xpla na tio n
Background image of page 6
7 Nature of the SRS Functionality What is the software supposed to do? External interfaces How does the software interact with people, the system’s hardware, other  hardware, and other software? Performance What is the speed, availability, response time, recovery time of various software  functions? Attributes What are the portability, correctness, maintainability, security, etc.  considerations? Design constraints imposed on an implementation Are there any required standards in effect, implementation language, policies for  database integrity, resource limits, operating environments?
Background image of page 7

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
8 Characteristics of Good SRS 1 Correct An SRS is correct if, and only if, every requirement stated therein is one  that the software shall meet Customer’s determination or comply with superior specifications. Unambiguous Every requirement stated has only one interpretation. Using glossary  Formal languages (SE 211)
Background image of page 8
9 Characteristics of Good SRS 2 Complete It includes all significant requirements; responses to all classes  of input; doesn’t have TBDs.
Background image of page 9

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
Image of page 10
This is the end of the preview. Sign up to access the rest of the document.

Page1 / 33

Leture-w2-1 - SE 210: Software Specification and Design I...

This preview shows document pages 1 - 10. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online