Tuesday, June 18, 2013

Widgets

Requirement Types with Examples

Dearest Readers,

Here we go with another post for our BA Blog on Software Requirement Types. As Requirements are the PILLAR of any Software Application or System, hence Identifying correct Requirements and documenting those properly is one of the core competencies of any Business Analyst. 

In this post, I tried to depict a glimpse of different Software Requirement Types along with relevant examples. Please check the below picture:

Pic: Software Requirement Types

It is not mandatory that, we shall document all types of Requirements in our deliverables (Business Requirements Document or Software Requirements Specification) for all the Projects. Depending upon the Project nature, we can identify and document requirements belonging to some or all of the Requirement Types.

Below is the Examples of various Requirements Types. To do the same, I have taken a simple Example of "Log-in" Functionality and tried to differentiate various types of Requirements.


Pic: Requirements Documentation - Example

Requirements Documentation Guidelines:

Requirement ID (Req. ID):  Each Requirement shall be identified with a unique ID. In this example, I have used Acronyms of the Requirement Types followed by a Requirement Number for documenting Requirement IDs. Such as:
  • FR.01 (Functional Requirement 01), FR.02 (Functional Requirement 02), so on and so forth...
  • NFR.01 (Non-Functional Requirement 01)...
Requirement Description: This describes the Requirement of the Proposed System completely.

Priority & Complexity:  While documenting Requirements, generally we assign the Priority and Complexity of each Requirement. Here I have taken measures as Low, Medium and High to assign the Priority and Complexity. At some places, you will see a numeric scale as well. There are so many factors to determine the Priority and Complexity of Requirements. Hopefully, I will write a separate Blog Post on"Requirements Prioritization" soon.

Hope, this post will help you guys in understanding various Requirement Types and the way to document them.

Let me know your feedback...


As We Work...We Learn...

21 comments :

Richa Varshney said...

Too good .. You summaries the stuff I took long to finish in my course . Thank you so much for sharing .

ROHIT kumar said...

ITS Awesome ...very helpfull

Thanks Abhijeet.

Anonymous said...

Very great Webpage
Sudhi

Kalpa said...

Its very informative! i understand you had taken simple one to make us understand quickly but i am expecting something more than "Login" page. I liked the pattern you chose to explain.

Please do post more often

Rakesh Sharma said...

Hi Abhijeet, Thanks a lot for sharing it.. you have given perfect examples of different types of requirements.

Abhijit Patro said...

A big thanks to all of you for your appreciation and feedback.

Regards...

Shankari said...

Wow!! Loved this post.. really liked the way you have explained all the Requirement Types - very clear and concise.

Sujeet said...

Hi Abhijeet,

Its' a very simple summary of the requirements very well explained in a pictorial format. It is for the learners to understand and you explained it in a very simple and a professional way. You have taken a right example to explain the requirements as it is for the learners who want to learn about Business Analysis and how to become a Business Analyst

Abhijit Patro said...

Thank You Very Much...

Regards...

Prabhat Padhy said...

Good one-simple but informative.

Anonymous said...

so informative, i will definetly refer to this as an intern im working on certain projects.

CucuRucu said...

Hi!
I am using exactly the same format for the requirements description and sometimes I feel that I have an issue with finding the proper size for one requirement ID (one line).
For example, if I have to do some changes that involve, also, an UI form update (let’s say: some new fields on the existing tab of the form, shift some existing fields, add a new tab to the form – with new fields) – should I put all these requests as 1 requirement ID (taking into account that comparing to the entire specification file, this is a tiny task) or split them in several requirements (ID-s)?...
Is there a best practice regarding a requirement size when using this template?
Thank you!

Abhijit Patro said...

Per my experience, you should document separate requirements with unique Requirements IDs if there are different functionalities involved (Such as: a new tab needs to be added for a new feature, a new button needs to be introduced in an existing screen which has some additional functionality, etc.).

But if there are only UI (User Interface) related changes pertaining to a single functionality then you can document a Single UI Requirement and create Mock UIs (Sample Screens) for As-Is & To-Be, to differentiate the required change.

Hope this would help.

Regards...

CucuRucu said...

This is how I did at the begining - every requirement with separate requirementID, but my dev colleagues (that write the code) complained that it is too dissipated and for them it would be easier if all requirements concerning one functionality would be grouped in a requirementID, so I started to put more requests related to a specific feature on one ID (but I am worried about ending up at the other extreme). :)
As I "borrowed" this template from my BA ex-colleagues (I used to be support analyst at the time I worked with them) and now use it more "intuitively" then based on some theoretical knowledge, I was wondering if there are some standards that state where is the equilibrium regarding a requirement size.
From your answer I understand that it depends on the case.
Thank you,
Cristina

Swapnil said...

Helpful Blog. Many thanks...

Neeraj Kumar Singh said...

Thanks for the post
As a beginner BA it is very useful.

Anonymous said...

Thanks. How would you incorporate business rules, basically, as another requirement type under business requirements?

Avinash said...

thanks man, that ws very useful

Abhijit Patro said...

Thanks a ton everyone for going through this blog-post and liking it.

Regards...

Eric Barnes said...

too many design elements used if this is to be a true business requirements document. This is a functional spec., not a business requirement. I have seen this too much where design overlaps business requirements can usually steers organizations in which the business side of the house is dictating design. This is not a format I am in favor of using for large projects or across business entities to I.T.

Anonymous said...

Its very helpful..thanks for sharing..but can you share requirement example for little bit more complex scenario.

Post a Comment