c55 w2

 “Traceability and Change Control” Please respond to the following:

Suppose a system had no traceability management present. Predict five problems that you believe could occur when change requests are made. 
Suppose you were a project leader. Propose five methods that you would use to manage change requests. Select the method that you think would work best for you and defend your selection.

Classmates:
 
Suppose a system had no traceability management present. Predict five problems that you believe could occur when change requests are made.
If a system had no traceability management, five problems could occur: inability to assess the impact of changes and/or whether requirements missing objectives, are being met, are following compliance regulations, and inability to manage scope, schedule, and costs.  The requirements document (RD) contains traceability links that allows project teams to assess the impact of a proposed or requested change.  According to Lamsweerde (2009), when a range is requested, project team members follow the dependency link of the RD item-to-be-changed backwards to find the context of the change and the source items on which the RD item-to-be-changed depends on.  The impact is then determined by following the links forward to find the dependency items that will be affected.
Second, the project would not able to determine if there is a reason for the RD item-to-be-changed to exist in the RD.  When the dependency links of the item-to-be-changed are traced upwards, it allows project team members to determine whether there is sufficient reasons and objectives for the RD item-to-be-changed (Lamsweerde, 2009).  As a result, the team could discover that the item-to-be-changed does not have sufficient reasons for being the RD. According to Lamsweerde (2009), “When no reason is found, we may question the relevance of this item” (p. 235).
Third, the project team would be able to determine whether the item-to-be-changed is being met in the first place.  For example, when a change request is received, project teams can follow the derivation links of the item-to-be-changed downwards to determine whether it is being covered (Lamsweerde, 2009).  If there is no traceability management, the project team would not able to determine this.
Fourth, traceability allows project team members to analyze the compliance regulations of requirements.  For example, project team members can assess whether the appropriate contractual, regulations, and standards are being covered by the requirements (Lamsweerde, 2009).  Without traceability management, this would not be possible.
Fifth, traceability allows project team members to determine the scope, schedule, and cost of changes.  According to Lamsweerde (2009), “When traceability chains include project management information about tasks, resources and costs, we may follow dependency links to monitor progress, allocate resources and control costs” (p. 235).  Without traceability management, requested changes could cause the project to fall out of scope, schedule, and/or cost.
Suppose you were a project leader. Propose five methods that you would use to manage change requests. Select the method that you think would work best for you and defend your selection.
Five methods I recommend for managing change requests are: formal change requests, a change review board, a database to manage change requests, an automated system to manage change requests, and/or an automated system to manage traceability.  I would recommend using a fully automated system to manage change requests.  Such a system would be customer facing so that the customer can submit formal change requests.  The system would request a description of the change and why it is needed.  Then they would specify the functional requirements that need changing.  The system would use this information to calculate the priority level.
Once the change request is submitted, an automated email would be sent to members of the change request review board that a new change request is received.  They would review the request and determine how important it is and whether it should be implemented immediately or wait until another revision of the product.  To ensure that reviews are not biased, the change control board would be made up of members that represent the collective stakeholders.
The final step in this automated system would be implementing the changes.  Approved change requests would be received by the development team and new user stories would be added to track the change.  During sprint planning meetings, the project team would meet to discuss when and how the changes should be implemented.
References
Lamsweerde, A. V. (2009). Requirements Engineering: From System Goals to UML Models to Software Specifications. Chichester, West Sussex, England: John Wiley & Sons, Ltd. Retrieved April 15, 2018, from https://strayer.vitalsource.com/#/books/978EUDTE00270/