System

Requirements
Specification

Specifying the Specifications

Review 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
Modeling
What are the benefits of building a
model?

So, what 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

source characters machine object

code compiler instructions code

Syntax tokens Semantic machine

characters
Analysis Analysis yadda yadda instructions

DFDs also require

a Data Dictionary
Data Modeling
Data Objects, Attributes,
Relationships
Formatted as Lists or Tables

Entity Relationship Diagrams

monitors

enables/disables
security
tests sensor
system

programs
is programmed by
Behavior Modeling
State Transition Diagram

start done
file name

1 2 3
save msg
read msg

send
compose

4
Combining Info Flow & Behavior
Use Cases

http://www.evanetics.com/Articles/ar_usecases/uc_valueofucd.htm
Requirements Engineering Tasks
1. Inception
2. Elicitation
3. Elaboration
4. Negotiation
5. Specification
6. Validation
7. Management
Technically Speaking,
"requirement" "specification"

Requirement understanding
between customer and supplier
Specification what the software
must do
Requirements that are not in the SRS
Costs
Deliverydates
Acceptance procedures
etc
Uses of the SRS
Design
Validation
Customer Contract rarely
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.
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
Desired SRS Characteristics
Complete

Consistent

Changeable

Traceable
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
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
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
 Clear, Complete
Unclear Clearer
The system shall be The system shall be able to
able to read updates import new tumor patient
from MedImg data supplied by MedImg to
the radiology management
system, for evaluating the
tumor to be malignant or
benign
The system shall be The system shall be able to
able to provide provide patient tumor data
historical reports for the past five calendar
years

http://www.healthcareguy.com/
Expressing Requirements
Through input/output specs
aka IEEE 830 Format

Use of Representative Examples

Specification through Models

IEEE 830
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
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
 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 830style 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
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
Next Classes
Agile Development
Risk Analysis and Management
Metrics
Managing the Testing Process