How do you document non-functional requirements in your solution?

Why emphasize NFRs? As a solution architect, your role isn't merely about building; it's about setting clear benchmarks. Documenting NFRs crystallizes expectations, highlights potential pitfalls, and fosters dialogue with stakeholders. It acts as a beacon for performance and quality. Overlooking NFRs? It's akin to sidelining the vital elements that guarantee project success.

In addition to the NFRs document you can always use your NFRs to document your architectural decisions and explain the reason of your architecture selection in compliance with your NFRs. NFRs are decisive not only for solution architecture but also for defining testing strategies.

Non Function Requirements are in a way more important than functional requirements. A few missed or incorrectly captured requirements are not a big deal and be fixed easily during testing or in production. However if NFR requirements of security, scalability, reliability, uptime, performance, interoperability etc are not captured and taken into consideration at the architecture and design level and tested on continuous basis, the system may be headed for disaster with either a costly rework or even to abandon the same. Most NFR can only be addressed at Architecture level and given that architectural issues are not easy to fix later, not giving them due importance at start is a serious risk to successful rollout of project to production.

Pluto7 architect, I document non-functional requirements in my solution using a variety of documents, including: Non-functional requirements document (NFR doc): This document is a comprehensive overview of all the non-functional requirements for the system. It includes the following sections: Introduction Scope Definitions Non-functional requirements Acceptance criteria

I was brought in to rescue a $1B project that failed due to lack of documenting and building to NFRs. The original designers did not even know what NFRs are. These are critical to define up front and may even show that the project is not feasible or have a positive ROI. Leadership should be demanding to see this.

Asking questions around "ilities" (quality, scalability, availability, security, reliability, usability, accessibility, etc.) is a great way to start, and then refine to make the NFR specific and measurable.

Start by identifying the non-functional requirements that are relevant to your solution. These may include performance, scalability, security, availability, reliability, usability, accessibility, and more. Collaborate with stakeholders, including end-users, business analysts, architects, and security experts, to gather and prioritize these requirements.

They stem from business aims, user demands, tech limits, regulations, and industry norms. Engage stakeholders with queries like, "What defines your solution's success?" or "Any potential challenges?" Review documents for NFR hints, like scalability needs or user interface expectations. Benchmark against industry: if rivals offer chatbots, should you? If similar solutions respond in under 2 seconds, can yours? Maturity models play a pivotal role, offering structured levels to gauge and elevate solution readiness and robustness.

Separate based on whether it is a NFR based on run-time or other part of the lifecycle such as maintainability vs performance

Nowadays my recommendation is to use a lightweight version of Architecture Decision Records (ADR). This way it is possible to capture the requirements as part of the context but also have all the consequences and way forward colocated. I love the opportunity of writing the ADRs using Markdown which allows to check the ADR into source control and cross link it to stories, code commits, automated test reports and release notes.

In my experience solutions architected can be two fold - greenfield and brownfield. First, for brownfield architecture and design, since the product or platform existed - one can baseline using production logs and transactions data to model the non-functional requirements and approach it in a more realistic or pragmatic manner. Greenfield, as the name suggests is something new. Hence the business drivers and goals can be discussed upfront as part of the business requirements phase and then translated to technical stories that could or not be related to functional stories. E.g. of a related story is login/MFA etc. which translates to security related NFRs and extending in that thought process. Unrelated one could be disaster recovery, BCP.

NFR's- Non functional Requirements should be carefully selected and agreed and taken in to consideration right from design and development phases, so it's not neglected. Otherwise, it's seen that these NFR open up during performance testing which is too late to take care if design does not permit. It's a best practice to be cognizant of requirements and it should be taken care from beginning for example, NFR's could be added in "definition of done" in Agile Development where team will ensure development is done as per requirement.

It is advised that NFR should be conceived from the very beginning of the project using the "shift-left"approach and it should always have a holistic enterprise view in mind . It should be ever evolving and should be updated regularly as the project progresses. The NFRs has applicability from Design to even post delivery we could not leave the baton in between and should be assessed in each project phase.It has been observed that siloed NFR design could be flawed impractical and costly to implement.It has often been observed as Non-Funct has multiple facets(Availability,ORT, security, performance,DR,etc). Many of these do not get required focus due to lack of focus and commitment from the project resulting in costlier and flawed delivery.

As the project advances, continuously review and refine the non-functional requirements. Ensure they remain relevant and aligned with the evolving project goals and user needs. If you are practicing Agile, attempt to create NFR user stories to normalize the vocabulary used by project teams.

NFRs are essential, however a note of caution; NFRs can be expensive to implement and operate, so care should be taken to ensure that NFR is really needed and properly scoped. How often have we all seen the requirement "must be 99.99% available" but only to find out the real availability NFR is something less?