![]() |
Telelogic Rhapsody (steve huntington) | ![]() |
Topic Title: Open Space Discussion - Requirements flow down in harmony process Topic Summary: Created On: 13-Jun-2006 19:51 Status: Read Only |
Linear : Threading : Single : Branch |
![]() |
![]()
|
![]() |
|
Discussion Topic: Requirements flow down in harmony process
Leader Name: Charlie Lane Attendees: Andreas Lyncker Simon Morrish Jan Haulsen Jörg Christoffers Peter Schmittinger Jürgen Strauss Stenio Lingaya Wolfgang Messner Winfried Reichardt Session Notes: Aim Discussion on how we actually do a flow-down, given that we use the Harmony process. Basic linking of text requirements From the Harmony process: a) Import textual requirements using Gateway b) Give every requirements a home in a use case c) Define the operational contracts (using sequence diagrams and activity diagrams) d) Link operational contracts to imported requirements using <<satisfy>> dependencies (allows Gateway to indicate percent coverage) e) Develop architecture f) Transfer operational contracts to subsystems (using wizard) g) Where a system level opcon will be decomposed to more than one subsystem, decompose them, using the swim lanes and lifelines h) Get the software to trace to the subsystem operational contracts Non-functional requirements Not actually part of the Harmony process (pending book 2!), except that constraints on opcons can be treated with the opcons. Need to identify the non-functional requirements separately ? possible routes are to keep in the model but use tags to identify, or to keep outside the model. There are some non-functional requirements that won't link to any subsystem (e.g. requirement for 3 iterations of a GUI, satisfied by the project plan, or requirements for a user manual). Maybe bring these into the model at the top level, but then refer out to other documents where they are satisfied. Variants Need to keep the variant functionality separate from core functionality. Possible ways: by having separate models and include-by-referenced (has some problems for Gateway); have single model but with alternative blocks for some functionality. Different types of links Basic link is <<satisfy>>, but may also want to link with <<implements>> to the software. Gateway can use links in three modes: a) Link using <<satisfy>> in Rhapsody model b) Link in DOORS and import links c) Link in Gateway (maybe useful for links between Word docs) Outstanding ? collecting the info for hand-off Need to provide a consolidated set of functional and non-functional requirements for hand-off to the subsystem teams (not just UML software ? may be mechanical, electrical, etc). How do we collect into a hand-over pack? Please feel free to discuss further... |
|
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.