On this website we use cookies that are strictly necessary to make our website function correctly, as well as optional – analytics, performance and/or marketing - cookies which help us improve our website by collecting and reporting information on how the website is used, as well as help us to reach out to you with information about our organization or offer. If you do not wish to accept optional cookies when visiting our website, you may change the settings in the Cookie Settings. For more information go to Cookie Settings.

Skip to content

Non-Functional Requirements tips

Technology

Sep 24, 2015 - 4 minutes read

Objectivity Blog 416 306
Grzegorz Łoniewski
They call me Analyst, Business Analyst. I’m a software engineer experienced in the industry with strong background from the academia. My hobbies are: Requirements Engineering, snooker and orienteering.
See all Grzegorz's posts
Data Driven Organisation Blog Ebook 416X300

Share

Do you explicitly address Non-Functional Requirements (NFRs) in your projects? If the answer is NO, then this article is addressed to you! These 6 tips will help you avoid some serious trouble.

Always consider NFRs, even if the client can’t see it that way

How often do you hear that there are no specific requirements for performance, security, etc.? How often does the client hide NFRs knowing their impact on the project cost? How often is a delivered product not accepted as the client’s expectations are not met or simply the product is not working properly in the production environment?

Always consider NFRs as they are crucial to client satisfaction. Probably every IT company can deliver a product which does what it should do. Be the one who also cares about how well it is done!

Be clear that NFRs may significantly impact project effort and timeline

Knowing the importance of NFRs, do not ignore them during your estimations and project timeline setting.

Long lasting performance improvements, sometimes even last minute technological or architecture changes due to usability requirements not being met, arduous bug detection and fixing, this list could be very long, as are the projects, in which case NFRs are not being treated properly. Each identified requirement brings additional effort for proper architecture design, development and testing. Moreover, there is a risk that some of the requirements may significantly impact the effort and project delivery date.

Including the NFR treatment as a potential project risk, as well as early communication with the client at this point, may be helpful in NFR analysis to mitigate that risk.

Analyse NFR dependencies

In academia, NFRs are commonly known to be complex and therefore a lot of attention is being paid to this area. Industry practitioners hardly think of NFR as they are hard to identify, very hard to analyse and extremely hard to measure. Where is the balance?

The complexity of NFRs comes from their interdependencies. They should not be considered in isolation but rather some trade-offs between them have to be made. Several Requirement Engineering methods have been proposed in recent years to document and analyse NFRs. These approaches fall into process-oriented or product-oriented categories. The former category is aimed at fully understanding NFRs, making design decisions and communicating their importance to the client. While the latter is to formalise the operational criteria for each requirement.

Some of these methods are NFR Framework, Keep All Objectives Satisfied (KAOS), or i-star.

Follow our next posts in the NFR thread for more on this topic.

Deliver tasty specification for developers and testers

The aforementioned industry aversion to NFRs originates from the fact that it is hard to specify and measure them. If the clients are not really satisfied with what they’ve got, it means that the analysis phase has failed. Business Analysts should be aware of what kind of tools can be used and what kind of measures can be taken to validate the product against requirements. The goal for analysts should be creating NFR specifications that are understandable by technical architects and testers, bound by functional context and are possible to measure effectively.

Keep NFRs a part of DoR and DoD

First of all, keep NFRs a part of the Definition of Readiness. Making it explicit, we show the client that we care. It is also an item on analyst’s long checklist of what should be done within each User Story. Sometimes, it’s not necessary but discussing it with the Product Owner brings valuable NFR awareness.

Second of all, NFRs should be a criteria in the Definition of Done. NFRs should be validated at all stages of development.

Test Continuously

Do not leave the NFR testing until the end of a project. Each delivered product increment may have an impact on the satisfaction of NFRs. System qualities should be verified continuously, whether they are acceptable or not. Measurements of how a particular delivery degraded or improved the product qualities can be a key factor when taking important technical or delivery process decisions. The known testing matrix below highlights the character and importance of continuous testing. Use tools to automate it whenever possible.

Testing_matrix

 

Summary

If you are reading this summary, it means that you are now ready for NFR-oriented thinking. Regardless of your role in the project, ask yourself a question about NFRs. The client will appreciate it.

More to come in the next blog entry: benefits of analysing NFR interdependencies; deep dive into I-star method, first attempt at sharing practical knowledge of NFRs – a report from our Business Analysts day away.

Data Driven Organisation Blog Ebook 416X300
Grzegorz Łoniewski
They call me Analyst, Business Analyst. I’m a software engineer experienced in the industry with strong background from the academia. My hobbies are: Requirements Engineering, snooker and orienteering.
See all Grzegorz's posts

Related posts

You might be also interested in

Contact

Start your project with Objectivity

CTA Pattern - Contact - Middle