Software

Software Requirements
Requirements
Specification
Specification
 Vision Document
• A Vision Document is a document
that is used to define the software
application.
• It gives us details about the
target market, the user and about
the application features.
 Vision Document
• The Vision Document describes the
application in general terms, including
description of target market, the
system users, and the application
features. The Vision Document
defines, at a high level of abstraction,
both the problem and the solution.
 Vision Document
• It is important, because it
captures the essence of the
product from all significant
perspective in a short, readable,
abstract and manageable form .
 Vision Document
• For a software product, the Vision document also
serves as the basis for discussion and agreement
among the three primary internal stakeholder
communities of the project:
• The marketing and product management team, which serves as
the proxy for the customer and the user and which will
ultimately be held accountable for the success of the product
after release
• The project team developing the application
• The management team, which will be held responsible for the
business outcome of the endeavor
 Vision Document:
Contents
Introduction :
1.1. Purpose of the vision document
1.2. Product Overview
1.3. References
User Description :
2.1. User/Market Demographics
2.2. User Profile
2.3. User Environment
2.4. User Needs
 Vision Document:
Contents
3. Product Overview :
3.1. Product Perspectives
3.2. Product Position Statement
3.3. Summary of Capabilities
3.4. Cost Pricing
4.Features Attributes
5.Product Features
5.1. Feature 1
5.2. Feature 2
 Vision Document:
Contents
6.Exemplary Use Case
7.Other Product Requirements :
7.1. Applicable Standards
7.2. System and Performance Requirement
7.3. Licensing, Security, and Installation
8. Documentation Requirements :
8.1. User Manual and help online
8.2. Installation and Guides
9. Glossary
 The Vision Document
Versions

• The Delta Vision Document

• The Vision Document For Version
1.0
• The Vision Document For Version
2.0
 Reference
• Chapter 16, The Vision Document ,
“Managing Software Requirements: A
Use case approach”
 Software Requirements
Specifications (SRS)
• I. Cover page (contents & layout)
– Name of Document
– Project Title
– Document Version Number
– Printing Date
– Location of electronic version of file
– Department & University
• II. Revisions page (contents)
– Overview
– Target Audience
– Project Team Members
– Version control history
Version Primary Author(s) Descritpion of Date completed
version

Draft / final

• Version control history

– Signatures of Approval
• III. Additional Material (contents)
– ADDITIONAL ISSUES
– DFINITIONS, ACRONYMS, AND ABBREVIATIONS
– REFERENCES
– APPENDICES
 SRS
• Cover Page
• Revisions Page
• Table of Contents

• 1 INTRODUCTION
– 1.1 Purpose
– 1.2 Scope
– 1.3 Assumptions and Dependencies
– 1.4 Overview of SRS
• 2 General Description
– 2.1 Product perspective
– 2.2 Product Functions
– 2.3 User Characteristic
– 2.4 General Constraints
 SRS

• 3 SPECIFIC REQUIREMENTS
– 3.1 Functional Requirements
• Functional Requirement1 (Introduction, Inputs, processing, output)
• Functional Requirement2 (Introduction, Inputs, processing, output)
• Functional Requirement3 (Introduction, Inputs, processing, output)
• …
– 3.2 External Interface Requirements
• 3.2.1 User Interfaces
• 3.2.2 Hardware Interfaces
• 3.2.3 Software Interfaces
• 3.2.4 Communications Protocols

REF: IEEE standards: IEEE-830

 SRS
– 3.3 Performance Requirements
– 3.4 Design Constraints
– 3.5 Quality Characteristics
• 3.5.1 Reliability
• 3.5.2 Availability
• 3.5.3 Security
• 4 Supporting Information

REF: IEEE standards: IEEE-830

 Requirement
Statement
versus Requirement
Specification
 Requirement Statement
Characteristics
• Complete - Each requirement must fully describe the
functionality to be delivered.
• Correct - Each requirement must accurately describe the
functionality to be built.
• Feasible - It must be possible to implement each requirement
within the known capabilities and limitations of the system and
its environment.
• Necessary -Each requirement should document something
that the customer really need.
• Prioritized - Assign an implementation priority to each
requirement, feature or use case to indicate how essential it is
to a particular product release.
• Unambiguous - All readers of a requirement statement
should arrive at a single, consistent interpretation of it.
• Verifiable - Examine each requirement to see whether you
can use verification approaches, such as inspection or
demonstration, to determine whether the requirement was
properly implemented.
 Requirement Specification
Characteristics
• Complete - No requirement or necessary
information should be missing.
• Consistent - Should not conflict with other
software or higher-level system or business
requirements.
• Modifiable - One must be able to revise the SRS
when necessary and maintain a history of changes
made to each requirement.
• Traceable - One should be able to link each
requirement to its origin and to the design
elements, source code, and test cases that
implement and verify the correct implementation
of the requirement.
Attributes of a Well-
Written SRS - 1
• Correct
• Unambiguous
• Complete
• Verifiable
• Consistent
• Understandable by customer
• Modifiable

19
Attributes of a Well-
Written SRS - 2
• Traced
• Traceable
• Design independent
• Annotated
• Concise
• Organized

20
 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

21
 Conclusion
• Requirements engineering and software
quality are tightly-coupled
• Requirements engineering must be
performed in a way that results in the
development of high quality software
• Requirements defects can have devastating
impact on the software project/product
• Defect prevention works better than
removal

22
 Reference
• Chapter 17, Quality Software Project
Management by Robert T. Futrell,
Donald F. Shafer, and Linda I. Shafet