Artifacts Involved in the Requirements Phase
Published: 12 Jun 2007
This article will start with a brief description of the SDLC and then some details about the requirements phase related artifacts such as SRS, BPA, Features list, Use cases, etc.
by Uday Denduluri
Average Rating: This article has not yet been rated.
Views (Total / Last 10 Days): 38889/ 137


Requirements analysis is considered to be the key phase in Software Development Life Cycle (SDLC). Requirements phase would deal with thoroughly analyzing each and individual feature in the scope document or Features list. All the understandings or findings would be exhaustively documented. This document is called as Software Requirements Specification (SRS). We have some standard templates available for SRS. The SRS would be the main output of the Requirements phase. Apart from these there are some other artifacts involved in the Requirements phase.

We will discuss each of these Requirements related artifacts in detail. Our main concern will be on the content of the documents rather than the template. Different organizations follow different templates.

Tasks in Requirements Phase

Let us try to visualize the requirements phase with a diagram showing the inputs and also outputs.

Figure 1

1.    Artifacts in Requirements Phase

2.    Features List/Scope Document/Vision Document

3.    Software Requirement Specification [SRS]

4.    Business Process Analysis [BPA] Document

5.    Use Cases Diagrams

Features List Document

A features list document is generally prepared by a functional consultant. This document contains the scope of the entire project. A functional consultant prepares this document after a detail market analysis. (In case of product development various scenarios are taken into consideration before freezing the scope of the document Competitive company products, Innovative features, Time lines for the product, etc.)

A features list document is considered to be the input for the requirements phase. In some scenarios this document is also called as a scope document or a Vision document. Each individual feature in the features list document can be a Functional requirement or a Specific requirement. We will understand more about requirements in the next section. Generally, a feature will be quite generic in nature. It does not speak more about the technical aspects.

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


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.


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.


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.

Business Process Analysis (BPA)

The Business process Analysis document is prepared by the functional consultant exposing a feature or a module in the proposed product. The BPA document is prepared for all the key features of the proposed product. This document will be circulated to all the individual stake holders of the project which gives an insight of the feature.

The Business Process Analysis (BPA) document discusses all the following topics.

·         Description of the Module or feature – Gives the usage of Module in the entire project.

·         Acronyms or Definitions – Lists down all the Acronyms used with definitions.

·         Feature 1…n – Explains each feature within the module.

·         Tables – The table will be a functional table and needs not be a physical table in database.

·         Interfaces exposed – Interfaces are exposed by the module so that it can be consumed by other modules.

·         Using other modules – If the module is using other modules then this section explains how it needs to use the module.

Use Case Document

Use case is a Unified Modeling Language (UML) technique to capture the requirements in form of a figure. A use case diagram displays relationships between Actors and a Use case. An actor represents a user or another system that will interact with the system. A Use case is the system that we are currently showing. Let us see some Use case diagrams before we actually go through the UML documents.

Figure 2 shows a use case which explains all the operations of a customer from getting a catalogue for ordering and finally getting the confirmation of the same.

Figure 2

Use case document is the supporting document for the use case diagram. It has the description of the use case diagram. It has the following sections.

·         Brief Description – 2 to 3 sentences about the use case

·         Pre-conditions – conditions before the use case actually started

·         Basic flow – the basic control flow

·         Alternative flow – the alternative control flow

·         Post conditions – the condition after the use case executes



Requirements analysis is considered to be the key phase in Software Development Life Cycle (SDLC). Requirements phase would deal with thoroughly analyzing each and individual feature in the scope document or Features list. We have discussed most of the artifacts of the requirements phase. We covered Features list, SRS, BPA and Use case documents.

User Comments

Title: Ms   
Name: Angelina Peters
Date: 2009-02-19 10:44:38 AM
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
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. 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-2020  |  Page Processed at 2020-08-09 1:15:14 PM  AspAlliance Recent Articles RSS Feed
About ASPAlliance | Newsgroups | Advertise | Authors | Email Lists | Feedback | Link To Us | Privacy | Search