Once the features list document is baseline, the Software
Requirements Specification (SRS) document is prepared based on the features
list document. The SRS document not only speaks about all the features in an
extensive manner, but also speaks about other requirements like performance
requirements, system requirements, etc. Let us try to understand different
types of requirements that we see in an SRS document.
A Functional Requirement elaborates a feature which shows
some operations that can be performed on a screen. As the name suggests a
functional requirement is a requirement that has some functionality attached to
it. Any operation that can be performed by the user is generally a functional
requirement. It starts with the input initiated by the user, the validations
that need to be incorporated and the output of the system. Let us understand a
Functional requirement with the help of an example. Listing 1 explains the
contents or template of the functional requirement.
Functional Requirement Name [FR-No] – “Name of the
Requirement and serial number of the requirement are shown here. In some of the
cases Requirements are referred with the numbers attached to it.”
Input – “The actual input for the requirement or from where
does the user initiate.”
Processing – “Validations, Steps in achieving the
requirements, etc. are discussed here.”
Output – “The outcome of the requirement is discussed.”
Let us take a more realistic example here. The functional
requirement below explains a simple scenario of a Log-In page. The User gives the
Username and Password. In the case of success, the user will be shown a welcome
page. In the case of a log-in failure, the user is shown an appropriate
message. For a developer it looks like a simple scenario, but it is one of the
most exhaustive functional requirements. Let me justify why it is more
exhaustive. Listing 2 explains a functional requirement with a real life
Fn-R001 – Log-In access for the Application
User should be given the provision to type User name and
Username will be displayed as WYSIWYG format, but Password
will be displayed in “*” format.
Username and Password should be persisted in a centralized
Both the fields' User name and password are mandatory for
the Log-In page.
Username should be verified to be at least 6 characters in
Username should not start with a numeric character.
There should be at least one numeric character in the
The password should be stored in the encrypted format in the
If the User name and password do not match then a proper
Log-In failure message should be displayed to the user.
If they match then the User should be shown a welcome page.
Specific requirements are generally requirements that
discuss the behavior of the system rather than the functionality of a feature.
In general Specific requirements do not have a user interface. Specific
requirements are considered to be very easy to document, but very tough to
develop. Let us understand specific requirement with the help of an example.
The example shown below is a specific requirement. It
explains a feature called Logging that needs to be implemented for the entire
Logging should be implemented for the Application. There can
be four logging levels attached to the logging: Error, Warning, Info and
Verbose. The level of logging should be configurable and also the repository
for the logging should also be configurable. The logging repository can be a
Database, MSMQ, Event Viewer or a Text file.
As the name suggests the performance requirements deal with
the performance of the system. It is more of a quality factor rather than a
requirement. Generally, performance requirements come into picture for Real
time systems or Web applications. In case of client server architecture the
minimum number of clients the server can serve can also be taken as performance
requirement. It is to be understood that performance requirements varies on the
machine, architecture, installation, etc. Hence, performance requirements will
be documented with optimal parameters.