1. Software Architecture
Architectural Requirements
Quality Attributes
Vakgroep Informatietechnologie – IBCN

2. Software Architecture Definition
The Software Architecture of a program or
computing system is the structure or
structures of the system, which comprises
software elements, the external visible
properties of those elements and the
relationships among them.
Software
Requirements Design
Architecture
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 2

3. Dilbert on Software Requirements ...
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 3

4. Functional versus Non Functional
 Functional Requirements:
 FR’s capture the intended behavior of the system
and describe what the systems should do. This
behavior may be expressed as services, tasks or
functions the system is required to perform.
 Non Functional Requirements:
 NFR’s are not directly concerned with a specific
function delivered by the system. They typically
come from the ABC (Architecture Business Cycle)
and cover o.a. business, organisational, legal and
quality requirements.
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 4

5. Architecture and Functionality
 Functionality
 defines what the system has to do.
 can be achieved through any number of
structures.
 is often the ONLY consideration at the start of
a project and leads to redesign, project
cancelation,…
 to slow
 hard to maintain
The mapping of the system’s functionality onto software structures is
critical for the support of quality .
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 5

6. Use Cases & Scenario’s / UML
 Functional Requirements are documented with:
 Use cases:
 define a goal-oriented set of interactions between external
actors and the system under consideration.
 Are graphically summarized in a UML use case diagram.
 They are documented using a use case template.
 Scenario’s:
 A (black box or system ) scenario is an instance of a use
case, and represents a single path through the use case.
Thus, one may construct a scenario for the main flow
through the use case, and other scenarios for each possible
variation.
 Scenario’s are documented with UML sequence diagrams
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 6

7. Example : Use Case Diagram
Department of Information Technology – Broadband Communication Networks (IBCN) 7

8. System Sequence Diagrams
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 8

9. The origins of architecture complexity
 Functionality needs to be mapped to
software structures in order to support the
quality
 This mapping requires the collaboration,
communication, synchronisation of these
software elements in order to provide the
functionality.
 Example: caching
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 9

10. Software Quality Attributes
 Software Architecture and ...
 Quality Attributes.
 Quality Attribute Tactics.
 Architecture Patterns
Quality is ‘value as perceived by the customer’.
Over and above the definition of customer features, quality attributes
clarify which items are most important to the customer's perception of
the product's quality and performance.
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 10

11. Qualities in Software Architecture
• Capabilities
Functionality • Functions
• Services
• Behaviour
Software
System Architectural
Architecture
Qualities Qualities
• Conceptual Integrity
• Modifiability
• Correctness
• Performance
• Completeness
• Testability
• Buildability
• Availability
Business
• Security • Cost
Qualities
• Usability • Margins
• Scalability • Time-to-market
• Interoperability • Target market
• Portability • System lifetime
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 11

12. ISO/IEC CD 25010 SQuaRE
[1.] ISO/IEC CD 25010 Software engineering -- Software product Quality Requirements and Evaluation (SQuaRE), 2009
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 12

13. Quality Attributes in practice:
EXAMPLE : SLA - Service Level Agreement
 A service-level agreement (SLA) is a contract
between a service provider and a customer that
specifies, usually in measurable terms, what services
provider will furnish.
 SLA’s may specify :
 What percentage of the time services will be available
 The number of users that can be served simultaneously
 Specific performance benchmarks to which actual
performance will be periodically compared.
 Help desk response time
 Usage statistics that will be provided.
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 13

14. SLA terms (1/2)
Guaranteed uptime
 The expected availability of the Platform is 99.8%
or with periods of unavailability of maximum 2
(two) hours per month.
Recovery
 In case of system failure, the application and all
data shall be restored within 4 hours after problem
fixation.
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 14

15. SLA Terms (2/2)
Performance
 The target response time to any request should be
respected in 90% of all requests.
 New page download time inferior to 3 seconds
Capacity
 The installation will be planned for a maximum of
20.000 requests per day.
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 15

16. Business Qualities (1/2)
Time to Market:
 Build or buy
 Re-use existing elements from previous
projects
 COTS/OSS :Time to market is often reduced
by using prebuilt elements such as commercial
off-the-shelf or open source components.
 Deploy a subset : The ability to insert or
deploy a subset of the system depends on the
decomposition of the system into elements.
(roll-out schedule)
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 16

17. Business Qualities (2/2)
Cost and Benefit:
 The development budget must not be exceeded.
 Different architectures will yield different development
costs.
 Architectures based on new technology are more expensive
 Flexible architecture cost more to build but will be less costly
to maintain and modify
System Lifetime:
 If the system is intended to have a long lifetime,
modifiability, scalability, and portability become
important. ( = more revenue)
 Building in the additional infrastructure (such as a layer to
support portability) will usually compromise time to market.
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 17

18. The Quality state-of-mind
 Quality is not the privilege of Architects:
 it needs to be considered throughout the entire
lifecycle (design, implementation, deployment)
 But:
 Architecture is critical to the realisation of many
qualities.
 And
 Architecture cannot achieve quality by itself.
 Qualities can never be achieved in isolation.
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 18

19. Quality Attribute Scenarios
 Qualities are abstract and non-operational:
 What does it mean for a system to be modifiable ?
 Quality attribute requirements are captured with
quality attribute scenarios.
 Generic scenarios (system independent) need to be
translated into specific scenarios
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 19

20. Quality Attribute Scenarios
A Quality Attribute Scenario describes:
 SOURCE: who or what
 STIMULUS: does something
 ARTIFACT: to the system or part of it
 ENVIRONMENT: under certain conditions
 RESPONES: how the system reacts
 MEASURE: how you can measure this
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 20

21. Example : Public Transport Signage
Availability QAS :
SOURCE who or what A random event
STIMULUS does something ... causes a failure
ARTIFACT to the system or part of it ... to the communication system
ENVIRONMENT under certain conditions ...during normal operations
RESPONSE how the system reacts All displays must start showing
scheduled arrival times for all
buses
MEASURE how you can measure this ... Within 30 seconds of failure
detection
Q: What is the architectural impact of this requirement ?
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 21