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
Intended audience and reading suggestions, References
Product perspective, Product features, User classes and characteristics , Operating environment
Design and implementation constraints , User documentation requirements, Assumptions and dependencies
Usage Cases (Usage Scenario)
User profiles, Use cases, Special usage considerations
Data Model and Description
Functional model and description, Description for functions
Performance requirements, Safety requirements, Security requirements, Software quality attributes
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