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.

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

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.

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.

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

Use case

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.