Product owners defines application functionalities and requirements about what application should do. Such requirements are called functional requirements.
There use to be some inherent requirements of a system like performance,scalability, manageability, which the software architect needs to identify and define.These are called non-functional requirements of a system.Non functional requirements defines the quality or constraints of a system.If these are not taken care during software architecture phase, application ends up with technical debt, which leads to high cost of maintenance, enhancement and support.
The distinction between functional and non-functional requirement can be understood from a ticket booking application. The functional requirement would be that users should be able to book the tickets between two locations. Whether the application should remain available all the time or can be brought down for some time weekly or monthly for maintenance would be a non-functional requirement.
Some examples of non-functional requirements of an application are as following -
Creating the stories and getting the product-owners buy-in for prioritization -In this approach, we talk to product owner to get the non-functional requirements considered as user stories. The example of such story with acceptance criteria might be "As a user, I want the application to remain available 24*7. It should not need to be brought down for upgrades" . The limitation of this approach is that some of the times, such stories might not be prioritized by product owners for a long time. The positive side of this approach is that whenever its picked up, we would have complete buy-in from product-owners.
Considering the non-functional requirements part of functional story itself - In this approach, the non-functional requirements gets implemented along with the story itself, but it would have impact on the estimation of stories. While following this approach, the estimation would be higher than it would have been without non-functional requirements
In this article, I explained the way to understand and manage the non-functional requirements. Please let us know,your experience as well about managing and handling non-functional requirements
There use to be some inherent requirements of a system like performance,scalability, manageability, which the software architect needs to identify and define.These are called non-functional requirements of a system.Non functional requirements defines the quality or constraints of a system.If these are not taken care during software architecture phase, application ends up with technical debt, which leads to high cost of maintenance, enhancement and support.
The distinction between functional and non-functional requirement can be understood from a ticket booking application. The functional requirement would be that users should be able to book the tickets between two locations. Whether the application should remain available all the time or can be brought down for some time weekly or monthly for maintenance would be a non-functional requirement.
Some examples of non-functional requirements of an application are as following -
- Scalability (Capability to handle growing amount of work)
- Performance
- Usability (Easy to use, learn and fit for purpose)
- Manageability (Easy to configured, deployed, controlled and supervised)
- Security
- Documentation
- Extensibility (Ability to be extended with minimal or no change in existing code/behaviour)
- Portability (Usability in different environment)
- Reliability (Ability to function under stated condition for specified period of time)
- Robustness (Ability to cope up with error or erroneous input during execution)
- Availability (Ratio of time of application at operable/committed level to total time)
- Resilience (Ability to provide accepted level on service in case of faults, natural disasters or targeted attacks)
- Configuration management (Track and control changes in software)
- Disaster recovery (Procedures to recover from natural or human made disasters)
Creating the stories and getting the product-owners buy-in for prioritization -In this approach, we talk to product owner to get the non-functional requirements considered as user stories. The example of such story with acceptance criteria might be "As a user, I want the application to remain available 24*7. It should not need to be brought down for upgrades" . The limitation of this approach is that some of the times, such stories might not be prioritized by product owners for a long time. The positive side of this approach is that whenever its picked up, we would have complete buy-in from product-owners.
Considering the non-functional requirements part of functional story itself - In this approach, the non-functional requirements gets implemented along with the story itself, but it would have impact on the estimation of stories. While following this approach, the estimation would be higher than it would have been without non-functional requirements
In this article, I explained the way to understand and manage the non-functional requirements. Please let us know,your experience as well about managing and handling non-functional requirements
No comments:
Post a Comment