Architecturally Significant Requirements

1. Requirements Decision Making through
Architecturally Significant Requirements
Feng Chen

2. Mo9va9on
• Inadequate requirements prac5ce
Ø steers research towards improving Requirements Engineering
(RE).
• The changing RE environment, specifically in enterprise soCware
development
Ø brings the focus to architecture in RE.
Manage requirements through architectures → ASRs as a sweet spot.
Ø Recogni5on of RE as a decision making process
It becomes an appropriate way of viewing contemporary RE.
2

3. Research Ques9ons
RQ 1. How are requirements decisions made in enterprise
soCware development?
RQ 2. What are the requirements challenges and issues facing
prac55oners as well as opportuni5es for improvement?
RQ 3. How to iden5fy architecturally significant requirements?
RQ 4. How to use findings from the previous ques5ons to
improve requirements decision making?
3

4. Research Design
Understanding the requirements
challenges, issues and
opportuni9es
RQ1
RQ2
RQ3
RQ4
Research Ques9ons Objec9ves Research Methods
Discovering the knowledge for
iden9fying ASRs
Improving requirements decision
making through ASRs
Survey
Grounded theory
Valida9ng the results
Literature review +
Experts interview
Understanding the requirements
decision making context
Par9cipant
observa9on
4
Revised from Figure 3-2,
page 64 from the thesis.

5. Studied Environment
5
• Avaya Inc. – an interna5onal telecommunica5on company
• Embedded as an employee for 12 months in total
• IT department – over 800 employees
• Had access to all the IT project documenta5on including
documenta5on from the R&D projects
• Par5cipated in many IT project mee5ngs
• Worked closely with two solu5on architects and a group of
business analysts as part of this research

6. Studies
RQ1
RQ2
RQ3
Research Ques9ons Research Methods
Survey
Grounded theory
Literature review +
Experts interview
Par9cipant
observa9on
Study details
In-vivo observa9ons, three case stories, data from
prac99oners, requirements-related documents
Feedback from 8 BAs, 7 technical leads, 2 QAs
Interviewed 10 experts from 10 different
organiza9ons with 187 years’ experience in total
Observed 7 ARB mee9ngs, analysed 22 ARB
presenta9on files, interviewed 5 architects with 75
years’ experience in total
6
valida9on

7. Deriving the Theory
- Atlas.5 Qualita5ve Data Analysis tool
7
Figure 8-3, page 144
Figure 8-5, page 145
Figure 9-1, page 153

8. Contribu9on 1. A Stakeholder Contribu9on Pa_ern in
Requirements Decision Making
8
WHO (Role) WHAT (Content /
Characteris7cs /
Efficiency)
HOW (Ac7vity / Task) WHEN (Time &
Frequency / Situa7on)
WHY (Goals /
Interests)
Business SME Degree of business value:
Current business
environment;
Proposed business
environment;
Func9onal requirements
Share informa9on via demos,
examples, screen shots,
documenta9ons, etc.
Speak out current challenges and
needs;
Define business rules and processes
and new func9onal requirements
Primary business SMEs are
ac9ve most of the 9me
while secondary SMEs are
ac9ve when needed.
Improve business process
and work produc9vity
Solu9on
Architect
Degree of feasibility and
completeness
Advise BAs;
Review and validate requirements;
Propose alterna9ve requirements
Determine the completeness of
details in the BRS.
Periodically engaged but very
ac9ve at the end for
reviewing the BRS
Ensure the business-IT
partnership and alignment;
Produce HLD / HLE
… … … … …

9. Contribu9on 2. Architects’ Influence on Requirements
Decision Making
9
Project Proposal Requirements
elicita7on
Requirements
valida7on
Architec7ng
Who Enterprise architects;
Solu9on architects
Enterprise architects;
Solu9on architects;
Technical leads
Solu9on architects;
Technical leads
Enterprise architects;
Solu9on architects;
Technical leads
Ac9vi9es Triage (Assess the project
proposal and navigate )
Advise BAs;
Provide overarching
support
Point out missing or
infeasible requirements;
Sign-off
Frame requirements;
Negate / propose
requirements
Influence on
requirements
Constraining Shaping Ra9fying Refining
Table 6-6, page 113

10. Contribu9on 3. A Conceptual Model for Requirements
Decision Making
10 Figure 6-2, page 116
Current Business / IT Environment
Business / IT Goals
Requirements Decisions
Project Situa9on
Stakeholder Composi9on
Decision Making
Level of Detail
Drive
Have
Determine
Impacts Jus9fies

11. Contribu9on 4. Empirical Evidence for Requirements
Challenges and Issues
11
Ø 11 requirements challenges
Ø 9 requirements issues
Ø 13 requirements opportuni5es
For the studied environment, the key underlying challenges are:
the difficulty to iden5fy ramifica5ons of changes &
the difficulty to balance and control the level of detail of requirements

12. Contribu9on 5. The ASR Framework
AIC ASRs Indicator
Locus of Influence
ASR Context
Architectural Effect
Embodies
Expressed by
Implies
Situated in
12 Figure 10-1, page 182

13. Contribu9on 6. Recommenda9ons for Requirements
Decision Making through ASRs
13
Ø Six recommenda5ons for requirements decision making through ASRs
Ø For example:
Recommenda5on 2. Architectural Design Decisions (ADDs) should be
allowed and even encouraged to be made in requirements decision
making (Early ADDs), while any design decisions that are not
architectural should be avoided; and the ADDs should be made with the
agreement of the architects.

14. 14