view release on metacpan or  search on metacpan

lib/App/Requirement/Multidimensional_Requirement_Database.pod  view on Meta::CPAN

Enable also use of a simple file system structure were each baseline is stored in a separate folder (possibly only the difference in each folder).
Why?
1) Enables easy manual investigation of different baselines.
2) Enables generation of difference reports with existing (simple) tools.


----- Hierarchy of requirements and responsibilities -----

MD = Marketing Department
PO = Product Owner

Marketing requirements (very high level; MD)           -
     |                                                 |
High-level Use Cases (PO)                              | Regalutory & standards (MD; PO; R&D)
     |                                                 | 
    SRS (R&D)                                          |
     |                                                 | Feature list, strategically
Subrequirements (R&D)                                  |  important features (MD; PO)
     |                                                 |
 User stories (R&D)                                    -

Feature list: in this example it corresponds to the "importance" dimension. A strictly hierarchical PRS it would fit between the MR and UC or between UC and SRS.

Observation: If an SRS requirment don't map to a higher level (MR, UC or feature list) it's not traceable.
- Is that a problem?
- Would a solution be to add marketing requirements like "The product quality shall be good enough for the mass volume market" or "The product quality shall be top-notch"? That is, some marketing characteristic or product strategy sets overall princi...


----- Application Lifecycle Management (ALM) -----

* Types of items in a complete Application Lifecycle Management (ALM) approach:
- requirement
- test case
- test plan
- design specification
- development task
- time plan
- release plan

* Complete hierarchy
These items can be connected into a hierarchy based on the requirement hierarchy, thereby catching most or all aspects of a development project.

Types of relations:
- structure: breakdown, consists of
- history; derived from, revision of
- conceptual links or traces: satisfies
- references

* Work flow
Each item type can be associated with its own work flow, which defines how an individual item is to be processed and enables tracking of progress (by developers, project managers, managers etc).

* Time plan
Timeplans can be automatically created from:
- start dates
- available man power
- requirement priorities
- requirement dependencies
- release scope

Timeplans are automatically updated based on:
- states of current work flows


----- Views -----

Views based on hierarchies or attribute values:
 - standard: ...TBD...
 - single top level requirement breakdown
 - requirement breakdown with references (alphabetical order)
 - requirement breakdown with references sorted by category
 - requirement complete breakdown, i.e. requirements with multiple parents are displayed more than once
 - abstraction level (alphabetical order)
 - abstraction level sorted by category
 - category
   1.use explicitly defined categories (no breakdown)
   2.without explicit category: use parent´s, display broken down
 - analysis:
 	> text patterns
 	> statistics 1: # req's in different categories
 	> statistics 2: # words in individual req's
 	> statistics 3: # links/relations in individual req's
 - importance ~fetaure list?

Filters:
 - views are a kind of filters but here filter means an addition on top of the views
 - basically any attribute can be used to filter
 - state: to be able to see e.g. released requirements (may infer stricter change control)


----- Metadata -----

- Unique id per requirement - UUID
- Type: use case, requirement
- Name
- Abstraction level
- Origin (database, etc)
- Creator (author)
- Category
- Description
- Long description
- Rationale
- Fit/test criteria
- Satisfaction
- Dissatisfaction
- Related requirement
- Subrequirement
- State
- (Possibly) Implementation priority
- Branches/projects/products...
- ...


----- Mapping/linking between different item types -----

Test case mapping
- Where shall the link be placed:
	 from test case file/script to requirement?
	 from test case tool/db to requirement?
	 from requirement to test case?
- Automatically create map