0% found this document useful (0 votes)
33 views27 pages

Understanding Architecturally Significant Requirements

Uploaded by

Kiran Rocky
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
33 views27 pages

Understanding Architecturally Significant Requirements

Uploaded by

Kiran Rocky
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd

Software Architecture

Software Architecture :
Architecturally Significant Requirements (ASR)
Topics To Be Covered

 What is ASR?
 Systematic Means for Identifying ASR from :
 Requirement Documents
 Interviewing Stakeholders (QAW – Quality Attributes Workshop)
 Understanding Business Goals (PALM – Pedigreed Attribute
eLicitation Method)
 Designing a Utility Tree
 What will be the best way forward?

CONFIDENTIAL - RESTRICTED CIRCULATION 3


Architecturally Significant Requirements (ASR): Definition

An architecturally significant requirement (ASR) is a requirement


that will have a profound effect on the architecture - that is, the
architecture might well be dramatically different in the absence of such a
requirement.

The more difficult and important the QA requirement, the more


likely it is to significantly affect the architecture, and hence to be an ASR.
Drivers:
 Need for Categorizing requirements into Critical, Important and Useful
 Researchers indicate that only 40 % of software features are used even in highly
critical applications.

CONFIDENTIAL - RESTRICTED CIRCULATION 4


Some requirements are technically more challenging than others

• Simple functional requirements like ‘System should be able to create


an order’, ‘System should keep track of inventory’, etc. are straight
forward to implement

• Some functional requirements such as ‘We should be able to


detect fraud in real time and block the user’ may not be that
straight forward

• Some non-functional requirements like the ‘System should be easy


to customize for a different organization” may not be straight
forward to implement

• Such challenging requirements are called ‘Architecturally


Significant Requirements’ (ASR)
CONFIDENTIAL - RESTRICTED CIRCULATION 5
Examples of ASRs

• Audit trail
• Alert & Notifications
• Variety of data input mechanisms
• Third party interaction
• Workflow
• User behaviour analysis (ex. in e-commerce)

• All such requirements need to be probed in detail and we need


to understand the specific scenarios in order to decide the
design approach
CONFIDENTIAL - RESTRICTED CIRCULATION 6
Deeper understanding of requirements helps identify ASRs

Audit trail: Should we use File or DB? This will depend on how the
audit trail is going to be used – are we going to perform some
kind of analysis of the activities or are we looking for a specific
activity

Third party interaction: We need to understand what


communication mechanisms are supported by the 3rd party.

Notifications: Should it be an SMS notification or eMail notification


or notifying an application via message queue? Should it be a
one way notification or do we need an Acknowledgement?
CONFIDENTIAL - RESTRICTED CIRCULATION 7
Ex. of probing the requirements - ‘Traffic Management System’

CONFIDENTIAL - RESTRICTED CIRCULATION 8


1. ASR from Requirement Documents

 Do requirements specification follow the principle of “MoSCoW” style (must,


should, could, won’t), or as a collection of “user stories ”?
 Do the requirement capturing exercise include Quality Attributes as well in
equal proportions as per Software Engineering Body of Knowledge
(SWEBOK) recommendations?
 Have you come across BSR (Basic Skill Requirements) with explicit
requirements on “ high usability”, “System Modularity”, “performance through
Resilience”, “Fault detection” etc.,?
So, in the absence of BSR not reflecting the QA clearly, it is a challenge for an
ARCHITECT to extract ASR . However, that makes the Role of an Architect requisite.

CONFIDENTIAL - RESTRICTED CIRCULATION 9


Look for leads from Design Decision Documents ..,
Design Decision Category Look for Requirements addressing …,

Allocation of Responsibilities Planned evolution of responsibilities, user roles, system modes, major
processing steps, commercial packages
Coordination Model Properties of the coordination (timeliness, currency, completeness,
correctness, and consistency) Names of external elements, protocols,
sensors or actuators (devices), middleware, network configurations
(including their security properties) Evolution requirements on the list
above
Data Model Processing steps, information flows, major domain entities, access
rights, persistence, evolution requirements
Management of Resources Time, concurrency, memory footprint, scheduling, multiple users, multiple
activities, devices, energy usage, soft resources (buffers, queues, etc.)
Scalability requirements on the list above
Mapping among Architectural Plans for teaming, processors, families of processors, evolution of
Elements processors, network configurations.
Binding Time Decisions Extension of or flexibility of functionality, regional distinctions, language
distinctions, portability, calibrations, configurations
Choice of Technology Named technologies, changes to technologies (planned and unplanned)

CONFIDENTIAL - RESTRICTED CIRCULATION 10


2. ASR from interviewing Stakeholders QAW
Quality Attributes Workshop - Expectation : List of architectural Drivers

QAW Steps

2. Business 3. Architectural 4. Identification


1. Presentation & 5.Scenario 6. Scenario 7. Scenario
Mission Plan of Architectural
Introduction Brainstorming Consolidation Prioritization
Presentation Presentation Drivers

1. Presentation & Introduction : Everyone introduces themselves, briefly stating their background, their role
in the organization, and their relationship to the system being built.
2. Business Mission Presentation : The stakeholder representing the business concerns behind the system
(typically a manager or management representative) spends about one hour presenting the system’s business
context, broad functional requirements, constraints, and known quality attribute requirements. The quality attributes that
will be refined in later steps

CONFIDENTIAL - RESTRICTED CIRCULATION 11


2. ASR from interviewing Stakeholders QAW
Quality Attributes Workshop - Expectation : List of architectural Drivers

3. Architectural Plan Presentation : At this point in the workshop, the architect will present the system
architectural plans as they stand. This lets stakeholders know the current architectural thinking, to the extent that it
exists.
4. Identification of Architectural Drivers : The facilitators will share their list of key architectural drivers that they
assembled during steps 2 and 3, and ask the stakeholders for clarifications, additions, deletions, and corrections. The
idea is to reach a consensus on a distilled list of architectural drivers that includes overall requirements, business
drivers, constraints, and quality attributes.
5. Scenario Brainstorming : Each stakeholder expresses a scenario representing his or her concerns with respect
to the system. Facilitators ensure that each scenario has an explicit stimulus and response. The facilitators ensure that
at least one representative scenario exists for each architectural driver listed in step 4.
6. Scenario Consolidation : Similar scenarios are consolidated where reasonable. Facilitators ask stakeholders to
identify those scenarios that are very similar in content. Scenarios that are similar are merged, as long as the people
who proposed them agree and feel that their scenarios will not be diluted in the process
7. Scenario Prioritization : Prioritization of the scenarios is accomplished by allocating each stakeholder a number
of votes equal to 30 percent of the total number of scenarios generated after consolidation

CONFIDENTIAL - RESTRICTED CIRCULATION 12


3. ASR from Business GOALS
Format : “X” to “Y” by when? : “X “ - Current State : “Y” - Future state

Business Goals Quality Attributes

Architecture
Non-architectural Solutions

1. Business goals often lead to quality attribute requirements


2. Business goals may directly affect the architecture without precipitating a quality
attribute requirement at all
3. No influence at all
CONFIDENTIAL - RESTRICTED CIRCULATION 13
Business GOAL Categories
Format : “X” to “Y” by when? : “X “ - Current State : “Y” - Future state
# Category Example
1 Contributing to the growth and continuity of the organization Market share by 15%
2 Meeting financial objectives 30 % Profit after tax
3 Meeting personal objectives Learn New Technologies
4 Meeting responsibility to employees Reduce work load by 8 %
5 Meeting responsibility to society Green Computing – Less CO2
6 Meeting responsibility to state Regulatory Compliance
7 Meeting responsibility to shareholders 1:3 Share Dividend
8 Managing market position IPR - 50 Design Registrations
9 Improving business processes Productivity Improvement
10 Managing the quality and reputation of products Automated Testing Strategy
11 Managing change in environmental factors US Dollar Volatility

CONFIDENTIAL - RESTRICTED CIRCULATION 14


Example of Business Goal: BHIM

Examples of business goals:

• Govt. wanted to speed-up


cashless transactions

• So Government introduced
BHIM app

This translates into QAs:


• Usability (easy steps)
• Security (3-factors)

CONFIDENTIAL - RESTRICTED CIRCULATION 15


Format for Presenting Final Business Goals

CONFIDENTIAL - RESTRICTED CIRCULATION 16


PALM : Pedigreed Attribute eLicitation Method
Capturing Business Goal
“Pedigree” means that the business Goal has a strong background:
1. PALM overview presentation. Overview of PALM, the problem it solves, its steps, and its
expected outcomes.
2. Business driver’s presentation. Briefing of business drivers by project management. What are
the goals of the customer organization for this system? What are the goals of the development
organization?
3. Architecture driver’s presentation. Briefing by the architect on the driving business and quality
attribute requirements: the ASRs.
4. Business goals elicitation. Using the standard business goal categories to guide discussion,
capture the set of important business goals as scenarios, consolidate and prioritize them to identify
important Goals.
5. Identification of potential quality attributes from business goals. For each important
business goal scenario, participants describe a quality attribute that would help achieve it
6. Assignment of pedigree to existing quality attributes drivers. For each architectural driver
named in step 3, we identify which business goals it is there to support. For example: Why is there a
40-millisecond performance requirement? Why not 60 milliseconds? Or 80 milliseconds?
7. Exercise conclusion. Review of results, next steps, and participant feedback

CONFIDENTIAL - RESTRICTED CIRCULATION 17


4. ASR in Utility Tree
Quality Attribute Attribute Refinement ASR

Performance Transaction response time A user updates a patient’s account in response to a change-
of-address notification while the system is under peak load,
and the transaction completes in less than 0.75 second.
(H,M)
A user updates a patient’s account in response to a change-
of-address notification while the system is under double the
peak load, and the transaction completes in less than 4
seconds. (L,M)
Throughput At peak load, the system is able to complete 150 normalized
transactions per second. (M,M)

Usability Proficiency training A new hire with two or more years’ experience in the
business becomes proficient in Nightingale’s core functions
in less than 1 week. (M,L)
A user in a particular context asks for help, and the system
provides help for that context, within 3 seconds. (H,M)

Normal operations A hospital payment officer initiates a payment plan for a


patient while interacting with that patient and completes the
process without the system introducing delays. (M,M)

CONFIDENTIAL - RESTRICTED CIRCULATION 18


4. ASR in Utility Tree - Contd.,
Quality Attribute Attribute Refinement ASR

Configurability User-defined A hospital increases the fee for a particular service. The
configuration team makes the change in 1 working day; no
changes
source code needs to change. (H,L)

Maintainability Routine changes A maintainer encounters search- and response-time


deficiencies, fixes the bug, and distributes the bug fix with no
more than 3 person-days of effort. (H,M)

A reporting requirement requires a change to the report


generating metadata. Change is made in 4 person-hours of
effort. (M,L)

Upgrades to The database vendor releases a new version that must be


commercial installed in less than 3 person-weeks. (H,M)
components

Extensibility Adding new A product that tracks blood bank donors is created within 2
person-months. (M,M)
product

CONFIDENTIAL - RESTRICTED CIRCULATION 19


4. ASR in Utility Tree - Contd.,

Quality Attribute Attribute Refinement ASR

Security Confidentiality A physical therapist is allowed to see that part of a patient’s


record dealing with orthopaedic treatment but not other parts
nor any financial information. (H,M)

Integrity The system resists unauthorized intrusion and reports the


intrusion attempt to authorities within 90 seconds. (H,M)

Availability No Downtime The database vendor releases new software, which is hot-
swapped into place, with no downtime. (H,L)

The system supports 24/7 web-based account access by


patients. (L,L)

H - High Priority M - Moderate Priority L - Low Priority

CONFIDENTIAL - RESTRICTED CIRCULATION 20


What is the Best Approach?
…. How much is the time scheduled in your project for this activity?
….. As an architect, even when no BSR, you are accountable for ASR…
…. Interview with stakeholders must be planned by you well in advance…..
…. Utility Tree is more like a repository approach…..
… Choose the one the most suits with the time to fill

CONFIDENTIAL - RESTRICTED CIRCULATION 21


Architecture in Agile Projects
CONFIDENTIAL - RESTRICTED CIRCULATION 22
Agile Vs. Traditional
Agile Development Traditional Development

Individuals and interactions Processes and tools

Working software Comprehensive documentation

Customer collaboration Contract negotiation

Responding to change Following a plan

CONFIDENTIAL - RESTRICTED CIRCULATION 23


Agile Manifesto :
12 Principles
# Principles # Principles
1 Early and continuous delivery of valuable 7 Working software is the primary measure of
software progress

2 Welcome changing requirements, even 8 Agile processes promote sustainable


late in development development

3 Deliver working software frequently, from 9 Continuous attention to technical excellence


a couple of weeks to a couple of months and good design enhances agility.

4 Business people and developers must 10 Simplicity is essential


work together

5 Build projects around motivated 11 The best architectures, requirements, and


individuals designs emerge from self-organizing teams

6 Face-to-Face conversation 12 At regular intervals, the team reflects on


how to become more effective, then tunes
and adjusts its behaviour accordingly

CONFIDENTIAL - RESTRICTED CIRCULATION 24


Analytics : Up-front Work Vs. Agility
Interpretations:
1. There is one line representing each of these three
projects, starting near the Y axis and descending, at
different rates, to the X axis at the 50 mark. This
shows that adding time for up-front work reduces
later rework.
2. when you sum each of those downward-trending
lines (for the 10, 100, and 1,000 KSLOC projects)
with the upward sloping line for the up-front (initial
architecture and risk resolution) work, you get the
second set of three lines, which start at the Y axis
and meet the upward sloping line at the 50 mark on
the X axis.
3. These lines show that there is a sweet spot for each
project. For the 10 KSLOC project, the sweet spot is
at the far left. This says that devoting much, if any,
time to up-front work is a waste for a small project.
4. For the 100 KSLOC project, the sweet spot is at
around 20 percent of the project schedule. And for
the 1,000 KSLOC project, the sweet spot is at
around 40 percent of the project schedule.

A project with a million lines of code is enormously complex, and it is difficult to imagine how Agile principles
alone can cope with this complexity if there is no architecture to guide and organize the effort .
CONFIDENTIAL - RESTRICTED CIRCULATION 25
BDUF (Big Design Up-front Model) for Agile

Define Architecture completely Before Implementation


CONFIDENTIAL - RESTRICTED CIRCULATION 26
Thank you!
• Sat Arch Episode Ep - 23: Architecturally Signifi
cant Requirements Part 1 (youtube.com)

• Assignment work – [10 marks]-


• How To Write A Case Study? | Amazon Case St
udy Example (youtube.com)

CONFIDENTIAL - RESTRICTED CIRCULATION 27

You might also like