Architecting Non-Functional Requirements


Published on

Modeling and Analysing Non-Functional Requirements to support architectural decision-making in organizational settings

Published in: Technology, Business
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Architecting Non-Functional Requirements

  1. 1. Modeling and AnalyzingNon-Functional Requirements (NFRs) to support Architectural decision-making SW Craftsmanship May 14th, 2012 Daniel Gross, PhD Daniel Gross © 2012
  2. 2. Talk Objective• Illustrate that dealing with NFRs in projects is surprisingly complex -- and modeling them can help discussing and analyzing them• Show that NFRs are key drivers that shape the software system architecture• Show that NFRs link between business goals and the architecture – and that resolving NFR conflicts in organizations may require business (commercial) decisions• Examples from two industry case studies Daniel Gross © 2012 2
  3. 3. Architectural Decision ProblemEvolution path planning PBX/Call Control Virtual Intellig Periph From an industrial case study [14] ent tel. eral Daniel Gross © 2012 3 [14] Gross, D. and E. Yu (2001). Evolving System Architecture to Meet Changing Business Goals: an Agent and Goal-Oriented Approach. Proceedings of the First International Workshop From Software Requirements to Architectures (STRAW 2001) at the International Conference of Software Engineering. Toronto, Canada.
  4. 4. Decision-making in organizations• Stakeholders (“the WML Team”) • NFRs of stakeholders – Industrial designer – Seamless UI interaction – Marketing – Portalization – New Business Strategy – Ease of Use – Desktop PLM – Cost of Phone set – Architecture Strategy – Fast and easy access to key internet functions – IP Phone architect – Increase mobility – Call control Architect – Avoid unnecessary functionality – Immediate access to functionality – User Centric – Quick addition of features – Architectural evolution – Reduce time to market How to – Reduce new product risk systematically deal – Maintain architectural integrity with NFRs? – Maximize WML enabling of phone sets – Reuse existing architectural solutions Daniel Gross © 2012 4
  5. 5. Intentional Actors show stakeholders goals Stakeholder goals are visually included inside Intentional Actors (gray circles) Actor Actor Internal View Actors assigned to the “WML” team. Daniel Gross © 2012 5
  6. 6. WML team in the organization Goal delegation Collective actor typeContribution linkDecision option Daniel Gross © 2012 6
  7. 7. NFR s as “soft” goals to Goal reasoning by the team achieveRefining NFRs into more specific NFRs Impact of solution approaches on NFRs Solution approaches The architecture evolution problem? Where in the architecture to place client browser code, and why? Daniel Gross © 2012 7
  8. 8. Upper managementand their demands At an insurance organization Another “Team” and its goal graphOne “Team” and its goal graph Designer Competing goal reasoning between stakeholders Daniel Gross © 2012 8
  9. 9. ! ! ! ! ! ! ! ! ! Product Management prioritizes goals and hence resolves conflicting non-functional demands on the SOA architect and component designerGross © 2012 Daniel 9