1. Team Mason PFDA Contextual Architecture Oliver Rettig Team Leader Process Manager Planning Manager Lazar Crawford Design Manager Implementation Manager Customer Interface Manager David Harty Test Manager Quality Manager Support Manager

2. Primary System Functionality  Project Creation/Saving  Diagram Creation/Verification  Diagram Printing  XML Exportation  Multiple User Access

3. PFDA Context Diagram

4. Organizational Factors Organizational FactorFlexibility and ChangeabilityImpact O1: Management O1.1: Conflicting Goals MSE 530 and 610 have goals and intentions that do not always coincide Communication may bridge different approaches Moderate impact on schedule O1.2: Aggressive Schedule Schedule is constrained by course objectives This factor is not flexibleLarge impact on schedule and completeness of design O1.3: Requirements Volatility The working SRSs are still under construction Eventually the SRSs will be finalizedModerate impact on schedule and design O1.4: Conflicting Requirements There are currently 4 different working SRSs Eventually the SRSs will be merged, or one will chosen as the master Moderate impact on schedule and design O2: Staff Skills O2.1: Familiarity With Domain Team has little or no experience with Problem Frames Training can be arrangedModerate impact on schedule

5. Technological Factors Technological FactorFlexibility and ChangeabilityImpact T1: General-Purpose Hardware T1.1: Computing Hardware PFDA shall run on a standard PC-based system As technology advances, the PC hardware platform will be upgraded Moderate impact on design so that hardware changes are transparent T2: Supporting Software T2.1: Operating System The PFDA shall support multiple Windows versions, including 98 and NT which run on different kernels If potentially flexibleModerate impact on design to support different OS environments

6. Product Factors: Functional Features Product FactorFlexibility and ChangeabilityImpact P1: Functional Features P1.1: Concurrent, multiple user access PFDA supports multiple users accessing a project Requirement is not flexibleLarge impact design P1.2: Problem Frame Diagramming User shall be able to create, edit, save Problem Frame Diagrams Requirement is not flexibleLarge impact on design P1.3: Problem Frame Modeling & Verification PFDA shall verify that model units are used in accordance with standard Problem Frame guidelines. This is flexibleModerate impact on design P1.4: XML Generation PFDA shall be able to output Problem Frame diagrams in XML format Somewhat flexibleLight impact on design

7. Product FactorFlexibility and ChangeabilityImpact P2: User Interface P2.1: GUI Components The GUI shall have a menu bar, project hierarchy window, drawing window, diagram canvas window, and a status bar. Specific arrangement and content of the GUI is flexible Light impact on design P3: Error Handling & Recovery P3.1: Automatic Project Backup When the PFDA experiences an unrecoverable error, current working files shall be available for recovery upon restart This is a flexible requirement in terms of degree of recoverability Moderate impact on design Product Factors: User Interface, Error Handling & Recovery

8. Issue Tables IssueInfluencing FactorsApplicable Strategy RequirementsO1.1,O1.3,O1.4Modularization of functional elements Continual communications with requirements team ScheduleO1.2,O2.1Modular design will support parallel tasking among the team Problem FramesO2.1,P1.2,P1.3Partition the system such that Problem Frame logic is encapsulated in distinct elements Concurrent Multiple User AccessP1.1Apply separation of concerns along the lines of user interaction with the system and the systems primary logic Identify an architectural style, or hybrid of styles, that will provide an interface for remote access to the PFDA Implement a data model that enables version control for shared projects

9. Conceptual Diagrams: Level 1

10. Level 2:PFDA->Client

11. Level 3: PFDA->Client-> ProblemFrames

12. Level 3: PFDA->Client-> ProblemFrames->Drawing

13. Level 2: PFDA->Server