Software Architecture is the organizational structure of a system. Architecture can be recursively decomposed into parts that interact through interfaces, relationships that connect parts and constraints for assembling parts. Parts that interact through interfaces include classes, components and subsystems. Whether software architecture plays any role to satisfy the non-functional requirements? Justify your answer with strong arguments.
Read the instructions carefully before sending your comments:
They are the people responsible to often times derive the hidden non-functional requirements and incorporate them into the overall design. A good example of non-functional requirements that can be heavily dependent on design would include performance and usability. An architect's decisions can heavily sway how quick (or slow) a system is based on their design, like the choice of if, where, how to store and access data can make a very large difference in performance. In terms of usability, the choices that go into what controls(if a GUI, the layout can be key as well) are to be implemented (and how they are to be accessed) for the-end user to perform whatever the functional requirements can make or break the usability of the system.
Software architecture plays very important role to satisfy the Non functional requirements. The software architecture means structure of software system and the structures are very important for software systems. Architectures divided our system into smaller parts. The parts are very useful to perform bigger tasks with efficiency. Non functional requirements tells the criteria that can be used to judge the operation of a system and these requirements are often called the Qualities of a system that is why the software architecture is very vital to satisfy non functional requirements
As the question is
Whether software architecture plays any role to satisfy the non-functional requirements? Justify your answer with strong arguments
The answer is software architecture plays a vital role to satisfy the non-functional requirements & arguments are already given
Software Software Architecture performs a vital role and part in non-functional requirements. Architecture partitions your system into smaller parts, which should make estimation more structured, more accurate. You can also use architecture to support development, for example different teams or individuals having responsibility over different architectural subsystems, and controlled incremental test/release of subsystems from the bottom up. Bottom line is that development of a code base with a defined and enforced architecture will be quicker and more predictable/manageable - all else being equal - and improve many of the non-functional aspects of your project. A system incorrectly designed for non-functional requirements can meet all the functional requirements, but turn out to do it inefficiently as well as in a manner very difficult to control (thus not meeting the non-functional reqs.). But The newly created design is evaluated again and the process is repeated, if necessary, until all non-functional requirements have been satisfied as much as possible.
How do software architects deal with non-functional requirements?
The full results of our exploratory study on how software architects deal with non-functional requirements (based on a set of interviews with software architects) were presented at the RE’12 conference (full paper is available here and the summary/slides can be browsed below)
What was the motivation of this work? Research papers on software architecture often include sentencens like:
“[NFRs] play a critical role during system development, serving as selection criteria for choosing among myriads of alternative designs
“the rationale behind each architecture decision is mostly about achieving certain NFRs”
“quality attribute requirements strongly influence a system’s architecture”
but the problem is that there is very little evidence that this is really how software architects work in practice. Therefore, we set out to see if we could confirm or not this assumption.
Some of the observations that can be derived from the analysis of the interviews’ data were quite surprising (for full details and the threats to validity see the full text linked above, in the following we single out some simplified results):
In fact, nobody had a permanent software architect role. Instead, they played the role of software architect (and others simultaneously) depending on the project
There is a lot of confusion regarding the exact meaning of several non-functional requirements
Non-technical requirements (price, license, provider) are as important as the technical ones, i.e. the SW architecture can never be the ideal one but the one that satifies all these non-technical constraints).
The software architect, and not the client, is the one that decides which NFRs are needed
System compliance with the NFRs is hardly ever verified
No tool support to manage the NFRs is used.
The first part of the role is about managing the non-functional requirements. Software projects often get caught up on asking users what features they want, but rarely ask them what non-functional requirements (or system qualities) that they need. Sometimes the stakeholders will tell us that "the system must be fast", but that's far too subjective. Non-functional requirements need to be specific, measurable, achievable and testable if we are going to satisfy them, plus we need to make sure that all of the important non-functional requirements are taken into account. This includes the common runtime characteristics such performance, scalability, availability and security through to the non-runtime characteristics such as audit, extensibility, internationalisation and localisation. Somebody needs to help the stakeholders refine the non-functional requirements, define them and challenge them when appropriate. After all, how many systems have you seen that genuinely need to be operational 24x7? Since most of the non-functional requirements are technical in nature, they often have a huge influence on the software architecture and the resulting solution needs to take them into account. For this reason alone, it makes sense that the software architect takes this on as a part of their role. Ultimately, the software architect needs to understand what it is they are building.
Even with the best architecture and leadership in the world, poor delivery can cause an otherwise successful project to fail. Quality assurance is a large part of an architect's role, but it's more than just doing code reviews. For example, you need a baseline to assure against, and this means the introduction of standards and working practices. From a software development perspective, these could include coding standards, design principles and source code analysis tools through to the use of continuous integration, automated unit testing and code coverage tools. It's safe to say that most projects don't do enough quality assurance, and therefore you need to figure out what's important and make sure that it's sufficiently assured. For me, the important parts of a project are anything that is architecturally significant, business critical, complex or highly visible. You just need to be pragmatic and realise that you can't necessarily assureeverything.
Putting non-functional requirements into software architecture
This paper presents an approach for incorporating non-functional information of software system into software architectures. To do so, components present two distinguished slots: their non-functional specification, where non-functional requirements on components are placed, and their non-functional behaviour with respect to these requirements. Also, connector protocols may describe which non-functional aspects are relevant to component connections. We propose a notation to describe non-functionality in a systematic manner, and we use it to analyse two particular aspects of the meeting scheduler case study, user interaction and performance
Role of Software Architecture in Non-Functional Requirements
Software Architecture plays a very large role in non-functional requirements.
They are the people responsible to often times derive the hidden non-functional requirements and incorporate them into the overall design.
A good example of non-functional requirements that can be heavily dependent on design would include performance and usability. An architect's decisions can heavily sway how quick (or slow) a system is based on their design, like the choice of if, where, how to store and access data can make a very large difference in performance. In terms of usability, the choices that go into what controls(if a GUI, the layout can be key as well) are to be implemented (and how they are to be accessed) for the-end user to perform whatever the functional requirements can make or break the usability of the system.
A system incorectly designed for non-functional requirements can meet all the functional requirements, but turn out to do it inefficiently as well as in a manner very difficult to control (thus not meeting the non-functional reqs.).
non-functional requirements define the operation of a system. these are important for any system. a system in which all non-func. requirements are not considered would fail. software architecture plays an important role to satisfy non-functional requirements as it is organizational structure of a system and it is incomplete without non-functional reqs.I think every system architecture obeys the OSI model and that's why I think that it satisfy the non-functional requirements.
Non functional requirements in software architecture practice: