SSystem

RRequirements

SSpecification

Specifying the SpecificationsSpecifying the Specifications

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

ModelingModeling

What are the benefits of building a model?

So, what needs to be modeled?

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

Functional and Information Flow Modeling

Data Flow Diagrams

compilersourcecode

objectcode

characters

machineinstructions

SyntaxAnalysis

characters

SemanticAnalysis

tokens yadda yadda machineinstructions

DFDs also requirea Data Dictionary

Data Modeling

Data Objects, Attributes, Relationships Formatted as Lists or Tables

Entity Relationship Diagrams

securitysystem

sensor

monitors

enables/disables

tests

programsis programmed by

Behavior Modeling

State Transition Diagram

1 32

4

start

read msg save msg

file namedone

composesend

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. Specification6. 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 Delivery dates Acceptance procedures etc

Uses of the SRS

Design

Validation

Customer Contract – rarely

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

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 CharacteristicsDesired 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 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/

Expressing Requirements

Through input/output specs aka IEEE 830 Format

Use of Representative Examples

Specification through Models

IEEE 830

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

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

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 ClassesNext Classes

Risk Analysis and Management Metrics Managing the Testing Process