system

1. SSystem
RRequirements
SSpecification
Specifying the SpecificationsSpecifying the Specifications

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

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

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

5. Functional and Information
Flow Modeling
Data Flow Diagrams
compiler
source
code
object
code
characters
machine
instructions
Syntax
Analysis
characters
Semantic
Analysis
tokens
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
security
system
sensor
monitors
enables/disables
tests
programs
is programmed by

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

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

9. Requirements Engineering Tasks
1. Inception
2. Elicitation
3. Elaboration
4. Negotiation
5. Specification
6. Validation
7. 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. IEEE 830
Role of SRS
1. “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.”

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

14. Desired SRS CharacteristicsDesired SRS Characteristics
 Complete
 Consistent
 Changeable
 Traceable

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

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

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

18. 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/

19. Expressing Requirements
 Through input/output specs
 aka IEEE 830 Format
 Use of Representative Examples
 Specification through Models
IEEE 830

20. SRS Table of Contents
1. Introduction
1. Purpose
2. Scope
3. Definitions
4. References
5. Overview
2. General Description
1. Product Perspective
2. Product Functions
3. User Characteristics
4. General Constraints
5. Assumptions and Dependencies
3. Specific Requirements
IEEE 830

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

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

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

24. Next ClassesNext Classes
 Agile Development
 Risk Analysis and Management
 Metrics
 Managing the Testing Process