Whenever we work on a Project, the Business Users of that project/ system will have some implicit expectations on how effectively the software will work. These expectations may include how user friendly the software will be to use, how fastly it will execute transactions, how durable it will be, and how well it behaves when unexpected conditions or exceptions arise. The Non-Functional Requirements (NFRs) define these aspects about the system. In our previous blog post we understood all about NFRs. In this blog post we will discuss on how to identify and document the Non-Functional Requirements (NFRs) for a Project.
In the below Picture (Table), I have listed possible Non-Functional Requirement Statements under each category and respective Target values. So while documenting the NFRs for your project, you can list similar NFRs and obtain the answer (target value) for the NFR from various Stake-holders. Some inputs you can obtain from Business Users, some from IT Department, some from Design Team, some from Database Team, so on and so forth...
Pic: Documenting Non-Functional Requirements
The above list is not the final set of NFR Statements Vs Values, out of my experience I have documented these. Depending on your Project Requirements there may be some new NFR Categories and some more NFR Statements. Here, my intention was just to show a path to identify and document NFRs. Hope you all will like this. Please share your experience and feedback through comments.