Framework Requirements Specification .


56 views
Uploaded on:
Category: Product / Service
Description
Survey from last class. Necessities Engineering TasksInceptionElicitationElaboration - next brief topicNegotiationSpecification - fundamental theme tonightValidationManagement. Demonstrating. What are the advantages of building a model?So, what should be demonstrated?. Framework Modeling. Information Modelstructure of the informationFunction and Information Flow Modelwhat we will do with the dataBehavior Modelhow we intera
Transcripts
Slide 1

S ystem R equirements S pecification Specifying the Specifications

Slide 2

Review from last class Requirements Engineering Tasks Inception Elicitation Elaboration - next brief subject Negotiation Specification - primary theme this evening Validation Management

Slide 3

Modeling What are the advantages of building a model? All in all, what should be displayed?

Slide 4

System Modeling Function & Information Flow Model what we will do with the information Data Model structure of the data Behavior Model how we interface with the framework

Slide 5

Functional and Information Flow Modeling Data Flow Diagrams compiler source code characters machine directions question code Syntax Analysis Semantic Analysis tokens characters yadda machine guidelines DFDs likewise require a Data Dictionary

Slide 6

Data Modeling Data Objects, Attributes, Relationships Formatted as Lists or Tables Entity Relationship Diagrams screens empowers/cripples security framework sensor tests projects is customized by

Slide 7

Behavior Modeling State Transition Diagram done begin document name 1 2 3 spare msg read msg send make 4

Slide 8

Combining Info Flow & Behavior Use Cases http://www.evanetics.com/Articles/ar_usecases/uc_valueofucd.htm

Slide 9

Requirements Engineering Tasks Inception Elicitation Elaboration Negotiation Specification Validation Management

Slide 10

Technically Speaking, "requirement" ≠ "specification" Requirement – understanding amongst client and provider Specification – what the product must do Requirements that are not in the SRS Costs Delivery dates Acceptance techniques and so on

Slide 11

Uses of the SRS Design Validation Customer Contract – once in a while

Slide 12

Desired SRS Characteristics Complete Consistent Changeable Traceable

Slide 13

IEEE 830 Characteristics of a Good SRS Unambiguous Complete Verifiable Consistent Modifiable Traceable Usable amid the Operation and Maintenance Phase

Slide 14

IEEE 830 Role of SRS "The SRS should effectively characterize the greater part of the product necessities, however no more." "The SRS ought not depict plan, confirmation, or venture administration points of interest, aside from required outline imperatives."

Slide 15

Ambiguousness – case one The control aggregate is taken from the last record. The aggregate is taken from the record toward the finish of the document. The aggregate is taken from the most recent record. The aggregate is taken from the past record. IEEE 830-1984

Slide 16

Ambiguousness – illustration two All clients have a similar control field. All clients have a similar incentive in their control field. All control fields have a similar organization. One control field is issued for all clients. IEEE 830-1984

Slide 17

Expressing Requirements Through information/yield specs otherwise known as IEEE 830 Format Use of Representative Examples Specification through Models IEEE 830-1984

Slide 18

SRS Table of Contents Introduction Purpose Scope Definitions References Overview General Description Product Perspective Product Functions User Characteristics General Constraints Assumptions and Dependencies Specific Requirements IEEE 830-1984

Slide 19

3. Particular Requirements 3.1 Functional Requirements 3.1.1 Func Req 1 3.1.1.1 Introduction 3.1.1.2 Inputs 3.1.1.3 Processing 3.1.1.4 Outputs 3.1.2 Func Req 2 … 3.2 External Interface Requirements 3.2.1 User Interface 3.2.2 Hardware Interfaces 3.2.3 Software Interfaces 3.2.4 Communication Interfaces 3.3 Performance Requirements 3.4 Design Constraints 3.4.1 Standards Compliance 3.4.2 Hardware Limitations 3.5 Attributes 3.5.1 Security 3.5.2 Maintainability 3.6 Other Requirements 3.6.1 Database IEEE 830-1984

Slide 20

Non-830-Style Requirements User stories urge the group to concede gathering subtle elements. An underlying spot holding objective level story ("A Recruiter can post another employment opening") can be composed and after that supplanted with more nitty gritty stories once it gets to be distinctly essential to have the points of interest. This strategy makes client stories ideal for time-compelled ventures . A group can rapidly compose a couple of dozen stories to give them a general feel for the framework. They can then dive into the subtle elements on a couple of the stories and can code much sooner than a group that feels constrained to finish an IEEE 830–style programming necessities determination. Cite from "Advantages of User Stories for Requirements" By Mike Cohn http://www.awprofessional.com/articles/article.asp?p=342885&seqNum=3

Slide 21

Other Specification Techniques Use Cases Formal Specification Languages e.g. Petri Nets http://www.cs.indiana.edu/classes/p465/Lect/Images/petri-img-10.jpg

Slide 22

Next Classes Risk Analysis and Management Metrics Managing the Testing Process

Recommended
View more...