1. - 1 -
Abstract— In terms of Software Architecture
seldom the requirements of a new system are
sufficient to ensure that it will meet the needs and
expectations of customers. Without undertaking a
formal architectural evaluation process, the
organization cannot ensure that the architectural
decisions made-particularly those which affect the
achievement of quality attribute such as
performance, functionality, usability, efficiency,
maintainability, reliability, availability, security
and modifiability are advisable ones that
appropriately mitigate risks. The question to which
the answer is often vague is: The architecture is
good enough? Many authors and researchers have
identified that there is a gap between requirements
definition and architecture defined for new
systems. This failure in the elicitation of the
features that ensure the quality desired by the
client leads to risks. Some authors have researched
this field and proposed models of quality
assessment in systems architecture. However there
is a market need for tools that facilitates the
evaluation of architecture quality and connect it to
which involved components. So this paper relies on
the Architecture Tradeoff Analysis Method - ATAM
as a guide and proposes the requirements for a toll
to be used for architecture evaluation and the
traceability between components and artifacts.
Index Terms—Architecture Tradeoff Analysis
Method ATAM, Qualitative evaluation of software
architecture .
I. INTRODUCTION
The structure of a software system reflects its
architecture. Each system has an architecture, whether
achieved in a planned or an unplanned manner. A
high-quality architecture is the key aspect of the
success of any development project. Software
architecture is an “intellectually graspable” abstraction
of a complex system[1]. Architectural decisions have a
great impact on the consequent quality of software
systems. As a result, it is important to evaluate how
the designed software architecture meets its quality
demands. It gives a basis for analysis of software
systems' behavior before the system has been built [5].
The ability to verify that a future software system
fulfills it stakeholders' needs without actually having
to build it represents substantial cost-saving and risk-
mitigation [6]. Architectural views are models of
architectural structures or other elements of a software
architecture. Architects use views throughout the
architecture lifecycle for the specific purpose of
understanding and analyzing the different aspects of
system development and performance. The major
characteristic of a view is its purpose and utility.
Views are not complete descriptions of the software
architecture. Often views omit otherwise important
architectural information in order to be useful for their
specific purpose. The major issue with the views is
consistency with the system rather than completeness.
Architectural views are a necessary part of any
architecture and serve as a way to design architectural
structures and to understand different aspects of
system design. But it is difficult to ensure the
relationship between these views and the strategic
business objectives that a system should cover.
Aiming to improve the effectiveness of systems
architecture to try to achieve the quality desired by
customers, some techniques have been developed to
perform architectural analyses and qualitative
evaluation, like ATAM. The motivation to define and
describe requirements for a tool that supports
Qualitative Evaluation of Software Architecture is that
conflicts often occurs in the delivery stage of new
systems. Very often, while delivering a new developed
system, it meets the described requirements but did
not meet the expectations of customers in terms of:
functionality, reliability, usability, efficiency,
maintainability, and portability. Too often, systems are
released with performance issues, security risks, and
availability problems as a result of inappropriate
decisions. Architecture evaluation is an early risk
reduction method [2]. The architectures were defined
early in the project life cycle, but the resulting flaws
were discovered much later. The most significant
benefit of qualitative evaluation is to reassure
stakeholders that the candidate architecture is capable
of supporting the current and future business
objectives; specifically, it can meet its functional and
nonfunctional requirements. The quality attributes of a
system such as performance, availability, extensibility,
and security are a direct result of its architecture;
therefore, quality cannot be introduced easily to your
system late in the game. A qualitative evaluation of the
architecture while it is still a candidate specification
Requirements for quality evaluation of
software architecture
Joao C. Albuquerque
Hochschule Furtwangen University
Fakultät Informatik
Robert-Gerwig-Platz 1
78120 Furtwangen, Germany
E-mail: joao.albuquerque@hs-furtwangen.de

2. - 2 -
can reduce project risk greatly. What is the
importance of evaluating the architecture in the early
stage of a software project? The architecture
evaluation will not produce answers such as yes or no.
It will point out risks and also help to map out which
components support defined customer needs,
limitations or features. The sooner the risks or
weaknesses are identified, the lower the cost to re-
evaluate the solution and change the project in part or
in whole. There are currently few well-defined and
mature to qualitatively evaluate the architecture of a
software design methods:
SAAM – Software Architecture Analysis Method,
Target: changeability and extensibility,
ALMA – Architecture-Level Modifiability
Analysis, Target: Changeability,
PASA – Performance Assessment of Software
Architectures , Target: Efficiency and
Performance,
ATAM – Architecture Tradeoff Analysis Method,
Target: system-relevant quality attributes.
One reason for the choice of methodology for
evaluating the quality of software: Architecture
Tradeoff Analysis Method ATAM [4] was to be the
one that best drives for architecture design and it’s
relationships with quality attributes. It is a method for
evaluating software architectures relative to quality
attribute goals. ATAM evaluations expose
architectural risks that potentially inhibit the
achievement of an organization's business goals. The
ATAM gets its name because it not only reveals how
well an architecture satisfies particular quality goals,
but it also provides insight into how those quality
goals interact with each other, how they trade off
against each other. The ATAM is the leading method
in the area of software architecture evaluation. This
also means that: the system proposed in this paper
serve to support quality assessment using ATAM. In
other words, it supports and documents the nine steps:
1-Present the ATAM. 2-Present business drivers.
3-Present architecture focusing on how it addresses
the business drivers. 4-Identify architectural
approaches. Architectural approaches are identified by
the architect, but are not analyzed. 5-Generate quality
attribute utility tree. The quality factors are elicited,
specified down to the level of scenarios and
prioritized. 6-Analyze architectural approaches.
Based on the high-priority factors identified in Step 5,
the architectural approaches that address those factors
are elicited and analyzed. During this step,
architectural risks, sensitivity points, and tradeoff
points are identified. 7-Perform brainstorm meeting to
prioritize scenarios. 8-Analyze architectural
approaches. 9-Present results based on the information
collected in approaches, scenarios, attribute-specific
questions, the utility tree, and risks. Software
reliability evaluation mainly includes the quantitative
evaluation and qualitative evaluation. Both can be
summarized as follows: quantitative evaluation is
more accurate because it is based on metrics and
mathematical formulas that numerically may rank the
degree of complexity, interdependence, coupling
among others. But there is a condition so that it can be
applied. The software code must be implemented in
order to be evaluated. In other words , it is an accurate
method of assessment, but it can be used only after
implementation. On the other hand, the qualitative
assessment do not provide accurate answers but it can
be performed early in the hole process (after
requirements and architecture definition and before
implementation, tests and delivery), before many
mistakes and omissions had consumed resources, time
and customer patience unnecessarily. Risks can be
identified and avoided or mitigated previously.
Moreover, the process involves a high degree of
communication between stakeholders in the system,
sponsors and development teams. This undoubtedly
improves the degree of refinement of the quality
requirements and can be pre- set in the architecture of
the software project to end the increasing degree of
satisfaction with the product delivered. These
features, advantages and challenges lead to interest to
research and develop standards and requirements to
facilitate its implementation. Many problems in
software systems are directly related to the
specification and design of quality attributes such as
modifiability or performance, to name just a few.
Quality attributes have a main influence on customer
and end user acceptance. To address them in a
systematic and appropriate way is an important but
challenging endeavor. Quality attributes are difficult to
handle, because they need to be treated differently and
typically affect not only parts of a system but the
system as a whole. For example, engineers can’t
constrain security or performance attributes to one
single place in the system. Such attempts turn out to
be impossible in most contexts, because the concerns
are cross-cutting and often even invasive, that is, they
require software engineers to inject design and code
into existing components. With other words, most
quality attributes are systemic and need global and
strategic treatment. The benefits from performing an
quality evaluation are: improved software architecture
documentation, formulate a documented foothold for
architectural decisions, make clear quality attribute
requirements, to pinpoint risks at early stage, when the
budget for implementation has not been exhausted and
improves communication between stakeholders
avoiding misunderstandings and omissions.

3. - 3 -
II.PREVIOUS RESEARCHES ARTICLES ON THIS TOPIC
Some studies and researches were already made to
drill an Qualitative Evaluation tool Software
Architecture such as: [2] and [3]. Papers that also refer
to the ATAM method [1]. In the software market are
several products for mapping requirements and
components of a project. There are good solutions that
document and address traceability between: customer
requirements, architecture view, functional modules
and implementation units. In some documentation
tools, architectural attributes are referred as
functionality limitations or obligations such as
maximum response time, maximum number of
concurrent users, growth rate of the stored data but
these are just limitations. Another researched tool was
the: IBM-Rational-Quality-Manager. This is a web
application that enables to track aspects of the quality
assurance. The central artifact in this tool is a test plan
that contains information, such as goals, schedules,
milestones as well as links to associated test cases,
requirements and development items. Rational Quality
Manager includes manual test authoring and
execution, test lab management, test execution,
reporting and defect management. It was designed as a
replacement for IBM Rational Manual Tester, IBM
Rational ClearQuest Test Manager, and Rational
TestManager. An Overview of Rational Quality
Manager functions: The test plan defines the
objectives and scope for the test effort and help teams
to answer to the question: Are we ready to release a
new software version? The advantages and features
are: It can be used to define business and test
objectives, establish a review and approval process,
manage project requirements and establish the inter
dependencies between the two, define quality goals,
create and manage test cases, a test case can include
links to development items and requirements. The
relationship between test artifacts, requirements, and
development artifacts can be traced by the traceability
view. The most frequently reported disadvantages are:
there is no reference manual that describes the
functionality. The standard reports in the reporting
section are not customizable and have a plain appeal,
there is no standard report to requirements, test cases
and execution result on the same sheet. In summary,
despite the name suggest being a quality manager, in
fact it is a test manager. What is an important activity,
but does not address the issue of evaluating
architectural software quality. Considerable research
has been devoted to relating requirements and with
source code. Less attention has been paid to relating
requirements with architecture quality. Traces between
requirements with architecture might be manually
assigned and might be incomplete. The impact of
requirements changes on other requirements, design
elements and source code can be traced to determine
parts of the software to be changed. In this research
were identified features in tools traditionally used for
requirements traceability and documentation of
architecture, which in its new versions are already
references the explicit all stakeholder requests and
their attributes. Already a long way towards avoid
losing customer focus. These characteristics have been
described as some recent studies [8] Referencing
solutions that are market leaders as IBM RequisitePro.
Traceability benefits are: prioritizing requirements,
estimating change impact, proving system
understanding supporting design decisions, validating,
and more. [9] But the focus of these solutions is not to
evaluate whether the architecture is good enough to
meet business goals. Yes, there are other market
leaders with consultancy which propose this
Qualitative Evaluation, but, in some cases, the
solution behind this consulting is the migration to
proprietary complete solutions. In other words, they
evaluate the solutions made in house, point out flaws
and weaknesses and recommend throwing away years
of experience replacing by an in-a-box ERP solution
that ensure architectural quality features. But the price
of these solutions may not be within reach of most
small and medium sized companies or create
technological dependence by monthly subscription
agreements. Migrating to these new solutions involves
training to all employees, initial loss of productivity,
data migration can not always be perfect done and
among other problems. In our literature research, other
tools [3], [4] showed an efficient architectural
qualitative evaluation. However the focus of the tool
proposed in this paper is that the qualitative evaluation
of the architecture should be traceable on the
respective requirements and implementation units. In
this study we aim to assess: how far traditional tools
for mapping requirements and design architecture can
be exploited to allow adoption of the features for
evaluating the quality of software architecture. Thus
the proposed solution can be compared with
established products on the market such as IBM
Rational described at figure 3 and so we will have a
feasibility study of our proposal. After all, a new
Software proposal only makes sense if there really still
this gap in the market (the loose coupling between
architecture design approaches and system quality
attributes are seen as major weak points) and from
solutions who are able to (identifying essential
requirements for creating a sustainable architecture
that permit achieving the business goals) pointed by
previous studies. [3].

4. - 4 -
III. REQUIREMENTS PROPOSAL
There is a big risk of projects being designed, meet
all documented requirements but contain risks and do
not meet the expectations of its sponsors. How can
we prove to the sponsors that the solution will meet
characteristics like: Functionality, Suitability,
Security, Interoperability, Reliability, Fault Tolerance,
Recoverability, Usability, Understandability,
Learnability, Operability, Attractiveness, Efficiency,
Maintainability, Changeability, Stability, Portability,
Co-Existence? Given this gap, this paper attempts to
describe a tool that can assist in this evaluation of
software architecture and mapping traceability
between these architectural attributes and components
of reported software. The identified risks should be
associated with components that address the problem.
Thus quality assessment and improvement points may
apply corrective measures with less effort and greater
assertiveness. The features: Initially the software
should be designed to be performed during a
presentation to stakeholders. After presenting the
concept of ATAM to the stakeholders some Business
Drivers are being raised and may already be filled in
the system to continue the survey of the major
Business Drivers. Then it should open a screen to fill
the summarized description of the major Business
Drivers. Third step: the toll should then open a screen
to fill the summarized description of architecture
solutions. This description should be focused on: how
it addresses the business drivers. This step will be best
understood by everyone if you could include not only
the textual description but also images, charts, or
diagrams regarding the architecture associated with
text description. Each entry of this step should be
linked with one or more from step above. The
Architecture is usually described by using the logical
view and it is concerned with the functionality that the
system provides to end-users. UML Diagrams used to
represent the logical view include Class diagram,
Communication diagram, and Sequence diagram. The
development view illustrates a system from a
programmer's perspective and is concerned with how
the solution is modularized and the software
management. This view is also known as the
implementation view. It uses the UML Component
diagram to describe system components. UML
Diagrams used to represent the development view
include the Package diagram. The process view deals
with the dynamic aspects of the system, explains the
system processes and how they communicate, and
focuses on the runtime behavior of the system. The
process view addresses concurrency, distribution,
integrators, performance, and scalability, etc. UML
Diagrams to represent process view include the
Activity diagram. The physical view depicts the
system from a system engineer's point-of-view. It is
concerned with the topology of software components
on the physical layer, as well as the physical
connections between these components. This view is
also known as the deployment view. UML Diagrams
used to represent physical view include the
Deployment diagram. Scenarios: The description of
architecture may be illustrated using a small set of use
cases, or scenarios which become a fifth view. The
scenarios describe sequences of interactions between
objects, and between processes. They are used to
identify architectural elements and to illustrate and
validate the architecture design. They also serve as a
starting point for tests of an architecture prototype,
and it’s also called as “use case view”. The proposed
the logical data model for this tool is described at
figure 1.
Figure 1 – Logical Data Model
Requirements typically define what a system should
do, but rarely define how it should be done. How fast
how secure how easy how modifiable, how portable
and so on. To help participants elicit the most
important features for their business, a database of
pre-defined questions that refer to issues of quality,
features and limitations should be used, described at:
Table 1 - Software Architecture Quality Survey.
For each question there are answer options according
to the degree of importance of this feature for
business. The choice of these answers will help
identify project risks. And consequently, will facilitate
the stakeholders understanding of the relationship of
each risk with the software components on dealing
with this functionality. To accelerate the meetings,
the data tables containing the main software
components designed in architecture or
implementation units for the application can be pre-
registered by the development team. In the same way,
the tables of questions and answers should previously
contain to the most common situations on business
needs like: how long should a new feature be ready to
market. restrictions about response time, volume of
data stored in the system, time required for system
changes, ease of users' learning, number of concurrent
users, availability (24h x 7d) or (8h x 5d) and so on.
From this point can be performed the step 5 from
ATAM [4]- by conducting the brainstorm meeting to
identify and prioritize the system’s most important
quality attribute goals. Here must be a way to focus
the attention of stakeholders on the architectural
solutions that are most critical to the system’s success.
And so can be successfully described the Quality
attribute utility tree on figure 2.

5. - 5 -
Figure 2 – Quality attribute utility tree
The scenarios are the most important part of the utility
tree, the main reason is that the scenarios help us
understand the quality attributes needed, and more
importantly, by tying the attributes to real instances in
the system the scenarios help make these goals both
concrete and measurable. Scenarios specification:
First - Scenarios should be as specific as possible.
Scenarios should cover a range of:
Anticipated uses of the system - what happens
under normal use
Anticipated changes to where is expected the
system to go and develop
Unanticipated stresses to the system.
Scenarios are basically statements that have a context
a stimulus and a response and describe a situation in
the systems where the quality attribute manifests
itself.
Context - under what circumstances
Stimulus - trigger in Use case
Response - what the system does.
For example: under normal operation, perform a
database transaction in under 100 milliseconds.
Remote user requests a database report during peak
period and receives it within 5 seconds. Add a new
data server to reduce latency in scenario 1 to 2
seconds within 1 person-week. An intrusion is
detected, and the system cannot lock the doors. The
system activates the electromagnetic fence so that the
intruder cannot escape. For a new release, integrate a
new component implementation in three weeks. Half
of the servers go down during normal operation
without affecting overall system availability. Under
normal operations, queuing orders to a site which is
down, system suspends within 10 minutes of first
failed request and all resources are available while
requests are suspended. Distribution to others is not
impacted. By adding hardware alone, increase the
number of orders processed hourly by a factor of ten
while keeping the worst-case response time below 2
seconds. If we take one of these: An intrusion is
detected, and the system cannot lock the doors. The
system activates the electromagnetic fences so that the
intruder cannot escape:
The stimulus - An intrusion is detected
Context - the system cannot lock the doors
Response - the system activates fences.
Or another one (Half of the servers go down during
normal operation without affecting overall system
availability)
Stimulus - Half the servers go down
Context during normal operation
Response - without affecting overall.
The next step is prioritizing scenarios by evaluating:
Importance to Business Goals
(High, Medium, Low attributes)
Difficulty or Risk in achieving
(High, Medium, Low attributes)
The interesting scenarios are the ones with high
priority. To help clarifying those scenarios and
identifying risks the common survey / answers table
should be used. The usefulness of the questions table
is the enrichment of brainstorming, avoiding that
crucial issues are forgotten or pass unnoticed, hence
the importance of linking their response to a risk. The
purpose of connecting all the steps and prioritize
needs is that: at the end of filling all data in the
respective tables this tool will be able to generate a
report with the rankings of architectural solutions and
their components that support the main business goals.
And if any identified risks have not been addressed by
any solution, this will be highlighted as risks
untreated. Each question should be as generic related
as possible but it should address one software quality
topic or sub characteristics detailed on Figure 3 [10].
This means that, in order to help stakeholders to elicit
detailed information about their business drivers who
should be treated by the system they will try to answer
if each of those questions impacts their expectations
about the characteristics of the software project being
evaluated referring to each of the above described
quality feature or attribute If some questions receive
responses with a high degree of importance to the
strategic business goals and those still not have
structures to handle it´s needs, then new risks
classified as untreated should be detailed in the project
documentation. This will highlight points of
architecture where there is a failure and need to be
improved.
Figure 3-ISO 25010 - Software product quality model
In the new model for software quality in the draft
ISO/IEC CD 25010 standard, the concept of quality in
use has been broadened to embrace a wider range of
issues than was common in usability. The term
flexibility has been added to refer to the need for
usability in both planned and unplanned contexts of

6. - 6 -
use and the need for usability for people with special
needs. Flexibility can also include learnability, or how
quickly and effectively a user interface can be learned.
The standard also makes a distinction between
usability from different stakeholder perspectives that
result in different types of measures, including from
the perspective of the end user achieving personal
goals, the perspective of the organization achieving
organizational goals, and the perspective of technical
support achieving maintenance goals.
Functional suitability
The degree to which the software product provides
functions that meet stated and implied needs when the
software is used under specified conditions.
Appropriateness - The degree to which the software
product provides an appropriate set of functions for
specified tasks and user objectives.
Accuracy - The degree to which the software product
provides the right or specified results with the needed
degree of precision.
Functional suitability compliance - The degree to
which the software product adheres to standards,
conventions or regulations in laws and similar
prescriptions relating to functional suitability.
Reliability
The degree to which the software product can
maintain a specified level of performance when used
under specified conditions.
Availability - The degree to which a software
component is available when required for use.
Fault tolerance - The degree to which the software
maintain a level of performance in cases of software
faults or of infringement of its specified interface.
Recoverability - The degree to which the software
product can re-establish a specified level of
performance and recover the data directly affected in
the case of a failure.
Reliability compliance - The degree to which the
software product adheres to standards, conventions or
regulations relating to reliability.
Performance
The degree to which the software product provides
appropriate performance, relative to the amount of
resources used, under stated conditions.
Time behavior
The degree to which the software product provides
appropriate response and processing times and
throughput rates when performing its function, under
stated conditions.
Resource utilization
The degree to which the software product uses
appropriate amounts and types of resources when the
software performs its function under stated conditions.
Performance efficiency compliance
The degree to which the software product adheres to
standards or conventions relating to performance
efficiency.
Operability
The degree to which the software product can be
understood, learned, used and attractive to the user,
when used under specified conditions.
Appropriateness recognisability - The degree to which
the software product enables users to recognize
whether the software is appropriate for their needs.
Learnability - The degree to which the software
product enables users to learn its application.
Ease of use - The degree to which the software makes
it easy for users to operate and use it.
Helpfulness - The degree to which the software
product provides help when users need assistance.
Attractiveness - Degree to which the software is
attractive to the user.
Technical accessibility - The degree of operability of
the software for users with specified needs.
Operability compliance - The degree to which the
software product adheres to standards, conventions,
style guides or regulations relating to operability.
Security
The protection items from accidental or malicious
access, use, modification, destruction, or disclosure.
Confidentiality - The degree to which the software
provides protection from unauthorized disclosure of
data or information, whether accidental or deliberate.
Integrity - The degree to which the accuracy and
completeness of assets are safeguarded.
Non-repudiation - The degree to which actions or
events can be proven to have taken place, so that the
events or actions cannot be repudiated later.
Accountability - The degree to which the actions of an
entity can be traced uniquely to the entity.
Authenticity - The degree to which the identity of a
subject can be proved to be the one claimed.
Security compliance - The degree to which the
software product adheres to standards, conventions or
regulations relating to security.
Compatibility
The ability of some software components to exchange
information and/or to perform their required functions
while sharing the same hardware or environment.
Replaceability - The degree to which the software
product can be used in place of another specified
software product for the same purpose in the same
environment.
Co-existence - The degree to which the software
product can co-exist with other independent software
in a common environment sharing common resources
without any detrimental impacts.
Interoperability - The degree to which the software
product can be cooperatively operable with one or
more other software products.
Compatibility compliance - The degree to which the
software product adheres to standards, conventions or
regulations relating to compatibility.
Maintainability
The degree to which the software product can be
modified. Modifications may include corrections,
improvements or adaptation of the software to

7. - 7 -
changes in environment, and in requirements and
functional specifications.
Modularity - The degree to which a system or
computer program is composed of discrete
components such that a change to one component has
minimal impact on other components.
Reusability - The degree to which an asset can be used
in more than one software system, or in building other
assets.
Analyzability - The degree to which the software
product can be diagnosed for deficiencies or causes of
failures in the software, or for the parts to be modified
to be identified.
Changeability - The degree to which the software
product enables a specified modification to be
implemented. The ease with which a software product
can be modified.
Modification stability - The degree to which the
software product can avoid unexpected effects from
modifications of the software.
Testability - The degree to which the software product
enables modified software to be validated.
Maintainability compliance - The degree to which the
software product adheres to standards or conventions
relating to maintainability.
Transferability
The degree to which the software product can be
transferred from one environment to another.
Portability - The ease with which a system or
component can be transferred from one hardware or
software environment to another
Adaptability - The degree to which the software
product can be adapted for different specified
environments without applying actions or means other
than those provided for this purpose for the software
considered.
Installability - The degree to which the software
product can be successfully installed and uninstalled
in a specified environment.
Transferability compliance - The degree to which the
software product adheres to standards or conventions
relating to portability.
Figure 4-ISO 25010 - Quality model for quality in use
Quality in use [10] is the degree to which a product
used by specific users meets their needs to achieve
specific goals with effectiveness in use, efficiency in
use, flexibility in use, safety and satisfaction in use in
specific contexts of use. Quality in use is a measure of
the quality of the system in a real or simulated
operational environment. It is determined by the
quality of the software, hardware, operating
environment, and the characteristics of the users, tasks
and social environment. All these factors contribute to
quality in use. Quality in use can be used to assess the
quality of software in a specific context of use. The
attributes of quality in use are categorized into three
characteristics:
Usability in use evaluates the degree to which
specified users can achieve specified goals with
effectiveness in use, efficiency in use and
satisfaction in use ;
Flexibility in use evaluate the degree to which the
product is usable in all potential contexts of use;
Safety deals with acceptable levels of risk of
harm to people, business, data, software, property
or the environment in the intended contexts.
SUMMARY AND OUTLOOK
Comparing the data model and the list of
requirements proposed in this article it was noted that
the RequisitePro tool can be efficiently adapted to
support an architecture quality review following the
steps proposed by ATAM methodology. In other
words, a template for this tool can be developed
containing documents standards, and types of
attributes with their respective links of influence and
traceability matrix, with the facility to generate a
quality attribute scenario. With the ease that the tool
already has the ability to rank of each document
attribute, the prioritization of business drivers,
prioritization of scenarios can be taken using the:
Attributes Tab
Priority (High, Medium, Low)
Status (Proposed, Approved, Implemented,
Tested, Discarded)
Difficulty (High, Medium, Low)
Stability (High, Medium, Low)
Origin
Cost (High, Medium, Low)
Defect
Figure 5 – Features from IBM RequisitePro
And other attributes related do the ATAM evaluation
may be created at the project properties figure 5 like
risk, quality attribute, relevance, security challenge,
and so on. On this way, it can not only documenting
the requirements and architecture of the software but
also make a qualitative assessment of both the
architecture initially proposed, as well as in future
developments of the software in question, but also

8. - 8 -
support and connect all evaluation steps. One
advantage is to be done in the same tool already
known and used worldwide.
The Requisite Tool integrates not only the Microsoft
Word text editor on any version. The matrix of
attributes and traceability is saved in an MDB
database file Microsoft Access database that can be
versioned along with the project providing version
control type. But SQL Server can also be used to save
the project and its attributes and traceability. There is
also the option to link the requirements artifacts and
architectural design activities with a project on the
timeline of Microsoft Project. The architectural views
are also easily integrated with Rational ROSE for
designing UML diagrams and use cases. Of course
there are disadvantages to. Companies that do not use
this tool to document their projects would need to
invest in license that has a manufacturer's suggested
price is U.S. 2740 per seat and also the disadvantage
of having to re-type the requirements already
documented in another management tool. Another
disadvantage is that tool is not intended to be a web
application, so that the evaluation and meetings are
only effective if they are face. Files can not be
renamed after they are created, so it must be
previously standardize the naming of artifacts. There
is no way to be easily implemented in world wide
collaborative work using clouds like "GoogleDocs"c.
When a new document is added to the project, all
project users must manually update the project to
contain this new document on his views. Each project
document can be edited by one user at a time, while
other users can open in read-only mode. The
characteristic of merging concurrent edits in the same
document does not always work if both users type in
the same sections of the document.
The proposed: requirements in this article, the steps of
the methodology, the prioritization of attributes and
their subsequent raking could be implemented in the
tool Rational Requisite Pro elaborating a template
shown on figure 6, so users, stakeholders and
developers can use a relatively simple and common
platform to conduct the evaluation of the architecture
of a software project after the requirements and
proposed software architecture design step. The
traceability matrix is customizable in requisite pro.
This means that is possible to create many different
views with different hierarchies. So, the relationships
described in the proposed data model can be
implemented easily. In other words, it is possible to
start a new view it from the risks and detail down to
the components that address the risk. This manner
evidences risks that remain to be addressed. Another
view can start the business drivers and get down to the
scenarios and the architecture view. Each change is
automatically pointed as the impact on the system.
And so, before start coding and implementing, it is
possible to evaluate that the final product will not only
meet requirements, but increase stakeholders
satisfaction, because it was possible to evaluate the
expected quality and ensure traceability between e
points defined and the delivered solution.
REFERENCES
[1] Clements, Paul, Rick Kazman, and Mark Klein.
“Evaluating software architectures”. Reading:
Addison-Wesley, 2012.
[2] Thiel, Steffen, Andreas Hein, and Heiner
Engelhardt. “Tool Support for Scenario-Based
Architecture Evaluation”. STRAW. p. 41-45., 2003.
[Online]. Available:
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.
1.1.145.6491&rep=rep1&type=pdf#page=47
[3] Thiel, Steffen. “A framework to improve the
architecture quality of software intensive systems.”
Diss. Universität Duisburg-Essen, Fakultät für
Wirtschaftswissenschaften, 2005. [Online]. Available:
duepublico.uni-duisburg-
essen.de/servlets/DerivateServlet/Derivate-
13645/Dissertation_Thiel.pdf
[4] Kazman. Rick, Klein. Mark, and Clements. Paul,
"ATAM: Method for Architecture Evaluation,"
Software Engineering Institute, Carnegie Mellon
University, Pittsburgh, Pennsylvania, Technical Report
CMU/SEI-2000-TR-004, 2000. [Online].
Available: resources.sei.cmu.edu/library/asset-
view.cfm?AssetID=5177
[5] Perry, D. E.; Wolf, A. L. "Foundations for the
study of software architecture". ACM SIGSOFT
Software Engineering Notes, 1992
[6] SARA Work Group "Software Architecture
Review and Assessment (SARA) Report ". 2012
Available
kruchten.com/philippe/architecture/SARAv1.pdf
[7]Alan M. Davis “Software Requirements –
Analysis and Specification,” Prentice Hall, 1990.
[8]Arda Goknil, Ivan Kurtev, Klaas Van Den Berg,
Generation and validation of traces between
requirements and architecture based on formal
trace semantics, Journal of Systems and Software,
Volume 88, February 2014, Pages 112-137,
Available http://dx.doi.org/10.1016/j.jss.2013.10.006
[9] Stefan Winkler and Jens Pilgrim. A survey of
traceability in requirements engineering and model-
driven development. Softw. Syst. Model. 9, 4 2010.,
Pages 529-565.
Available http://dx.doi.org/10.1007/s10270-009-0145-0
[10]ISO/IEC CD 25010 . Systems and software
engineering—Software product Quality Requirements
and Evaluation (SQuaRE)—Software product quality
and system quality in use models. 2009
Avaliable:
sa.inceptum.eu/sites/sa.inceptum.eu/files/Content/ISO_25010.pdf

9. - 9 -
Figure 6 – New Template - View for IBM RequisitePro

10. - 10 -
Table 1 - Software Architecture - Quality Attributes Survey
Functional suitability Does the presented software architecture provide functions that meet stated and implied needs?
□ Yes – □ No default answer form
Level of Importance
□ Low □ Average □ High □ Very important
Risk □ No □ Yes □ New Risk
New Risk Description [ ]
o Appropriateness Does the presented software architecture provide an appropriate set of functions for all
specified user objectives?
o Accuracy - Does the presented software architecture provide the expected results with the needed precision?
o Functional suitability compliance - Does the presented software architecture adhere to standards, conventions
or regulations in laws relating to Functional Suitability?
Reliability - Does the presented software architecture convince it can maintain a specified level of performance when used
under specified conditions? IOr - Where are the weaknesses?
o Availability - Does the presented software architecture provide available when required for use?
o Fault tolerance - The degree to which the software maintain a level of performance in cases of software faults or
of infringement of its specified interface?
o Recoverability - The degree to which the software can re-establish a specified level of performance and recover
the data directly affected in the case of a failure?
o Reliability compliance - The degree to which the software adheres to standards, conventions or regulations
relating to reliability?
Performance Does the presented software architecture provide appropriate performance, under stated conditions?
o Time behavior The proposed system is design to provides appropriate response and processing times and
throughput rates when performing its function, under stated conditions?
o Resource utilization - How well the software uses appropriate amounts and types of resources when the
software performs its function under stated conditions?
o Performance efficiency compliance - The proposed system is designed to adheres to standards or conventions
relating to performance efficiency?
Operability - How well can the proposed software design be understood, learned, used?
o Appropriateness recognisability - How well enables the software enables users to recognize whether the
software is appropriate for their needs ?
o Learnability - How well the proposed system is design enables users to learn its application?
o Ease of use - How well the proposed system is design makes it easy for users to operate and use it?
o Helpfulness - How well the proposed system is design provides help when users need assistance?
o Attractiveness - How well the software product is or will be attractive to the user?
o Technical accessibility – Is it appropriate the degree of operability for users with specified needs?
o Operability compliance - How well the software adheres to standards, conventions, style guides or regulations
relating to operability?
Security - How well protected are items from accidental or malicious access, modification, destruction or disclosure?
o Confidentiality - How well the software provides protection from unauthorized disclosure of data or information,
whether accidental or deliberate?
o Integrity - How well the accuracy and completeness of assets are safeguarded?
o Non-repudiation - How well actions or events can be proven to have taken place, so that the events or actions
cannot be repudiated later?
o Accountability - How well the actions of an entity can be traced uniquely to the entity?
o Authenticity - How well the identity of a subject can be proved to be the one claimed?
o Security compliance - How well does the software adheres to standards or regulations relating to security?
Compatibility - Are some software components able to exchange information or to perform their required functions while
sharing the same hardware or environment?
o Replaceability - The proposed system is designed to enable be used in place of another specified software for
the same purpose in the same environment?
o Co-existence - How well the software can co-exist with other independent software in a common environment
sharing common resources without any detrimental impacts?
o Interoperability - How well the software can be cooperatively operable with one or more other software
products?
o Compatibility compliance - The proposed system is designed to adheres to standards, conventions or
regulations relating to compatibility?
Maintainability - How complicated, time consuming, expensive and difficult it is to be performed maintenance, alterations
and development of new features in this software product? Modifications may include corrections, improvements or
adaptation of the software to changes in environment, and in requirements and functional specifications?

11. - 11 -
o Modularity – The proposed system is designed to be build of discrete components such that a change to one
component has minimal impact on other components?
o Reusability - The proposed system is designed to enable features being used in more than one software system,
or in building other assets?
o Analyzability - How well the proposed system design can be diagnosed for deficiencies or causes of failures in
the software, or for the parts to be modified to be identified?
o Changeability - How well the proposed system design enables a specified modification to be implemented? Will it
be easy to modify parts of the implemented software?
o Modification stability - How well the proposed system design can avoid unexpected effects from modifications of
the software?
o Testability - How well the proposed system design enables modified software to be validated?
o Maintainability compliance - How well the proposed system design adheres to standards or conventions relating
to maintainability?
Transferability - How complicated, time consuming, expensive and difficult it is to transfer the software from one
environment to another and set it to be fully operational?
o Portability – Is it easy the whole system be transferred from one hardware or software environment to another?
o Adaptability – Can the proposed system design be adapted for different specified environments without applying
actions or means other than those provided for this purpose for the software considered?
o Installability - Can the proposed system design can be successfully installed and uninstalled in a specified
environment?
o Transferability compliance - Does the software adheres to standards or conventions relating to portability like
older versions of Operating System, or different languages configured at the host operating system ?
Quality in use - Can the proposed system design be used by users and meets their needs to achieve specific goals with
effectiveness, efficiency, flexibility, safety and satisfaction in use?
Usability in use - How well the proposed system design enables specified users to achieve specified goals with
effectiveness in use, efficiency in use and satisfaction in use?
Flexibility in use How well the proposed system design enables to be usable in all potential contexts of use;
Safety How well the proposed system design deals with acceptable levels of risk of harm to people, business, data,
software, property or the environment in the intended contexts?