Software Requirements Specification
An SRS is basically an organization's understanding (in writing) of a
customer or potential client's system requirements and dependencies
at a particular point in time (usually) prior to any actual design or
development work . It's a two-way insurance policy that assures that
both the client and the organization understand the other's
requirements from that perspective at a given point in time .
The SRS document itself states in precise and explicit language those
functions and capabilities a software system (i.e., a software
application, an eCommerce Web site , and so on) must provide , as well
as states any required constraints by which the system must abide . The
SRS also functions as a blueprint for completing a project with as little
cost growth as possible .
The SRS is often referred to as the "parent" document because all
subsequent project management documents , such as design
specifications , statements of work , software architecture,
specifications , testing and validation plans , and documentation plans ,
are related to it .
It's important to note that an SRS contains functional and nonfunctional
requirements only ; it doesn't offer design suggestions , possible
solutions to technology or business issues , or any other information
other than what the development team understands the customer's
system requirements to be .
A well-designed, well-written SRS accomplishes four major
goals:
* It provides feedback to the customer. An SRS is the
customer's assurance that the development organization
understands the issues or problems to be solved and the
software behavior necessary to address those problems.
Therefore, the SRS should be written in natural language
(versus a formal language, explained later in this
article), in an unambiguous manner that may also include
charts, tables, data flow diagrams, decision tables, and so
on.
* It decomposes the problem into component parts. The
simple act of writing down software requirements in a
well-designed format organizes information, places borders
around the problem, solidifies ideas, and helps break down
the problem into its component parts in an orderly
fashion.
* It serves as an input to the design specification. As
mentioned previously, the SRS serves as the parent document
to subsequent documents, such as the software design
specification and statement of work. Therefore, the SRS
must contain sufficient detail in the functional system
requirements so that a design solution can be devised.
* It serves as a product validation check. The SRS also
serves as the parent document for testing and validation
strategies that will be applied to the requirements for
verification.
SRSs are typically developed during the first stages of
"Requirements Development," which is the initial product
development phase in which information is gathered about what
requirements are needed--and not. This information-gathering
stage can include onsite visits, questionnaires, surveys,
interviews, and perhaps a return-on-investment (ROI) analysis
or needs analysis of the customer or client's current business
environment. The actual specification, then, is written after
the requirements have been gathered and analyzed.
System Feasibility
It can be divided into following sections :
1. Economic Feasibility
This project is economically feasible as the entities involved in the
computer are with the minimum requirements mentioned earlier.
2. Technical Feasibility
To deploy the application , the only technical aspects needed are
mentioned below :
Operating Environment Win 2000/XP
Platform .Net Framework & IIS
Database SQL Server 2005
3. Behavioural Feasibility
The application requires no special technical guidance and all the
views available in the application are self explanatory . The users
are well guided with warning and failure messages for all the
actions taken .
System Analysis
After carefully analyzing the requirements and the functionality of the
web application , we had two important diagrams by the end of analysis
phase . They are the E-R Diagram and Data Flow Diagram which are the
basis for finding out entities and relationships between them .
E-R Diagrams
In software engineering , an entity-relationship model (ERM) is an
abstract and conceptual representation of data . Entity-relationship
modeling is a database modeling method , used to produce a type of
conceptual schema or semantic data model of a system, often a
relational database , and its requirements in a top-down fashion .
Diagrams created by this process are called entity-relationship
diagrams , ER diagrams , or ERDs .
Data Flow Diagram
Data flow diagrams can be used to provide a clear representation of
any business function . The technique starts with an overall picture of
the business and continues by analyzing each of the functional areas of
interest . This analysis can be carried out to precisely the level of detail
required . The technique exploits a method called top-down expansion
to conduct the analysis in a targeted way .
Context Level
Firstly, draw and name a single process box that represents the entire
system.
Next, identify and add the external entities that communicate directly
with the process box. Do this by considering origin and destination of
the resource flows and data flows.
Finally, add the resource flows and data flows to the diagram.
In drawing the context diagram you should only be concerned with the
most important information flows. These will be concerned with issues
such as: how orders are received and checked, with providing good
customer service and with the paying of invoices. Remember that no
business process diagram is the definitive solution - there is no absolute
right or wrong.
Level 1
The level 1 diagram shows the main functional areas of the system
under investigation. As with the context diagram, any system under
investigation should be represented by only one level 1 diagram.
There is no formula that can be applied in deciding what is, and what is
not, a level 1 process. Level 1 processes should describe only the main
functional areas of the system, and you should avoid the temptation of
including lower level processes on this diagram. As a general rule no
business process diagram should contain more than 12 process boxes.
The level 1 diagram is surrounded by the outline of a process box that
represents the boundaries of the system. Because the level 1 diagram
depicts the whole of the system under investigation, it can be difficult
to know where to start.
Level 2
There can be one level 2 DFD for each process of the Level 1 DFD. Level
2 shows a process broken down into greater detail. Level 2 Diagrams
are only necessary where the Level 1 process is more complex, and
where the particular process is relevant to the analysis.
Level 2 Diagram :
