12:01 PM
Abhijit Patro
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.
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:
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.
- FR.01 (Functional Requirement 01), FR.02 (Functional Requirement 02), so on and so forth...
- NFR.01 (Non-Functional Requirement 01)...
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...
Let me know your feedback...
Posted in:
Requirements Gathering
23 comments :
Too good .. You summaries the stuff I took long to finish in my course . Thank you so much for sharing .
ITS Awesome ...very helpfull
Thanks Abhijeet.
Very great Webpage
Sudhi
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
Hi Abhijeet, Thanks a lot for sharing it.. you have given perfect examples of different types of requirements.
A big thanks to all of you for your appreciation and feedback.
Regards...
Wow!! Loved this post.. really liked the way you have explained all the Requirement Types - very clear and concise.
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
Thank You Very Much...
Regards...
Good one-simple but informative.
so informative, i will definetly refer to this as an intern im working on certain projects.
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!
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...
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
Helpful Blog. Many thanks...
Thanks for the post
As a beginner BA it is very useful.
Thanks. How would you incorporate business rules, basically, as another requirement type under business requirements?
thanks man, that ws very useful
Thanks a ton everyone for going through this blog-post and liking it.
Regards...
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.
Its very helpful..thanks for sharing..but can you share requirement example for little bit more complex scenario.
Nice blog .Keep updating BA Online Course
Thanks for the info!
Post a Comment