1 / 22

S ystem R equirements S pecification

S ystem R equirements S pecification. Specifying the Specifications. Review from last class. Requirements Engineering Tasks Inception Elicitation Elaboration - next brief topic Negotiation Specification - main topic tonight Validation Management. Modeling.

jag
Télécharger la présentation

S ystem R equirements S pecification

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. System RequirementsSpecification Specifying the Specifications

  2. Review from last class Requirements Engineering Tasks • Inception • Elicitation • Elaboration - next brief topic • Negotiation • Specification - main topic tonight • Validation • Management

  3. Modeling • What are the benefits of building a model? • So, what needs to be modeled?

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

  5. Functional and Information Flow Modeling Data Flow Diagrams compiler source code characters machine instructions object code Syntax Analysis Semantic Analysis tokens characters yadda yadda machine instructions DFDs also require a Data Dictionary

  6. Data Modeling • Data Objects, Attributes, Relationships • Formatted as Lists or Tables • Entity Relationship Diagrams monitors enables/disables security system sensor tests programs is programmed by

  7. Behavior Modeling State Transition Diagram done start file name 1 2 3 save msg read msg send compose 4

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

  9. Requirements Engineering Tasks • Inception • Elicitation • Elaboration • Negotiation • Specification • Validation • Management

  10. Technically Speaking,"requirement" ≠ "specification" • Requirement – understanding between customer and supplier • Specification – what the software must do • Requirements that are not in the SRS • Costs • Delivery dates • Acceptance procedures • etc

  11. Uses of the SRS • Design • Validation • Customer Contract – rarely

  12. Desired SRS Characteristics • Complete • Consistent • Changeable • Traceable

  13. IEEE 830 Characteristics of a Good SRS • Unambiguous • Complete • Verifiable • Consistent • Modifiable • Traceable • Usable during the Operation and Maintenance Phase

  14. IEEE 830 Role of SRS • “The SRS must correctly define all of the software requirements, but no more.” • “The SRS should not describe design, verification, or project management details, except for required design constraints.”

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

  16. Ambiguousness – example two All customers have 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-1984

  17. Expressing Requirements • Through input/output specs • aka IEEE 830 Format • Use of Representative Examples • Specification through Models IEEE 830-1984

  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

  19. 3. Specific 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

  20. 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 important 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 feels compelled to complete an IEEE 830–style software requirements specification. Quote from "Advantages of User Stories for Requirements" By Mike Cohn http://www.awprofessional.com/articles/article.asp?p=342885&seqNum=3

  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

  22. Next Classes • Risk Analysis and Management • Metrics • Managing the Testing Process

More Related