how to prove you have met the NFRs

[Ronald Wouters]

Hi all,

I was just wondering, my assignment mentions some NFRs related to performance (response time), availability, etc...
Actual percentages and numbers are given that should be met.
Now, the deliverables for the assignment are the diagrams, assumptions, design choices and so on.
No matter what you put in these diagrams and other documents, it will never prove that your architecture and designs will meet the NFRs like response time percentages and so on. At best, the diagrams and documents are just a "best guess" that the chosen use of technologies, best practices, patterns, things like loadbalancing which you may or may not decide to "mention" in your assumptions document, will actually meet the specified goals. For example, what difference would it make **for the assignment** if you say you put two appservers in a cluster or you say you put three appserver instances in a cluster to meet the required failover if any ? As long as the numbers you mention "sound" a bit realistic, as far as the assignment goes, will it make a difference ?
We are not actually setting up hardware, implementing and deploying the design, doing load tests and so on, the stuff that can actually prove you meet the numbers.
So, maybe the actual NFR percentages and numbers in the assignment are just "window dressing" ?

Regards

[Hong Anderson]

We cannot prove it, but we can make it possible with our architecture and design.

[Scott Soo]

Originally posted by Ronald Wouters:
Hi all,

I was just wondering, my assignment mentions some NFRs related to performance (response time), availability, etc...
Actual percentages and numbers are given that should be met.
Now, the deliverables for the assignment are the diagrams, assumptions, design choices and so on.
No matter what you put in these diagrams and other documents, it will never prove that your architecture and designs will meet the NFRs like response time percentages and so on. At best, the diagrams and documents are just a "best guess" that the chosen use of technologies, best practices, patterns, things like loadbalancing which you may or may not decide to "mention" in your assumptions document, will actually meet the specified goals. For example, what difference would it make **for the assignment** if you say you put two appservers in a cluster or you say you put three appserver instances in a cluster to meet the required failover if any ? As long as the numbers you mention "sound" a bit realistic, as far as the assignment goes, will it make a difference ?
We are not actually setting up hardware, implementing and deploying the design, doing load tests and so on, the stuff that can actually prove you meet the numbers.
So, maybe the actual NFR percentages and numbers in the assignment are just "window dressing" ?

Regards

Hi,

As an architect, we are to justify our technology decision and design as well as giving technological direction and advice. Hence, based on an Architect experience, he or she needs to propose a feasible solution (eg. whether should start with 1,2,3 or 4 servers) which can realistically produce expected output or deliverable meeting both the function and non-functional requirements. The key here is "Expected" not "Actual". Of course the "Actual" can only be proven once implemented,tested and accepted. However, the output should not differ much from the expected with proper thoughts and careful considerations during the design stage. Hence, the assignment is the test the candidate thought process. Putting your reasons and thoughts in the design notes help to communicate your thoughts. Also, the assignment ask for "mitigate" risks which does not mean there is no chance for the risks to occur. It is to demonstrate how well you intent to "mitigate" the risks for the assignments with proper and reasonable justifications. For example, you cannot possible tell the customer to just buy 6 servers without justifying why. Hence, you need to tell the customer to start with a reasonable number of servers with justifications or, even, a roadmap.

Hope the above helps and it is just my point of view.

Thank you.

Cheers!!!

[Tejas Bavishi]

The NFRs like scalability, etc is part of the Capacity planning. It is possible to estimate the actual size of the hardware based on the application complexity, past experience of the architect as well as the soundness of the application design.

To have all this at the time of design / creation of architecture, will be based on several assumptions and for application to meet those NFRs will depend on the correctness of those assumptions and implementation of the application.

I have seen that over the time many of the assumptions with which the application was designed, actually changes. With this, the capacity planning is actually required to be done again after the application is built.

I am yet to see any exact mathematics to do this

These are my thoughts and other are welcome to share their thoughts.

Thanks
Tejas