• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Tim Cooke
  • Campbell Ritchie
  • paul wheaton
  • Ron McLeod
  • Devaka Cooray
Sheriffs:
  • Jeanne Boyarsky
  • Liutauras Vilda
  • Paul Clapham
Saloon Keepers:
  • Tim Holloway
  • Carey Brown
  • Piet Souris
Bartenders:

how to prove you have met the NFRs

 
Ranch Hand
Posts: 198
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 1936
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
We cannot prove it, but we can make it possible with our architecture and design.
 
Ranch Hand
Posts: 83
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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!!!
 
Ranch Hand
Posts: 73
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic