|
|
| Our Process |
|
| Development Process |
|
| Feasibility Study |
|
| |
During this phase, our business analysts defines the scope of the project at hand, who the end users are, any noticeable problems and opportunities, business and technical constraints, apparent project goals, and possible solutions. The end result is a feasibility study that produces a preliminary cost-benefit analysis report. This report will enable us to determine whether significant resources should be dedicated to the other phases of this project. |
|
| Software Requirements Specifications (SRS) Creation |
|
| |
Gathering the overall total project requirements is one of the most important aspects in any software development process. All of these requirements are gathered and inserted into a document called the Software Requirements Specifications (SRS). This document will contain the functional requirements of the project and how the developers will enhance the project to achieve all the objectives. The SRS in general serves as a guide for both the client and the developers. It is used for ongoing maintenance on the project as well as the base document for generating the validation and acceptance tests.
The SRS mainly addresses the problem domain in which the product will exist. It is the first step in a project that moves it from the problem domain, to the solution domain. The basic SRS outline contains the following sections: |
|
| Introduction |
|
| |
This section is a stand-alone executive summary. It is divided into the following four sub-sections: |
|
| |
 |
Purpose: This part identifies the purpose and target audience of the SRS. |
|
|
Scope: This section identifies the products to be produced. It also explains what these |
| |
products will and will not do. |
|
|
Assumption and Dependencies: This section lists and describes the factors that affect |
| |
the requirements stated in the SRS. These factors are not design constraints on the |
| |
software. However, any changes made to them affect the requirements in the SRS. |
|
|
Overview of the SRS: This section describes the SRS and how it is organized. |
|
|
| General Description |
|
| |
This section describes the general factors that affect the product and its requirements. The following five subsections make the requirements easier to understand. |
|
| |
|
Product Perspective: It relates the product to other projects, or products. A block |
| |
diagram showing the major components of the larger system or project, interconnections, and external interfaces is used as an effective explanatory tool |
|
|
Product Functions: It summarizes the functions of the product. The functions are |
| |
organized in a manner that makes the list of functions understandable to the customer, or to anyone else reading the document for the first time. Block diagrams showing different functions and their relationships, are used as an effective explanatory tool. |
|
|
User Characteristics: List the general characteristics of the users that will affect the |
| |
specific requirements. Characteristics such as education level, experience, and technical expertise impose constraints on the systems' operating environment. |
|
|
General Constraints: Provide a general description of the other items that limit the |
| |
developer's options for designing the system. These may include regulatory policies, hardware limitations, interface to the other applications etc. |
|
|
| Specific Requirements |
|
| |
This section contains all the details that a software developer needs to create a design. This is the largest and the most important part of the SRS. In this section, details are defined as individual specific requirements. Specific requirements are organized in the following subsections: |
|
| |
|
Functional Requirements: This subsection specifies what the input and output should |
| |
be, and what operations are required. |
|
|
External Interface Requirements: This subsection of SRS contains all the information |
| |
products will and will not do. adequately develop the interfaces to entities outside of the software specified. Specific interfaces to hardware, other software applications, and communication systems are specified in this subsection |
|
|
Performance Requirements: This subsection should specify the static and dynamic |
| |
numerical requirements placed on the software, or on human interaction with the software as whole. Static numerical requirements may include a number of terminals to be supported, a number of concurrent users etc. Dynamic numerical requirements may include a number of transactions and tasks, as well as the amount of data to be processed within certain time periods for both normal, and peak workload conditions. |
|
|
| Supporting Information |
| |
The supporting information adds to the completeness of the SRS. |
|
| |
|
Definitions Abbreviations and Acronyms: This section provides the definitions of all |
| |
terms, acronyms, and abbreviations required to interpret the SRS correctly. |
|
|
References: This section provides the complete list of documents referenced elsewhere |
| |
in the SRS. |
|
|
| |
|
|
|
|
|
|
|
