Earlier in the series:
Up until now, we’ve been talking about stuff that might seem to be interesting just for geeks. Today, I’m going to tell you how DITA can be extremely beneficial for those guys who are traditionally seen as a profit center in any company. I’m talking about pre-sale teams and product managers.
So here comes Reason #6:
Suppose you are analyzing requirements for a big project, say, like building a flying car.
This involves a lot of work of capturing, defining, estimating, and planning requirements. We might be talking about hundreds or even thousands of requirements. Some of them have various kinds of relationships between each other that you can’t just memorize.
For example, the auto-pilot feature can be implemented only after a high precision radar is done. The high precision radar requires that the construction of the car roof would have a safe place where the radar will be mounted. A special construction of the roof imposes certain limitations on the car design and features.
From the development perspective, each of these requirements are independent tasks that will be probably done by different people or even by different teams. However, in the context of the entire project, they are all interconnected.
At some point, the product management decides to give up the auto-pilot because it requires getting a special license from the federal government which may take years and cause a significant delay in the project. You now have to redo the project documentation and update the cost estimates. Obviously, it’s not enough just to remove the auto-pilot from the projects specs, and deduct the cost of developing this feature from the total estimate. Now, when the auto-pilot is irrelevant, perhaps the radar doesn’t have to be so precise. This may mean that it can be smaller, which may affect the requirement about its location on the roof. This means that the construction of the roof may now have less constraints, and so on. Plus removing the auto-pilot from the project means that a whole set of other requirements won’t make sense any longer at all, and they have to be taken out of the project scope too.
But understanding the relationships between requirements alone isn’t a big deal. After all, big requirements management systems, like DOORS, let you define and analyze how different individual requirements are linked to each other.
A big deal after updating the project scope is to instantly and automatically re-assemble a set of documents built from a large amount of individual semantically interconnected requirements: specs for developers, test cases for a QA team, cost estimate and project implementation plan for management, and so on. In each document the same information might be represented differently. For example, in the specs, the requirements are rendered just as plain text while in the cost estimate document, they are automatically divided based on project phase and accompanied by the subtotal and total estimates (whose level of detail might be different for different audiences, by the way). I was blogging about it here.
Now, because DITA is all about structure, you can combine it with a technology that parses individual requirements, retrieves metadata about relationships and estimates, disintegrates the requirement and metadata into pieces of information, and then aggregates them into new artefacts. So after the project scope is changed, you can instantly get the updated set of relevant project documents, and clearly see how the change affected the entire project, including whether other requirements should be now excluded, how the estimate changed, what other requirements are affected, and so on.
This capability can be extremely beneficial for:
In the next post, I’m going to talk about building such a technology, and why it’s so great to build it with DITA.