Very good points made here with an interesting perspective. I am in complete agreement with the concept of using enterprise architecture (graphic models) to define the functional and system requirements as this adds much needed clarity to the usually overly documented requirements.
Author Notes: This is the standard session track template for IBM Rational Software Conference 2009 Additional IBM presentation resource links available on W3: Rational Core Messaging Slides https://w3-03.ibm.com/software/marketing/markwh01.nsf/AllObjects/rt_mtb_cms/$file/RationalBrand_CoreSlides.ppt?OpenElement Rational Image Library https://w3-03.ibm.com/software/marketing/markwh01.nsf/AllObjects/rt_rsil/$file/Rational_Image+Library.ppt?OpenElement PowerPoint Best Practices Presentation https://w3-03.ibm.com/software/marketing/markwh01.nsf/AllObjects/rt_mtb_rpbp/$file/PowerPoint_BestPractices.ppt?OpenElement
Align business requirements from strategy to front line process execution
Combine use of Enterprise Architecture & Requirements tools.
Session Benefits
Users attending session can take away an understanding of:
Enabling an ‘actionable’ enterprise architecture
Value of linking enterprise architecture to requirements
Efficiencies of generating requirements from enterprise architecture
Process for managing requirements through enterprise architecture
Scenario
Managers make many decisions - from simple to complex.
Most business decisions have data dependencies captured as static snapshots in
enterprise architecture products or
requirements documentation .
Decisions are made without considering effects on enterprise touch points – un informed.
Scenario
EA, in today's world, cannot persist simply as artifacts supporting compliance…
Not enough money to support both
robust data management efforts
comprehensive EA efforts
Go beyond static artifacts - an enterprise architecture that delivers decisions based on relevant data .
Problem
Little attention is paid to human usability (or reuse) of the finished product.
Requirements ‘ documentation ’ is produced and the solution delivered.
Content is ‘shelved’ and neither visible nor usable to most people.
Most requirements gathering efforts center on generating large quantities of documentation to support ill-defined business needs.
Problem ( other side )
Most people are graphical learners – comprehending through pictures or models.
Problem ( other side )
Most requirements are textual; detailed and data rich.
Solution
Enable rapid assessment of gaps in enterprise through architecture ensuring requirements meet relevant needs.
Use enterprise architecture products ( graphics ) to clearly depict desired solution.
Link or generate requirements from an enterprise-wide accessible architecture based on real time information.
Link Requirements ( textual ) to Enterprise Architecture ( graphical )
Architecture Driven Requirements Process Scope Project End Start Assess against ‘ current’ architecture Architecture Views Define ‘ future’ architecture Update ‘ current’ architecture Deliver Project Solution Generate Solution Requirements Requirements Text Document
Scope Project Solution.
Assess current architecture for gaps or redundancies relevant to solution.
Define future solution architecture (linked to requirements).
Write (or generate from architecture) requirements to address solution (linked to architecture).
Deliver project solution.
Update ‘ current’ EA to reflect solution capabilities.
Solution Steps
Define Scope of Project Solution.
Discuss with stakeholders and capture scope and purpose for solution.
Scope These two parameters provide initial “ frame ” for questions that architecture can answer. Purpose
Assess ‘ Current’ Architecture for Gaps or Redundancies Process Model Variant 1 (as-is) Process Model Variant 2 (to-be)
Define ‘Future’ Architecture to Address Solution
Use System Architect (SA) tool to graphically model architecture.
Generate Requirements from Architecture
Requirements Structure (architecture) DOORs Internal Customer Functional System Functional Software Specification Software Load Plan User Acceptance Test Plan PITCO CMMI Process Strategy & Vision External Customer Test & Equipment Master Plan Tests System Standards Conforms to Technical Standards Conforms to Policy Conforms to Tests Satisfies Satisfies Satisfies Satisfies Tests
Requirements Coupled with Architecture System Architect OV-1 Concept Graphic OV-5 Operational Activity SV-4 System Function SV-5 OA to SF SV-10 System Process OV-6 Business Process OV-7 Logical Data DOORs Internal Customer Human Functional System Functional Software Specification Software Load Plan User Acceptance Test Plan PITCO CMMI Process Strategy & Vision External Customer Test & Equipment Master Plan Tests System Standards Conforms to Technical Standards Conforms to Policy Conforms to Tests Satisfies Satisfies Satisfies Satisfies Tests
Deliver Project Solution
Finished products generated in a variety of formats can be accomplished with features in System Architect or DOORs:
HTML output
Word Document
Detailed graphic diagrams
Database DDL
SAXT provides real-time web-based access
SA Publisher provides:
Dashboard views
Pie Charts, Bar Charts, “Heat Maps”
As-Is <> To-Be Comparisons
Update ‘Current’ Architecture to Reflect Solution
Results
Actionable, executable architecture that is tied to requirements that enable informed decisions supported by real time data.
Requirements Architecture
Results
Informed decisions supported by data are crucial for the success of any enterprise of the future.
Working with EA (graphical) tools enabled with requ more
Working with EA (graphical) tools enabled with requirements (textual) tools, Enabling an ‘actionable’ enterprise architecture, Value of linking enterprise architecture to requirements, Efficiencies of generating requirements from enterprise architecture, Process for managing requirements through enterprise architecture less
1 comments
Comments 1 - 1 of 1 previous next Post a comment