Software Requirement Specifications

Started by TechShristi, June 30, 2013, 11:05:25 am

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.


1. Software Requirement Specifications

A Software requirements specification (SRS), a requirements specification for a software system, is a complete description of the behavior of a system to be developed.
         A business analyst (BA), sometimes titled system analyst (SA), is responsible for analyzing the business needs of their clients and stakeholders to help identify business problems and propose solutions. Within the systems development life cycle domain, the BA typically performs a liaison function between the business side of an enterprise and the information technology department or external service providers.
The software requirements specification document enlists all necessary requirements that are required for the project development. To derive the requirements we need to have clear and thorough understanding of the products to be developed. This is prepared after detailed communications with the project team and customer.
The System Requirements Specification (SRS) document describes all data, functional and behavioral requirements of the software under production or development.
This 10-section template covers the overall description of the system/software to be implemented, use cases and scenarios, data model, functional and non-functional requirements, interface and behavioral models, as well as restrictions and validation criteria to be used for the software. The Appendices may include business rules, glossary, traceability matrices and other necessary supplementary information that are specific to the system.
A example organization of an SRS is as follows:
Table of Contents
System Requirements Specification (SRS) , Using this Document - Business Benefits
Goals and objectives, Statement of scope , Software context , Major constraints

Document Conventions
Intended audience and reading suggestions, References

Overall Description
Product perspective, Product features, User classes and characteristics , Operating environment
Design and implementation constraints , User documentation requirements, Assumptions and dependencies
System requirements

Usage Cases (Usage Scenario)
User profiles, Use cases, Special usage considerations
Data Model and Description
Data description
Functional Requirements 
Functional model and description, Description for functions
Non-functional Requirements
Performance requirements, Safety requirements, Security requirements, Software quality attributes
Other requirements
Interface Requirements
External machine interfaces, Hardware Interfaces, Communications interfaces , Control flow description
Behavioral Model and Description
Description for software behavior, State transition diagrams, Control specification (CSPEC)

        Restrictions, Limitations, and Constraints Validation Criteria
Classes of tests , Expected software response, Performance bounds

Glossary, Business rules, System traceability matrix, Analysis models and metrics
Product strategies , Issues list , Supplementary information (as required) , Crosscheck

2. Feasibility Analysis

A feasibility study, also known as feasibility analysis, is an analysis of the viability of an idea. It describes a preliminary study undertaken to determine and document a project's viability. The results of this analysis are used in making the decision whether to proceed with the project or not. The types of project feasibility factors are economic, technical, operational, schedule, legal and contractual, and political.

Economic feasibility is the process of identifying the financial benefits and costs associated with a development project.
Technical feasibility is the process of assessing the development organization's ability to construct a proposed system.
Operational feasibility is the process of assessing the degree to which a proposed system solves business problems or takes advantage of business opportunities.
Schedule feasibility is the process of assessing the degree to which the potential time frame and completion dates for all major activities within a project meet organizational deadlines and constraints for affecting change.
Legal and contractual feasibility is the process of assessing potential legal and contractual ramifications due to the construction of a system.
Political feasibility is the process of evaluating how key stakeholders within the organization view the proposed system



Hello admin123,  June 30, 2013, 11:05 am

Welcome to Techshristi Forum

In case if you find any link not working or any Abnormal activity then contact us at
[email protected]




Quick Reply

With Quick-Reply you can write a post when viewing a topic without loading a new page. You can still use bulletin board code and smileys as you would in a normal post.

Warning: this topic has not been posted in for at least 120 days.
Unless you're sure you want to reply, please consider starting a new topic.

Note: this post will not display until it's been approved by a moderator.

Please leave this box empty:
Type the letters shown in the picture
Listen to the letters / Request another image

Type the letters shown in the picture:

Shortcuts: ALT+S save/post or ALT+P preview