Artifacts Involved in the Requirements Phase
page 4 of 8
by Uday Denduluri
Feedback
Average Rating: This article has not yet been rated.
Views (Total / Last 10 Days): 41251/ 54

Software Requirements Specification (SRS)

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.

·         Functional Requirements

·         Specific Requirements

·         Performance Requirements

·         Security Requirements

·         Safety Requirements

Functional Requirement

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.

Listing 1

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 example.

Listing 2

Fn-R001 – Log-In access for the Application

Input

User should be given the provision to type User name and Password.

Username will be displayed as WYSIWYG format, but Password will be displayed in “*” format.

Username and Password should be persisted in a centralized database repository.

Processing

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 length.

Username should not start with a numeric character.

There should be at least one numeric character in the password.

The password should be stored in the encrypted format in the database.

Output

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

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 application.

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.

Performance Requirements

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.


View Entire Article

User Comments

Title: Ms   
Name: Angelina Peters
Date: 2009-02-19 10:44:38 AM
Comment:
I understand your frustration Mr Brown, but instead of blasting would have appreciated if you correct wherever he has messed up and edit it
Title: Mr.   
Name: PeterB
Date: 2007-06-12 11:02:36 AM
Comment:
I am very irritated to see this kind of foolish article in this kind of sites.

Editors would have been smart and practical enough to understand and also edit the articles dealing with the SDLC or any phase of the Project.

mr.author is creating all the mess with his vague or may be quite limited experience in the SDLC related matters.

I Just looked his article dealing with Artifacts in Design Phase, Which is completely vague and worst within a single word.


What does the mean of BPA and why is that mentioned as the standard artifact of requirement phase?

however it is understood that SDLC can be customized by different organizations to deliver additional artifacts according to their style of work.

But this fellow tried to take the same as the standard artifact and sending his waves of BIASED knowledge across the community.

I am sure any moderate or experienced Dev Folk after going through this article they will check for BPA across the internet, Don't worry it is a customized artifact but shouldn't be discussed as the standard artifact in this kind of articles.

I am surprised how blunt editor could edit and confirmed article for publishing as the requirements phase article never talk about RTM: Requirements Traceability Matrix and lot more mandatory artifacts.

It gives me the doubt that editor may be very good literate but not a practical hands on guy.

I am sure about what I've said.

If author has any point to talk to me give me the reverse message here.

If any one of you guys knows the mail id of the editor, I would URGE you guys to send this content as the mail to the editor

Mr. Peter Brown.

Product Spotlight
Product Spotlight 





Community Advice: ASP | SQL | XML | Regular Expressions | Windows


©Copyright 1998-2024 ASPAlliance.com  |  Page Processed at 2024-03-28 7:42:24 AM  AspAlliance Recent Articles RSS Feed
About ASPAlliance | Newsgroups | Advertise | Authors | Email Lists | Feedback | Link To Us | Privacy | Search