11 req specs
-
Upload
najam-uddin -
Category
Devices & Hardware
-
view
51 -
download
1
Transcript of 11 req specs
![Page 1: 11 req specs](https://reader033.fdocuments.us/reader033/viewer/2022051301/5a6d49507f8b9a0a428b5277/html5/thumbnails/1.jpg)
SSystem
RRequirements
SSpecification
Specifying the SpecificationsSpecifying the Specifications
![Page 2: 11 req specs](https://reader033.fdocuments.us/reader033/viewer/2022051301/5a6d49507f8b9a0a428b5277/html5/thumbnails/2.jpg)
Review from last classReview from last class
Requirements Engineering Tasks
1. Inception
2. Elicitation
3. Elaboration - next brief topic
4. Negotiation
5. Specification - main topic tonight
6. Validation
7. Management
![Page 3: 11 req specs](https://reader033.fdocuments.us/reader033/viewer/2022051301/5a6d49507f8b9a0a428b5277/html5/thumbnails/3.jpg)
ModelingModeling
What are the benefits of building a model?
So, what needs to be modeled?
![Page 4: 11 req specs](https://reader033.fdocuments.us/reader033/viewer/2022051301/5a6d49507f8b9a0a428b5277/html5/thumbnails/4.jpg)
System ModelingSystem 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
![Page 5: 11 req specs](https://reader033.fdocuments.us/reader033/viewer/2022051301/5a6d49507f8b9a0a428b5277/html5/thumbnails/5.jpg)
Functional and Information Flow Modeling
Data Flow Diagrams
compilersourcecode
objectcode
characters
machineinstructions
SyntaxAnalysis
characters
SemanticAnalysis
tokens yadda yadda machineinstructions
DFDs also requirea Data Dictionary
![Page 6: 11 req specs](https://reader033.fdocuments.us/reader033/viewer/2022051301/5a6d49507f8b9a0a428b5277/html5/thumbnails/6.jpg)
Data Modeling
Data Objects, Attributes, Relationships Formatted as Lists or Tables
Entity Relationship Diagrams
securitysystem sensor
monitors
enables/disables
tests
programsis programmed by
![Page 7: 11 req specs](https://reader033.fdocuments.us/reader033/viewer/2022051301/5a6d49507f8b9a0a428b5277/html5/thumbnails/7.jpg)
Behavior Modeling
State Transition Diagram
1 32
4
start
read msg save msg
file namedone
composesend
![Page 8: 11 req specs](https://reader033.fdocuments.us/reader033/viewer/2022051301/5a6d49507f8b9a0a428b5277/html5/thumbnails/8.jpg)
Combining Info Flow & Behavior
Use Cases
http://www.evanetics.com/Articles/ar_usecases/uc_valueofucd.htm
![Page 9: 11 req specs](https://reader033.fdocuments.us/reader033/viewer/2022051301/5a6d49507f8b9a0a428b5277/html5/thumbnails/9.jpg)
Requirements Engineering Tasks
1. Inception
2. Elicitation
3. Elaboration
4. Negotiation
5. Specification6. Validation
7. Management
![Page 10: 11 req specs](https://reader033.fdocuments.us/reader033/viewer/2022051301/5a6d49507f8b9a0a428b5277/html5/thumbnails/10.jpg)
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
![Page 11: 11 req specs](https://reader033.fdocuments.us/reader033/viewer/2022051301/5a6d49507f8b9a0a428b5277/html5/thumbnails/11.jpg)
Uses of the SRS
Design
Validation
Customer Contract – rarely
![Page 12: 11 req specs](https://reader033.fdocuments.us/reader033/viewer/2022051301/5a6d49507f8b9a0a428b5277/html5/thumbnails/12.jpg)
IEEE 830
Role of SRS1. “The SRS must correctly define all
of the software requirements, but no more.”
2. “The SRS should not describe design, verification, or project management details, except for required design constraints.”
![Page 13: 11 req specs](https://reader033.fdocuments.us/reader033/viewer/2022051301/5a6d49507f8b9a0a428b5277/html5/thumbnails/13.jpg)
IEEE 830
Characteristics of a Good SRS
1. Unambiguous
2. Complete
3. Verifiable
4. Consistent
5. Modifiable
6. Traceable
7. Usable during the Operation and Maintenance Phase
![Page 14: 11 req specs](https://reader033.fdocuments.us/reader033/viewer/2022051301/5a6d49507f8b9a0a428b5277/html5/thumbnails/14.jpg)
Desired SRS CharacteristicsDesired SRS Characteristics
Complete
Consistent
Changeable
Traceable
![Page 15: 11 req specs](https://reader033.fdocuments.us/reader033/viewer/2022051301/5a6d49507f8b9a0a428b5277/html5/thumbnails/15.jpg)
Ambiguousness – example one
The control total is taken from the last record.
1. The total is taken from the record at the end of the file.
2. The total is taken from the latest record.
3. The total is taken from the previous record.
IEEE 830
![Page 16: 11 req specs](https://reader033.fdocuments.us/reader033/viewer/2022051301/5a6d49507f8b9a0a428b5277/html5/thumbnails/16.jpg)
Ambiguousness – example two
All customers have the same control field.
1. All customers have the same value in their control field.
2. All control fields have the same format.
3. One control field is issued for all customers.
IEEE 830
![Page 17: 11 req specs](https://reader033.fdocuments.us/reader033/viewer/2022051301/5a6d49507f8b9a0a428b5277/html5/thumbnails/17.jpg)
Ambiguousness – example three
When a user fails to authenticate after a number of times, send a notification to IT.
http://stackoverflow.com/questions/626737/how-do-you-resolve-ambiguities-in-specification
![Page 18: 11 req specs](https://reader033.fdocuments.us/reader033/viewer/2022051301/5a6d49507f8b9a0a428b5277/html5/thumbnails/18.jpg)
Clear, Complete
Unclear The system shall be
able to read updates from MedImg
The 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
The system shall be able to provide patient tumor data for the past five calendar years
http://www.healthcareguy.com/
![Page 19: 11 req specs](https://reader033.fdocuments.us/reader033/viewer/2022051301/5a6d49507f8b9a0a428b5277/html5/thumbnails/19.jpg)
Expressing Requirements
Through input/output specs aka IEEE 830 Format
Use of Representative Examples
Specification through Models
IEEE 830
![Page 20: 11 req specs](https://reader033.fdocuments.us/reader033/viewer/2022051301/5a6d49507f8b9a0a428b5277/html5/thumbnails/20.jpg)
SRS Table of Contents
1. Introduction1. Purpose2. Scope3. Definitions4. References5. Overview
2. General Description1. Product Perspective2. Product Functions3. User Characteristics4. General Constraints5. Assumptions and Dependencies
3. Specific RequirementsIEEE 830
![Page 21: 11 req specs](https://reader033.fdocuments.us/reader033/viewer/2022051301/5a6d49507f8b9a0a428b5277/html5/thumbnails/21.jpg)
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
![Page 22: 11 req specs](https://reader033.fdocuments.us/reader033/viewer/2022051301/5a6d49507f8b9a0a428b5277/html5/thumbnails/22.jpg)
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
![Page 23: 11 req specs](https://reader033.fdocuments.us/reader033/viewer/2022051301/5a6d49507f8b9a0a428b5277/html5/thumbnails/23.jpg)
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
![Page 24: 11 req specs](https://reader033.fdocuments.us/reader033/viewer/2022051301/5a6d49507f8b9a0a428b5277/html5/thumbnails/24.jpg)
Next ClassesNext Classes
Agile Development Risk Analysis and Management Metrics Managing the Testing Process