Thursday, August 8, 2013

Documenting Non-Functional Requirements

Dearest Readers,

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.


As We Work...We Learn...

Wednesday, August 7, 2013

Understanding Non-Functional Requirements

Dearest Readers,

Requirements are the backbone of any Project and its a core competency of a Business Analyst to identify and document various Requirements correctly and completely. Its very important to understand and document Non-Functional Requirements along with the Functional Requirements, which do have an impact on the Project. In this blog post we will try to understand the so called Non-Functional Requirements and their categories.

What are Non-Functional Requirements (NFRs)?
NFRs specify ‘how’ the system should operate, rather than ‘what’ the system should do ‘functionally’. Examples include, but are not limited to, availability, reliability, capacity, scalability and security. These requirements are for a business system and address the aspects of the system that can possibly have a significant impact on how the system will work, and how it is accepted and operated both by the users and the people responsible for supporting and maintaining that system. 

The NFRs along with the functional requirements define the baseline against which the business system must be designed. It is essential that both sets of requirements are captured during the initial stages of a project. 

Non-Functional Requirements Categories:
NFRs define the Qualities expected in the system and the Constraints that may impact the system design and development.

The purpose of a non-functional requirements specification is:
  • To specify required properties of the system.
  • To define constraints on the system.
  • To facilitate early system sizing and estimation of cost.
  • To assess the viability of the proposed system.
  • To give a basis for designing the operational models.
  • To provide input to the component design.
The below diagrams depict various Categories of Non-Functional Requirements and respective Sub-Categories. 

Pic:  Non-Functional Requirements

The list of NFRs portrayed in the above list would help you guys to understand various categories of NFRs in your projects. Hope this will provide you all a glimpse of understanding NFRs. In the next blog-post I will provide a list of scenarios to document these NFRs for your project.

As We Work...We Learn...