Defining and Aligning Requirements using System Architect and DOORS
Upcoming SlideShare
Loading in...5
×
 

Defining and Aligning Requirements using System Architect and DOORS

on

  • 1,730 views

Working with EA (graphical) tools enabled with requirements (textual) tools, Enabling an ‘actionable’ enterprise architecture, Value of linking enterprise architecture to requirements, ...

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

Statistics

Views

Total Views
1,730
Views on SlideShare
1,718
Embed Views
12

Actions

Likes
1
Downloads
0
Comments
1

2 Embeds 12

http://www.slideshare.net 10
http://www.linkedin.com 2

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

11 of 1

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • 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.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • 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

Defining and Aligning Requirements using System Architect and DOORS Defining and Aligning Requirements using System Architect and DOORS Presentation Transcript

  • Defining and Aligning Requirements using System Architect and DOORs Paul W. Johnson CEO / President Pragmatica Innovations [email_address] iEA16 © 2009 IBM Corporation
  • Objective
    • 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.
    Data
  • © Copyright IBM Corporation 2009. All rights reserved. The information contained in these materials is provided for informational purposes only, and is provided AS IS without warranty of any kind, express or implied. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, these materials. Nothing contained in these materials is intended to, nor shall have the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM software. References in these materials to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates. Product release dates and/or capabilities referenced in these materials may change at any time at IBM’s sole discretion based on market opportunities or other factors, and are not intended to be a commitment to future product or feature availability in any way. IBM, the IBM logo, Rational, the Rational logo, Telelogic, the Telelogic logo, and other IBM products and services are trademarks of the International Business Machines Corporation, in the United States, other countries or both. Other company, product, or service names may be trademarks or service marks of others.