Fred Mod 2-4c ProducingQualitySRS

8/2/2019 Fred Mod 2-4c ProducingQualitySRS

1/24

PRODUCING

QUALITYSRS

Presented By: Fredrick J Menezes

ME -11-08


2/24

Locating Ourselves

MODULE 2

4.Managing Production

4.1.Scheduling the work

4.2.Eliciting Requirements

4.3.Producing Quality SRS

4.4.Identifying & dealing with risks

2PCCE: Producing Quality SRS

Fredrick Januario MenezesFebruary 2012


3/24

sssssss

3

PCCE: Producing Quality SRS

Fredrick Januario Menezes

February 2012


4/24

Competencies Addressed

Product Development Techniques

5.Managing Requirements.

Product Management Skills 13. Documenting Plans.

15. Estimating Effort.

People Management Skills 25. Holding Effective Meetings

31. Presenting Effectively




5/24

Coverage

Understanding the SRS for s/w project

Evaluate an SRS w.r.t. critical quality factors.

Plan and estimate the task of developing an SRS

during the requirements phase of a project.

Lay the groundwork for acceptance and

validation testing.




6/24

Understanding THE SRS

ATM > DATA(PIN) > PROCESS (VALIDATION)

> BEHAVIOR (STATES THE SYSTEM ASSUMES)

6

PROCES

S

DATA

BEHAVIO

R

PROBLE

M

DOMAIN

PCCE: Producing Quality SRS



7/24

BENEFITS OF AN SRS

Specification process that is unambiguous

Baseline for agreement between the customers and thesuppliers.

Reduces development effort.Points out omissions, misunderstandings and

inconsistencies early.

Estimating costs and schedules.

Helps in developing validation and verification plans.Facilitates portability.

Basis for enhancement.




8/24

building the srs

Title Page

Table of contents

1. Intro 1.1 Purpose

1.2 Scope

1.3 Assumptions and Dependencies 1.4 Overview of the SRS




9/24

building the srs

2. The General Description

2.1 Product Perspective 2.2 Product Functions

2.3 User Characteristics

2.4 General Constraints




10/24

building the srs

3. Specific Requirements

3.1 Functional Requirements

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




11/24

building the srs

3.3 Performance Requirements

3.4 Design Constraints

3.4.1 Standard Compliance

3.4.2 Hardware Limitations

3.5 Quality Characteristics

3.5.1 Efficiency

3.5.2 Usability




12/24

building the srs

3.6 Other Requirements

3.6.1 Database 3.6.2 Operations

3.6.3 Site Adaptation Requirements




13/24

building the srs

4. Supporting Information

4.1 Definitions, Acronyms, and Abbreviations 4.2 References

4.3 Appendices

4.4 Index




14/24

Evaluating the Project SRS

Correctness

Unambiguous

Completeness

Consistency

Stability

Verifiability

Modifiability

Traceability




15/24

Correctness

Requirement stated therein is one that the

software shall meet.

Can be compared to a higher level document,

like System Requirement Specification.

User can determine.

15PCCE: Producing Quality SRSFredrick Januario Menezes

February 2012


16/24

Unambiguous

Every requirement stated therein has only oneinterpretation.

Polysemy: one word many meanings (Eg. Have)

Synonymy: many words same meaning(Eg. Car/automobile)

Avoid ambiguity:

Natural Language Pitfalls Requirements Specification Language

Representation Tools


February 2012


17/24

Completeness

All significant requirements

Functionality

Performance

Design Constraints

Attributes

External Interfaces


February 2012


18/24

CORRECTNESS

Full labels and references to all figures.

No To Be Determined labels

If present then should be followed by a

description.

Also what must be done to eliminate the TBD

label.


February 2012


19/24

CONSISTENCY

Consistent if no subset of individual

requirements described in it conflicts.

Conflict among specified characteristics of real

world objects.

Logical or temporal conflicts between two

specified actions

Same function different name ( Eg. Pin, Password)


February 2012


20/24

VERIFIABILITY

The statements made must be definite.

Well, Good , Usually not acceptable for

verifiability.


February 2012


21/24

MODIFIABILITY

Depends on whether the SRS is easily

changeable.

Coherent organization, explicit cross referencing.

Not be redundant.

Express each requirement seperately.

Redundancy can lead to errors.


February 2012


22/24

TRACEABILITY

Origin of the requirements must be clear

Backward Traceability (Previous stages of dev.)

Forward Traceability (Docs. Spawned by the SRS)


February 2012


23/24

QUESTIONS ASKED

What are the perspectives needed to make

SRS? How do they help improving the quality

of the SRS?

The project manager must constantly be

aware of the quality characteristics, Justify.

Why is the evolution of these characteristics a

continuous process?


February 2012


24/24

24

THANK YOU !!!!

Fred Mod 2-4c ProducingQualitySRS

Documents

Transcript of Fred Mod 2-4c ProducingQualitySRS