Gold-plating is something we don't often associate with software. However, it has a very specific definition when it comes to systems. Gold-plating is what happens when software developers often add features or functionality that they think would be interesting, but the customer hasn't requested. Gold-plating can be identified using a technique called traceability. We're going to use this video to talk about traceability and its importance in identifying problems and issues in the implementation of the software. Now, gold-plating is a fun example where developers can often get carried away implementing functionality, but traceability has a very real purpose in ensuring that the system that's eventually developed meets the requirements it was developed to satisfy. After this video, you'll be able to define traceability as it relates to our system requirements, and describe at least one approach to documenting traceability. There are many, many ways to document traceability. Finally, we will talk about two different types of traceability and why each is important. Just a reminder that we're in the analysis phase of the software systems development life cycle, and right now our focus is on writing good requirements, which is one of the primary roles of the business analyst. Other videos will feature additional documentation and diagrams that the business analysts prepares and analysis phase, as well as talking about the role of the business analyst in future phases of the SDLC. Traceability is a technique that ties all project artifacts together. It is a required practice in many regulated industries. For example, an auditor might show up, and you might make a claim about the battery in your medical device. The auditor might then ask, "How do I know that this battery meets this specification? " Oftentimes, then the people hosting the audit would then go to a traceability matrix to find out when and where are the battery was tested to make sure that met that particular spec. Many enterprise case tools, which is short for computer aided software engineering tools, support traceability in some form. So, in other words, if you purchased or your organization has purchased a requirements management tool or a user story database manager, if you implement agile, many times they implement traceability, sometimes through a simple field. That tells where that particular requirement or user story came from. There are a variety of other methods to handle traceability, and we'll look at a few examples. Here's one example that shows a pretty sophisticated traceability matrix. On the left, you have the source of the requirement, and then moving across the matrix here, we see that that requirement was exploded into two different product requirements. Those product requirements appeared in various documents that you see across the top, all the way down to the code unit, which is the precise file that implements that particular requirement. Test case numbers, which we'll talk about in future videos. Then, finally, how that particular requirement would show up in the user manual. This is a particularly detailed look at traceability they might use in a regulated industry, for example, avionics or medical devices. Here's another example of how complicated these traceability matrices can get. Now, this is an eye chart, I understand. The purpose is not to understand the details here, but just to show that these things can get quite complex, if you need them to be. On the other hand, we can often handle traceability in a much simpler way. This is an example that might use a traditional document tools such as Microsoft Word to manage requirements. You can see that in the fourth column over here, we have an interview, is the source of a particular requirement. So, there are many, many methods to handle traceability. Traceability is important throughout the systems development life cycle. Not just from source of requirements to the requirements document, but beyond the requirements document into test cases, the user manual, and the eventual implementation of the software. It's also important, once we get to the end of the systems development life cycle, that we have a way to trace the end product back into its constituent components. Because of this, we refer to two different types of traceability. Forward traceability moves forward through the systems development life cycle. Starting with the source of the requirement, making sure that it appears in the requirements documents and then further making sure that it appears in test cases, then it's finally tested and in the released product. Backward traceability starts at the end of the system and its development life cycle, and moves backwards. It starts with an end product, and then moves backwards to make sure that we can find evidence of those features in the test cases that the test cases are tied to requirements, and that the requirements actually came from a business user. My question for you is, which one of these types of traceability identifies the gold-plating that I referred to at the beginning of this video? This pretty much wraps up our detailed look at requirements. Future videos will talk about other aspects of the analysis phase and the business analyst's role in those artifacts.
