I recommend you consider each of the NFRs shown below and rank them in order of importance to your enterprise. Each NFR is ranked with a range that goes from a “0” represents a quality that no effort is to be spent on—to—a “10” representing a quality that must be included even if it means additional cost and significantly delaying the release of the system. A “1” represents an optional, nice-to-have, feature. There should be only a few qualities set at “9” or “10”.
Business Qualities |
|
Affordability: The
ability to build the system with minimum development cost in labor and
tools.
|
|
Time-to-Market: The
ability to build the system in the minimum amount of time and ahead of
competition for the similar functionality.
|
|
Functionality: The
ability of the system to perform all the business tasks it was created to do
per the user’s requirements.
|
|
Regulatory Compliance: Adheres to
governmental regulations.
|
|
Buildability: Whether or
not the architecture can reasonably be built using the budget, staff, and
time available for delivery of the project.
Buildability is an often-overlooked quality attribute. Sometimes, the best architects are simply
too ambitious for a project team to complete given project constraints and
environment. The design that casts a
solution in terms of well-understood concepts is more buildable than a
design that introduces new concepts.
|
User Qualities |
|
Usability: How easy
it is for the user to understand and operate the system. Usability can be broken down into the
following areas:
|
|
Gratification: The
ability to anticipate the needs of the user and give more than is
asked. Most systems give only what
the user specifies and requires the user to expend significant effort in
stating the request. A system with
gratification learns the user’s habits and preferences, and intervenes with
quick solutions or alternatives when the user does not appear to making
progress.
|
|
Localization: The
ability easily adapt to multiple languages and locales.
|
|
Personalization: The
ability of a user to adapt the look and feel of the system to their own
taste.
|
|
Customer Compliance: Adheres to
the interfaces, data structures and conventions of the customer’s systems
without requiring modifications of their systems.
|
|
Accuracy: Ability to
provide the right or agreed results or effects with the needed degree of
precision. Includes the ability to
resist or correct poor data quality.
|
|
Mobility: Ability to
support mobile devices and cellular communications.
|
Administrator Qualities |
|
Manageability: Can be
expressed in terms of how easy it is to monitor a system and detect
operational characteristics related to performance and failures, how easy it
is to configure systems, the processes used for effecting this control, and
the degree to which the system can be managed remotely.
|
|
Administrability: Can be
expressed in terms of how easy it is to configure an application and detect application
characteristics related to functional usage, how easy it is to configure the
application, the processes used for effecting this control, and the degree
to which the application can be administered by multiple parties in
cooperating roles.
|
|
Data Location Transparency: The
business logic layer of the application does not know the physical location
of the data. The data may be
distributed to multiple locations at sites determined by the DBAs and
administrators for tuning, fail-over, and storage resource control.
|
|
Component Location Transparency: A client
does not know where a target server object resides. It could reside in a
different process on another machine across the network, on the same machine
but in a different process, or within the same process. Different components can be distributed
over multiple machines, or, copies of the same component can be distributed
over multiple machines.
|
|
Implementation Transparency: A client
neither knows how a target object is implemented, what programming or
scripting language it was written in, nor the operating system and hardware
it executes on. This is also a
security issue.
|
|
Hardware Virtualization: The
application may be moved unchanged as compiled from the testing to the
operational environment and across multiple hardware environments. VMware is an example of such an approach.
|
|
Object (Server) State Transparency: When a client makes a request on a target server
object, it does not need to know whether that object is currently activated
(i.e. in the executing state) and ready to accept requests or not. The ORB
transparently starts the object if necessary before delivering the request
to it. This feature greatly helps recovery handling for distributed objects.
|
|
Communication Mechanism Transparency: A client does not know what communication
mechanism (e.g., TCP/IP, shared memory, local method call, etc.) the ORB
uses to deliver the request to the object and return the response to the
client. Multiple communication
strategies may be statically or dynamically set.
|
|
Security: The
ability of the system to resist unauthorized attempts to access the system
and denial-of-service attacks while still providing services to authorized
users. Includes levels of
authentication supported, granularity of authorization controls, and techniques
utilized to ensure the integrity of resources.
|
|
Auditability: The
ability to ensure that the previous system states can later be reconstructed
and observed. Includes recording and
analyzing activities to detect intrusions or abuses.
|
|
Accountability: The
ability to ensure that the ultimate causes of the previous system states can
later be identified. The ability to
know who did what.
|
|
Confidentiality: keeping information secret only to those who are
authorized to see it.
|
|
Anonymity: concealing the identity of an entity involved in
a process.
|
|
Privacy: Ability to
follow business rules in regard to the rights and responsibilities that
govern the acquisition, disclosure, and use of personal information.
|
|
Data Integrity: ensuring information has not been altered by
unauthorized means.
|
|
Data Authentication: corroborating the source of data
|
|
Access Control: restricting access to resources to authorized
entities.
|
|
Non-Repudiation: The
ability to provide legally accepted proof that a user executed a particular
transaction, even if they deny having done it. Must be able to discriminate against
spoofing and man-in-the-middle attacks.
|
Qualities of Service |
|
Quality of Service (QoS): The
ability to measure and stay within the guaranteed performance and
availability limits for contracted services per
|
|
Scalability: The
ability for the system to grow linearly by adding hardware as the number of
users and transactions increase beyond initial implementation. For high scalability you typically need:
· Asynchronicity
· Statelessness
· Parallelism
· Pipelining
· Location Transparency
· Load Balancing
· GUIDs
|
|
Performance: A
specification of the workload and the latency or throughput requirement. The
form of the specification will depend on the type of system. In an interactive system, the form of the
specification might be an abstract specification of the number of users and
a deadline for response; in an embedded real-time system, the form of the
specification might be a characterization of the input events and an
associated deadline.
|
|
Responsiveness: A
measurement of the system response time for a functional requirement.
|
|
Availability: The amount
of time that the system is up and running.
It is measured by the length of time between failures, as well as by
how quickly the system is able to restart operations after a failure. For example, if the system was down for
one day out of the last twenty, the availability of the system for the
twenty days is 19/19+1 or 95 percent availability. This quality attribute is closely related
to reliability. The more reliable a
system is, the more available the system will be. The rule of thumb is that each additional
“9” of availability raises system cost ten-fold.
|
|
Survivability: The
ability to reestablish operations after a catastrophic event that leaves all
existing systems unusable.
|
|
Reliability: The
ability of the system to operate over time.
Reliability is measured by the mean-time-to-failure of the system.
|
|
Recoverability: The
ability to resume operations after a hardware or software fault that halts
the current systems. Is expressed by:
1. Capability to reestablish the level of performance. 2. Capability to
recover the data. 3. Time and effort needed for it. Measured by Mean-Time-To-Repair.
|
|
Nomadicity: Having
components (or mobile agents) that can survive relocation of the component
and/or automatically discover alternative living peer components in the
event that the peer components it was communicating with fail, or can
continue to work without interruption should related components fail. The DNS internet, Microsoft Outlook/Exchange,
and cellular phone system are examples of nomadic systems. Service Oriented Architecture (SOA) using
UDDI can easily be made nomadic.
|
|
Autonomic
Computing:
Autonomic computing derives its name from the autonomic nervous
system and denotes its ability to free our conscious brains from the burden
of dealing with the vital, but lower-level, functions of the body. As used
in the software industry, autonomic computing refers to self-managing
systems that are comprised of four core characteristics:
·
self-configuration,
·
self-healing,
·
self-optimizing,
and
·
self-protecting.
|
|
Transactionality: The
ability to commit a unit of work or, in the case of an error, roll-back the
data across all tables and stores. To
be transactional all of the ACID constraints (qualities) must be met:
· Atomic: all or nothing
· Consistent: logically correct transformation
· Isolated: no concurrency bugs
· Durable: survives failures
|
Software Life-Cycle Qualities |
|
Evolvability: The
ability of a system to change over time with minimum phased cut-over impact.
|
|
Composability: The
ability to sell the system as separate components that can work on their own
or together in harmony.
|
|
Extensibility: The
ability to easily add new data and behaviors to existing code by the
developers.
|
|
Tailorability: The
ability easily adapt the system to the needs of a specific customer. Includes the ability to re-brand the user
interface. Minimizes the effort
needed to maintain separate code bases.
|
|
Adaptability: The
ability to define business processes, business rules and refine data types
by an application administrator dynamically, without needing code revision.
|
|
Maintainability: The measurement
of how easy it is to change the' system to incorporate new
requirements. The two aspects of'
modifiability are cost and time. If a
system uses an obscure technology that requires high-priced consultants,
even though it may be quick to change, its maintainability can still be low.
|
|
Portability: Measures
the ease with which the system can be moved to different platforms. The platform may consist of hardware,
operating system, application server software, or database server software.
|
|
Reusability: The
ability to reuse portions of the system in other applications. Reusability comes in many forms. The run-time platform, source code,
libraries, components, operations, and processes are all candidates for
reuse in other applications.
|
|
Integrability: The
ability to make the separately developed components of the system work
correctly together as a whole. This
in turn depends on the external complexity of the components, their
interaction mechanisms and protocols, and the degree to which
responsibilities have been cleanly partitioned, all architecture-level
issues. Integrability also depends
upon how well and completely the interfaces to the components have been
specified. Integrating a component depends not only on the interaction mechanisms
used (e.g., procedure call versus process spawning) but also on the
functionality assigned to the component to be integrated and how that
functionality is related to the functionality of this new component's
environment.
|
|
Interoperability: Integrability
measures the ability of parts of a system to work together; interoperability
measures the ability of a group of parts (constituting a system) to work
with another external system. The integrability of a system depends on the
extent to which the system uses open integration standards and how well the
API is designed such that other systems can use the components of the system
being built
|
|
Testability: The ease
with which software can be made to demonstrate its faults through testing
(probability that the software will fail on its next test, given that it has
at least one fault). How easily the
system can be tested using human effort, automated testing tools,
inspections, and other means of testing system quality. Good testability is related to the
modularity of the system. If the
system is composed of components with well-defined interfaces, its
testability should be good.
|
|
Variability: How well
the architecture can handle new requirements. Variability comes in several forms. New requirements may be planned or
unplanned. At development time, the
system source code might be easy to extend to perform new functions. At run-time, the system might allow
pluggable components that modify system behavior on the fly. This quality attribute is closely related
to modifiability.
|
|
Subsetability: The
ability of the system to support a subset of the features required by the
system. For incremental development,
it is important that a system can execute some functionality to demonstrate
small iterations during product development.
It is the property of the system that allows it to build and execute
a small set of features and to add features over time until the entire
system is built. This is an important
property if the time or resources on the project are cut. If the subsetability of the architecture
is high, a subset of features may still make it into production.
|
|
Conceptual Integrity: The
ability of the architecture to communicate a clear, concise vision for the
system, also know as Architectural Style.
Fred Brooks writes, “I am more convinced than ever. Conceptual
integrity is central to product quality. Having a system architect is the
most important single step toward conceptual integrity…. After teaching a
software engineering laboratory more than 20 times, I came to insist that
student teams as small as four people choose a manager and a separate
architect” (Brooks 1995). Kent Beck
believes that metaphors are the most important part of the eXtreme
Programming methodology (Beck 1999).
The metaphor is a powerful means of providing one or more central
concepts for a system. The metaphor
provides a common vision and a shared vocabulary for all system
stakeholders. The metaphor provides a
means to enforce conceptual integrity.
When the design of the system goes outside the bounds of the
metaphor, the metaphor must change or new metaphors must be added;
otherwise, the design is going in the wrong direction. If any of these design decisions are made
without the concept feeling right, the conceptual integrity of the system
will be lost. Sometimes the system
metaphor is an architectural pattern, such as MVC or Blackboard. These architectural patterns provide a
common metaphor for system developers or others who understand the patterns.
|
|
Non-obsolescence: If the
system is intended to have a long lifetime, modifiability and portability
across different platforms become important, as well as rejection of
technologies that may become obsolete and vendors that may go out of
business. Building in the additional infrastructure (such as a portability
layer) to support modifiability and portability will usually compromise time
to market. On the other hand, a
modifiable, extensible product is more likely to survive longer in the
marketplace, extending its lifetime.
|
|
Installability: The capability
of the software product to be installed in a specified environment.
|
|
Co-existence: The
capability of the software product to co-exist with other independent
software in a common environment, sharing common resources.
|
|
Replaceability: The capability
of the software product to be used in place of another specified software
product for the same purpose in the same environment.
|
|
Standards Compliance: Adheres to external open standards.
|
The following qualities are absent from this list and may be added later if needed: flexibility, understandability, deployability, configurability, degradability, accessibility, demonstrability, footprint, simplicity, stability, timeliness, schedulability, openness, seamlessness, safety, trust, Error, Multi-Undo, feedback, empowerment. A partial list and discussion can be found on Wikipedia.
No comments:
Post a Comment