Option to lock (or not) item traceability / relationships

Options
[Deleted User]
[Deleted User] Posts: 6
in
The inability to add or remove relationships to locked items can be a pain, but there are also some good reasons to have some control over whether to allow or not to allow it.  If we develop system or product requirements based on validated customer needs, should we really review and approve (and call the requirement good and legit) if we can't link it to the specific customer need/requirement?  And let's say the upstream relationships (e.g. customer reqt) were available in the Jama Review Center, such that the review and approval of the system requirement did have context, will they still be legitimate, and have that context if after the requirement is approved (and even locked) someone removes the related items upon which that approval was based, and relates a different one?  Can we still then say the requirement is valid, approved, legit?  Would that ever happen?  Oh yes, it will!

If I review a set of requirements or designs for a bicycle, it may be the best, most complete set I've ever reviewed, and I may be tempted to approve, unless I see it traced to the customer's need for a vehicle that can reach the next town over, 100 miles away, in 2 hours!  Or maybe it's already approved, and locked?  But clearly this doesn't satisfy the customer's need.  Did someone perhaps change the relationship?  Wish I could have locked that down!

Comments

  • [Deleted User]
    [Deleted User] Product Manager Posts: 35
    Options
    Hi Steve,

    Interesting, thanks for starting this discussion. You stated the problem well. Today it's not obvious whether locking a requirement also means locking its relationships because, as you point out, the relationships may add additional meaning to the requirement itself. Locking may also slow down reuse of already-validated work. The tricky thing when building this concept into Jama is determining exactly what element you are approving/rejecting/locking, and then making that obvious to other users.  

    In your example where someone has traced your most excellent bicycle requirements to a customer need to "reach the next town over, 100 miles away, in 2 hours", how would you communicate that requirement-to-customer need incompatibility to others? Thinking outside of Jama's architecture for a second, are you rejecting...
    1. The customer need --  you're saying "my requirements are spot on for the bicycle I've been asked to design, and this new customer need is incompatible"
    2. The bicycle requirements -- you're saying "now that these new customer needs are here, they invalidate my bicycle requirements"
    3. The relationship itself -- you're saying "neither the customer need nor the bicycle requirements are wrong themselves. One requirement simply doesn't serve the other" 
    4. The whole thing. The bicycle requirement, customer need, and the relationship -- you're saying "This set of 3 components (req-need-relationship) is wrong. Up to someone else to determine whether the customer need or the bicycle requirement needs to change, or just the relationship removed"
    5. All of the above
    6. None of the above <-- Please let me know if this is the case!
    Depending on what reviewers are hoping to say, we'd handle that differently in the Jama UI. It might mean in the future we add more control over relationship locking as you suggest, or the types of reviews. First we need to understand better what people are trying to say in human-oriented terms to make our UI reflect that. 

    Thoughts?

Categories