Copyright DB Netz AG, licensed under CC-BY SA 3.0 DE (see full text in CC-BY-SA-3.0-DE)
ARCH.048 Identify system implementation constraints
Goal | Produce a list of candidate non-functional requirements on the system, derived from implementation constraints |
---|---|
Requirements met by this process step | ISO 15288 6.4.2.3 b 2)-4), d 2)-3), e 2)-4) |
Inputs | AMOD-010 Trade space assessment AMOD-012 System lifecycle model IM standards applying to any point of the engineering lifecycle Expert knowledge of railway engineering delivery |
Outputs | AMOD-049 Non-functional requirements implementation |
Methodology | The trade space assessment is a starting point in understanding tradeoff factors for the system under development. At this point in the process, a more detailed knowledge of the specific constraints on the system's implementation should be introduced. Constraints may be based on non-tradeable limitations (like the laws of physics, for example) or on tradeable limitations where a certain choice has been made and we don't propose to change it (for example, the need for earthing and bonding of trackside equipment is there because the line is electrified with OLE and whilst we could say "remove the OLE for our system" we choose not to). This requires understanding of the lifecycle and of the tradeoff factors. Implementation constraints will have been communicated to suppliers many times in previous specifications. They may also be found in laws, international standards, and IM standards. We must decide if the system is to comply with these existing requirements, or if the IM is to lobby for changes to these requirements. Either outcome is possible but we must take account of the time and effort needed to persuade government to change legislation. We will probably need to consult with our neighbouring organisational units who are more experienced with implementation of equipment on the track, in order to pick up the needs and practical considerations that we should include. At all points we should (internally) question everything we are told and satisfy ourselves that these constraints are either non-tradeable or firm decisions before accepting them. |
Tools and non-human resources | Brainstorming resources (optional) KRWD Perinorm |
Cardinality | One-off with possibility to revise |
Completion criteria | The set of identified constraints is complete enough with respect to the stage of maturity of the system (this means that it is not necessary to identify 100% of constraints the first time this activity is done; but there will be a point where it is necessary to gain assurance that we have covered enough constraints to make the set safe enough to fly. This will come at the point where there are no further opportunities to iterate before delivering the first system implementation into service.) |
Design review | |
Step done by (Responsible) | Lead system architect |
Provides input to/assists (Contributes) | Implementation experts including from neighbouring business units |
Uses outputs (Informed) | None directly |