|
| 1 | +## [ModelWriter] Havelsan - Product Owner Review Meeting (30-07-2015) |
| 2 | + |
| 3 | +### Agenda |
| 4 | +1. *Discussion of HAVELSAN presentation presented in the workshop of Belgium* |
| 5 | + + Translation from Requirement document to structured requirement object |
| 6 | + + Translation from Model to structured requirement object |
| 7 | + + Havelsan ext - Traceability Matrix |
| 8 | + + Havelsan ext - Suspect Analysis |
| 9 | + + Havelsan ext - Document Generation |
| 10 | + |
| 11 | +----------------------------------------------------- |
| 12 | +### Notes taken while the demonstration of the proprietary ALM (Application Lifecycle Management) tool of HAVELSAN |
| 13 | + - Although requirements are kept tracked online as Structured Requirements Objects, an infrastructure built on top of Microsoft Team Foundation Server by the ALM department of HAVELSAN, clients such as SSM (Undersecretariet for Defense Industries) and TSK (Turkish Armed Forces) enforces to get them in the form of specific document formats such as SRS/HRS (Software/Hardware Requirement Specification, System Subsystem Specification Documents etc.) for the sake of specific regulations. To this end, those documents delivered to clients are automatically generated easily, thanks to Structured Requirements Objects. However, if the client makes some changes on the document, those changes cannot be transferred into the tool automatically, but only manually. This situation may expose problems in traceability. |
| 14 | + - Document View/Generation: This tool of Havelsan generates specifications based on several word templates aligns to several industry standards. Some sections in the documents are filled manually but the most important section which describes specifications are enumerated with regards to structured requirement objects based on structured selection. Several traceability views are inserted in a tabular format into the documents. |
| 15 | + - Description field of requirement objects are not utilized since the information provided in this field is in the form of natural language. The texts in this field has not been able to be processed until now. |
| 16 | + - Several domain knowledge have been accumulated by each contract/project. Especially in command and control systems, the legacy software artifacts may be analyzed and after a commonality and variability analysis a knowledge base can be constituted. |
| 17 | + - Requirement Flow in Havelsan: Contract Requirements -> System Requirements -> Software/Hardware Requirements. |
| 18 | + - Every system/software requirement shall map to one or more contract requirements. For that reason, every workitem (requirement, specification, task, test case etc. should be tracked for changes) |
| 19 | + - Traceability Matrix View between different type of requirements (such as parent-child relationship). Each contract requirements are decomposed into system requirements and so on, every entry in a requirement document should have a relation with the entries of a parent document. |
| 20 | + - Example of a traceability scenario: Eray, software engineer, has written a test case for a feature, but has no information about the change in the requirement which has an impact on the feature and results the test case would become outdated. But the system notifies Eray about the change. Eray reviews and conforms the change. |
| 21 | + |
| 22 | +---------------------------------------------------- |
| 23 | +### Suggested Features for ModelWriter Platform: |
| 24 | + 1. *Versioning of each mapping (aka linking)* in order to be able to perform a possible rollback/undo operation. |
| 25 | + 2. *Tagging of Marking (such as Baseline) and Typing of Mapping (such as relationship type -Composion or shared-)* |
| 26 | + - Baseline (TR. “temel çizgi”) Scenario: Baseline means that every changes made after the date of the baseline should be tracked. It's like to take a snapshot of the system. This feature enforces ModelWriter to be integrated with the a git server (in Eclipse it is called EGit). Every concession request after a baseline must be approved by the client. |
| 27 | + - Assigning tags to markers enhances the analysis of the system under design. For instance, the tag information can be used for filtration purposes while creating traceability matrix view. |
| 28 | + - Assigning types for mapping (linking) such as parent-child, predessor-successor can be used for analysis of the system in traceability matrix view and suspect analysis view. |
| 29 | + 3. *Traceability Matrix View* |
| 30 | + 4. *Suspect (Impact/Change) Analysis View* |
| 31 | + 5. The semantic of marking and mapping can be defined by relational logic |
| 32 | + |
| 33 | +---------------------------------------------------- |
| 34 | +#### Conceptual Design - Inputs |
| 35 | + |
| 36 | + + **Tagging of Marking** |
| 37 | + |
| 38 | + |
| 39 | + Marking | Type/Tag (user defined) |
| 40 | + ------------|---------------- |
| 41 | + x:marker | Requirement |
| 42 | + | Feature |
| 43 | + y:marker | Issue |
| 44 | + | Change Request |
| 45 | + z:marker | Artifact |
| 46 | + | Feature |
| 47 | + a:marker | Test Case |
| 48 | + b:marker | Concept |
| 49 | + | Test Case |
| 50 | + c:marker | Model |
| 51 | + | Feature |
| 52 | + d:marker | Concept |
| 53 | + | Feature |
| 54 | + |
| 55 | + + **Typing of Mapping** |
| 56 | + |
| 57 | + |
| 58 | + Marking | Relation Type | Marking |
| 59 | + ---------------------|-------------------|----------------- |
| 60 | + x:marker | >>composed_of>> | y:marker |
| 61 | + | >>composed_of>> | a:marker |
| 62 | + y:marker | >>relates_to>> | z:marker |
| 63 | + c:marker (Feature c) | >>requires>> | d:marker (Feature d) |
| 64 | + c:marker (Feature c) | <<validates<< | b:marker (Test Case b) |
| 65 | + |
| 66 | + If x:marker is deleted, y:marker and a:marker should be deleted as well. |
| 67 | + First Order Logic constraints can be added as well. |
| 68 | + For all marked elements which are tagged with "Issue" ... |
| 69 | + |
| 70 | +---------------------------------------------------- |
| 71 | +#### Traceability Matrix View -Output |
| 72 | + + **Feature -> Test Case** |
| 73 | + |
| 74 | + |
| 75 | + - | TC: marker_a | TC: marker_b |... |
| 76 | + ----------------|-----------------|---------------|----------- |
| 77 | + F: marker_x | >>composed_of>> | ! |... |
| 78 | + F: marker_z | ! | ! |... |
| 79 | + F: marker_c | ! | <<validates<< |... |
| 80 | + F: marker_d | ... |... |... |
| 81 | + |
| 82 | + Rule: Each Test Case must have some feature. |
| 83 | + |
| 84 | + |
| 85 | + Tag: Feature | Tag: Test Case |
| 86 | + ----------------|---------------- |
| 87 | + F: x:marker | TC: a:marker |
| 88 | + F: z:marker | n/a |
| 89 | + F: c:marker | TC: b:marker |
| 90 | + F: d:marker | n/a |
| 91 | + |
| 92 | + + **Requirement -> Feature -> Test Case** |
| 93 | + |
| 94 | + |
| 95 | + Tag: Requirement| Tag: Feature | Tag: Test Case |
| 96 | + ----------------|----------------|---------------- |
| 97 | + R: marker_x | marker_a | |
| 98 | + R: marker_z | n/a | |
| 99 | + |
| 100 | +#### Suspect (Impact/Change) Analysis View -Output |
| 101 | + + Based upon a selection of a marked element, user can start a suspect analysis. Default Graph depth may be provided by the user as well. |
| 102 | + |
| 103 | + |
| 104 | + Depth: 2 | Level 1 | Level 2 |
| 105 | + -----------|-----------|--------- |
| 106 | + x:marker | | |
| 107 | + | y:marker | |
| 108 | + | | z:marker |
| 109 | + | a:marker | |
| 110 | + | | b:marker |
| 111 | + | | c:marker |
0 commit comments