QUALITY ATTRIBUTES OF
REQUIREMENTS DOCUMENTS
LECTURE NO-19
1
SPECIFYING REQUIREMENTS
• Requirements are specified in a document called software
requirements specifications (SRS)
• SRS is used for communication among customers, analysts,
and designers
• Supports system-testing activities
• Controls the evolution of the system
2
VALIDATION OBJECTIVES
• Certifies that the requirements
document is an acceptable description
of the system to be implemented
• Checks a requirements document for
• Completeness and consistency
• Conformance to standards
• Requirements conflicts
• Technical errors
• Ambiguous requirements
3
WHAT SHOULD BE INCLUDED IN
SRS?
• Functional requirements
• They define what the system does. These describe all
the inputs and outputs to and from the system as well as
information concerning how the inputs and outputs
interrelate.
4
WHAT SHOULD BE INCLUDED IN
SRS?
• Non-functional requirements
• They define the attributes of a system as it performs
its job. They include system’s required levels of
efficiency, reliability, security, maintainability, portability,
visibility, capacity, and standards compliance
• Some of these are quality attributes of a software
product
5
WHAT SHOULD NOT BE
INCLUDED IN SRS?
• Project requirements (for example,
staffing, schedules, costs, milestones,
activities, phases, reporting procedures)
• Designs
• Product assurance plans (for example,
configuration management plans,
verification and validation plans, test
plans, quality assurance plans)
6
SRS QUALITY ATTRIBUTES - 1
• Correct
• Complete
• Verifiable
• Consistent
7
SRS QUALITY ATTRIBUTES - 2
•Understandable by customer
•Modifiable
• Traced
• Traceable
• Design independent
8
SRS QUALITY ATTRIBUTES - 3
• Annotated
• Concise
• Organized
9
CORRECT
• An SRS is correct if and only if every requirement stated
therein represents something required of the system to be
built
10
COMPLETE - 1
•An SRS is complete if it
possesses the following four
qualities
• Everything that the software is supposed to do is included in
the SRS
• Definitions of the responses of the software.
11
COMPLETE - 2
• All pages are numbered; all figures and tables are
numbered, named, and referenced; all terms and units
of measure are provided; and all referenced material
and sections are present
• No sections are marked
“To Be Determined” (TBD)
12
VERIFIABLE
• An SRS is verifiable if every requirement stated
therein is verifiable. A requirement is verifiable if
and only if there exists some finite cost-effective
process with which a person or machine can check
that the actual as-built software product meets the
requirement.
13
CONSISTENT - 1
• An SRS is consistent if and only if:
• No requirement stated therein conflicts with
other preceding documents, such as
specifications or a statement of work.
14
CONSISTENT - 2
• Conflicts can be any of the following
• Conflicting behavior
• Conflicting terms
• Conflicting characteristics
15
UNDERSTANDABLE BY
CUSTOMERS
• Primary readers of SRS in many cases are customers or
users, who tend to be experts in an application area but are
not necessarily trained in computer science
16
MODIFIABLE
• An SRS is modifiable if its structure and
style are such that any necessary
changes to the requirements can be
made easily, completely, and consistently
• Existence of index, table of contents,
cross-referencing, and appropriate
page-numbering
• This attribute deals with format and
style of SRS
17
TRACED
• An SRS is traced if the origin of its requirements is clear.
That means that the SRS includes references to earlier
supportive documents
18
TRACEABLE
• An SRS is traceable if it is written in a manner that
facilitates the referencing of each individual requirement
stated therein
19
TECHNIQUES FOR TRACEABILITY
• Number every paragraph hierarchically and
never include more than one requirement
in any paragraph
• Assign every requirement a unique number
as we have discussed this earlier
• Use a convention for indicating a
requirement, e.g., use shall statement
20
TRACED AND TRACEABILITY - 1
• Backward-from-requirements traceability implies that we
know why every requirement in the SRS exists
• Forward-from-requirements traceability implies that we
understand which components of the software satisfy each
requirement
21
DESIGN INDEPENDENT
• An SRS is design independent if it does not imply a specific
software architecture or algorithm
• Sometimes, it is not possible to have no design information
due to constraints imposed by the customers or external
factors
22
ANNOTATED
• The purpose of annotating requirements contained in an
SRS is to provide guidance to the development organization
• Relative necessity
• Relative stability
23
CONCISE
• The SRS that is shorter is better, given that it meets all
characteristics
24
ORGANIZED
• An SRS is organized if requirements contained therein are
easy to locate. This implies that requirements are arranged
so that requirements that are related are co-related
25
PHRASES TO LOOK FOR IN AN SRS
- 1
• Always, Every,All, None, Never
• Certainly,Therefore, Clearly, Obviously, Evidently
• Some, Sometimes, Often, Usually, Ordinarily, Customarily,
Most, Mostly
• Etc.,And So Forth,And So On, Such As
26
PHRASES TO LOOK FOR IN AN SRS
- 2
• Good, Fast, Cheap, Efficient, Small, Stable
• Handled, Processed, Rejected, Skipped, Eliminated
• If…Then…(but missing Else)
27
THE BALANCING ACT
• Achieving all the preceding attributes in an SRS is
impossible
• Once you become involved in writing an SRS, you will gain
insight and experience necessary to do the balancing act
• There is no such thing as a perfect SRS
28
REFERENCES
• ‘Requirements Engineering: Processes
and Techniques’ by G. Kotonya and I.
Sommerville, John Wiley & Sons, 1998
• ‘Software Requirements: Objects,
Functions, and States’ by A. Davis, PH,
1993
• ‘SoftwareTesting’ by R. Patton,
Techmedia, 2000
29

Lecture No-19.ppt lecture number 19 ppt .

  • 1.
    QUALITY ATTRIBUTES OF REQUIREMENTSDOCUMENTS LECTURE NO-19 1
  • 2.
    SPECIFYING REQUIREMENTS • Requirementsare specified in a document called software requirements specifications (SRS) • SRS is used for communication among customers, analysts, and designers • Supports system-testing activities • Controls the evolution of the system 2
  • 3.
    VALIDATION OBJECTIVES • Certifiesthat the requirements document is an acceptable description of the system to be implemented • Checks a requirements document for • Completeness and consistency • Conformance to standards • Requirements conflicts • Technical errors • Ambiguous requirements 3
  • 4.
    WHAT SHOULD BEINCLUDED IN SRS? • Functional requirements • They define what the system does. These describe all the inputs and outputs to and from the system as well as information concerning how the inputs and outputs interrelate. 4
  • 5.
    WHAT SHOULD BEINCLUDED IN SRS? • Non-functional requirements • They define the attributes of a system as it performs its job. They include system’s required levels of efficiency, reliability, security, maintainability, portability, visibility, capacity, and standards compliance • Some of these are quality attributes of a software product 5
  • 6.
    WHAT SHOULD NOTBE INCLUDED IN SRS? • Project requirements (for example, staffing, schedules, costs, milestones, activities, phases, reporting procedures) • Designs • Product assurance plans (for example, configuration management plans, verification and validation plans, test plans, quality assurance plans) 6
  • 7.
    SRS QUALITY ATTRIBUTES- 1 • Correct • Complete • Verifiable • Consistent 7
  • 8.
    SRS QUALITY ATTRIBUTES- 2 •Understandable by customer •Modifiable • Traced • Traceable • Design independent 8
  • 9.
    SRS QUALITY ATTRIBUTES- 3 • Annotated • Concise • Organized 9
  • 10.
    CORRECT • An SRSis correct if and only if every requirement stated therein represents something required of the system to be built 10
  • 11.
    COMPLETE - 1 •AnSRS is complete if it possesses the following four qualities • Everything that the software is supposed to do is included in the SRS • Definitions of the responses of the software. 11
  • 12.
    COMPLETE - 2 •All pages are numbered; all figures and tables are numbered, named, and referenced; all terms and units of measure are provided; and all referenced material and sections are present • No sections are marked “To Be Determined” (TBD) 12
  • 13.
    VERIFIABLE • An SRSis verifiable if every requirement stated therein is verifiable. A requirement is verifiable if and only if there exists some finite cost-effective process with which a person or machine can check that the actual as-built software product meets the requirement. 13
  • 14.
    CONSISTENT - 1 •An SRS is consistent if and only if: • No requirement stated therein conflicts with other preceding documents, such as specifications or a statement of work. 14
  • 15.
    CONSISTENT - 2 •Conflicts can be any of the following • Conflicting behavior • Conflicting terms • Conflicting characteristics 15
  • 16.
    UNDERSTANDABLE BY CUSTOMERS • Primaryreaders of SRS in many cases are customers or users, who tend to be experts in an application area but are not necessarily trained in computer science 16
  • 17.
    MODIFIABLE • An SRSis modifiable if its structure and style are such that any necessary changes to the requirements can be made easily, completely, and consistently • Existence of index, table of contents, cross-referencing, and appropriate page-numbering • This attribute deals with format and style of SRS 17
  • 18.
    TRACED • An SRSis traced if the origin of its requirements is clear. That means that the SRS includes references to earlier supportive documents 18
  • 19.
    TRACEABLE • An SRSis traceable if it is written in a manner that facilitates the referencing of each individual requirement stated therein 19
  • 20.
    TECHNIQUES FOR TRACEABILITY •Number every paragraph hierarchically and never include more than one requirement in any paragraph • Assign every requirement a unique number as we have discussed this earlier • Use a convention for indicating a requirement, e.g., use shall statement 20
  • 21.
    TRACED AND TRACEABILITY- 1 • Backward-from-requirements traceability implies that we know why every requirement in the SRS exists • Forward-from-requirements traceability implies that we understand which components of the software satisfy each requirement 21
  • 22.
    DESIGN INDEPENDENT • AnSRS is design independent if it does not imply a specific software architecture or algorithm • Sometimes, it is not possible to have no design information due to constraints imposed by the customers or external factors 22
  • 23.
    ANNOTATED • The purposeof annotating requirements contained in an SRS is to provide guidance to the development organization • Relative necessity • Relative stability 23
  • 24.
    CONCISE • The SRSthat is shorter is better, given that it meets all characteristics 24
  • 25.
    ORGANIZED • An SRSis organized if requirements contained therein are easy to locate. This implies that requirements are arranged so that requirements that are related are co-related 25
  • 26.
    PHRASES TO LOOKFOR IN AN SRS - 1 • Always, Every,All, None, Never • Certainly,Therefore, Clearly, Obviously, Evidently • Some, Sometimes, Often, Usually, Ordinarily, Customarily, Most, Mostly • Etc.,And So Forth,And So On, Such As 26
  • 27.
    PHRASES TO LOOKFOR IN AN SRS - 2 • Good, Fast, Cheap, Efficient, Small, Stable • Handled, Processed, Rejected, Skipped, Eliminated • If…Then…(but missing Else) 27
  • 28.
    THE BALANCING ACT •Achieving all the preceding attributes in an SRS is impossible • Once you become involved in writing an SRS, you will gain insight and experience necessary to do the balancing act • There is no such thing as a perfect SRS 28
  • 29.
    REFERENCES • ‘Requirements Engineering:Processes and Techniques’ by G. Kotonya and I. Sommerville, John Wiley & Sons, 1998 • ‘Software Requirements: Objects, Functions, and States’ by A. Davis, PH, 1993 • ‘SoftwareTesting’ by R. Patton, Techmedia, 2000 29