1、System Requirements Specification,Specifying the Specifications,Review from last class,Requirements Engineering Tasks Inception Elicitation Elaboration - next brief topic Negotiation Specification - main topic tonight Validation Management,Modeling,What are the benefits of building a model?So, what
2、needs to be modeled?,System Modeling,Function & Information Flow Model what we will do with the data Data Model structure of the information Behavior Model how we interact with the system,Functional and Information Flow Modeling,Data Flow Diagrams,compiler,source code,object code,characters,machine
3、instructions,Syntax Analysis,characters,Semantic Analysis,tokens,yadda yadda,machine instructions,DFDs also require a Data Dictionary,Data Modeling,Data Objects, Attributes, Relationships Formatted as Lists or TablesEntity Relationship Diagrams,Behavior Modeling,State Transition Diagram,1,3,2,4,star
4、t,read msg,save msg,file name,done,compose,send,Combining Info Flow & Behavior,Use Cases,http:/ Engineering Tasks Inception Elicitation Elaboration Negotiation Specification Validation Management,Technically Speaking, “requirement“ “specification“,Requirement understanding between customer and suppl
5、ier Specification what the software must do Requirements that are not in the SRS Costs Delivery dates Acceptance procedures etc,Uses of the SRS,Design Validation Customer Contract rarely,IEEE 830,Role of SRS “The SRS must correctly define all of the software requirements, but no more.” “The SRS shou
6、ld not describe design, verification, or project management details, except for required design constraints.”,IEEE 830,Characteristics of a Good SRS Unambiguous Complete Verifiable Consistent Modifiable Traceable Usable during the Operation and Maintenance Phase,Desired SRS Characteristics,CompleteC
7、onsistentChangeableTraceable,Ambiguousness example one,The control total is taken from the last record.The total is taken from the record at the end of the file. The total is taken from the latest record. The total is taken from the previous record.,IEEE 830,Ambiguousness example two,All customers h
8、ave the same control field.All customers have the same value in their control field. All control fields have the same format. One control field is issued for all customers.,IEEE 830,Ambiguousness example three,When a user fails to authenticate after a number of times, send a notification to IT.,http
9、:/ Complete,Unclear,The system shall be able to read updates from MedImgThe system shall be able to provide historical reports,Clearer,The system shall be able to import new tumor patient data supplied by MedImg to the radiology management system, for evaluating the tumor to be malignant or benign T
10、he system shall be able to provide patient tumor data for the past five calendar years,http:/ Requirements,Through input/output specs aka IEEE 830 FormatUse of Representative ExamplesSpecification through Models,IEEE 830,SRS Table of Contents,Introduction Purpose Scope Definitions References Overvie
11、w General Description Product Perspective Product Functions User Characteristics General Constraints Assumptions and Dependencies Specific Requirements,IEEE 830,3. Specific Requirements3.1 Functional Requirements3.1.1 Func Req 13.1.1.1 Introduction3.1.1.2 Inputs3.1.1.3 Processing3.1.1.4 Outputs3.1.2
12、 Func Req 23.2 External Interface Requirements3.2.1 User Interface3.2.2 Hardware Interfaces3.2.3 Software Interfaces3.2.4 Communication Interfaces3.3 Performance Requirements3.4 Design Constraints3.4.1 Standards Compliance3.4.2 Hardware Limitations3.5 Attributes3.5.1 Security3.5.2 Maintainability3.6
13、 Other Requirements3.6.1 Database,IEEE 830,Non-830-Style Requirements,User stories encourage the team to defer collecting details. An initial place-holding goal-level story (“A Recruiter can post a new job opening“) can be written and then replaced with more detailed stories once it becomes importan
14、t to have the details. This technique makes user stories perfect for time-constrained projects. A team can very quickly write a few dozen stories to give them an overall feel for the system. They can then plunge into the details on a few of the stories and can be coding much sooner than a team that
15、feels compelled to complete an IEEE 830style software requirements specification.,Quote from “Advantages of User Stories for Requirements“ By Mike Cohn http:/ Specification Techniques,Use Cases Formal Specification Languages e.g. Petri Nets,http:/www.cs.indiana.edu/classes/p465/Lect/Images/petri-img-10.jpg,Next Classes,Agile Development Risk Analysis and Management Metrics Managing the Testing Process,
