Documenting interfaces has always been a challenge. We put the interface requirements in a separate document and give that as a part of the documentation to the groups designing on both sides of the interface. Now I have a single document with all aspects of the interface neatly covered, but when I look at my system requirements, I am missing some aspects that are hidden away in various interface specifications. It would be nice to have all my environmental requirements in one place, all my physical requirements in one place and so on. For complicated interfaces, perhaps a separate document is a good idea, but for simple interfaces, I think there is a better way.
This is another post about the IBM Rational DOORS Next Generation with Configuration Management Beta software, for more information go to jazz.net where the beta is available to try, and the development is being managed in a publicly visible Rational Team Concert database.
I had assumed that every engineer, or analyst working in DOORS Next Generation with Configuration Management, would have their own workspace and deliver changes to a parent workspace managed by an integration engineer of some description.
A little while ago, I posted about Real Configuration Management for Requirements, but I didn’t go in to any detail about HOW it should, or could be used. Requirements engineers/managers are not typically working with configuration management at this level on a daily basis, so I have set out a very basic flow here. First of all, you need to know that this post describes working with an open Beta release of DOORS Next Generation, and all manner of changes can occur before this functionality is ever released.
I set up an empty project as described in my previous post to work through the basic exercise shown in the image here. One Variant, with one Version, and two Engineers working on the problem. I thought it best to start simple and find out how this might actually work for real. If I lose you in the description then come back to this diagram for reference.
I posted a while ago on using DOORS Partitions for offline working. In that post, I mentioned that we had worked out a process for managing the data in a supply chain, and that is what I am going to cover here.
In an ideal world, you would have your suppliers directly accessing your data on your server through a secure hole in your firewall. In practice this seems to be a very rare occurrence. Even where I have seen access granted, it has been on a separate LAN so that you plug in to a red CAT5 cable to access the customer network. Web based tools are pointed to as a silver bullet for collaboration, but in fact there is no difference between allowing someone from outside your organization to access a secure web based tool with a browser, or allowing them access through a DOORS thick client to your database. This problem is not one of technology, but one of security and people.
DOORS Next Generation is getting Configuration Management capabilities. This is a huge step for DOORS NG, a requirements management tool. The CM capability is similar to what you might expect for source control, with similar language, like ‘streams’, ‘deliver’, ‘workspace’, and others. I think that we will find that many requirements management users (or Business Analysts) who are unfamiliar with the concepts and terms, and there will be much confusion to resolve. However, the capability will be very much welcomed by the user community who are looking for stronger governance over their Requirements Management process.
Be part of a social experiment: share the IBM Innovate hallway conversations. IBM Innovate is soon to be underway, running from 1-5 June 2014. This year I didn’t get the Golden Ticket, so I am changing my name to Cinderella and staying home. I realized that I didn’t have to let a little thing like […]
As our world becomes more connected, this topic comes up less often, but it is still an issue for many people. I am not talking about data sharing down the supply chain here, but about taking your work away with you on a laptop and returning it to the corporate database with updates some time […]
I have been playing with the idea of a very generic process core. It is sufficiently abstract to not be useful on its own, but only as a pattern for building content. I think there may be a small handful of these generic patterns. I am still considering how many other patterns I need, and […]
Following on from the Information Architecture Workshop series, I want to show an example of how some of that information should be documented. A comprehensive document should be made available, but also a summary document for quick reference and guidance. Some years ago we produced a quick reference document for a generic schema and process, […]
From the previous three articles in this series, we know what we have and what we want to have; we just have to plan the route. I have started this section with definition of the database schema, which is arguably a part of the to-be. I have included it in this roadmap planning phase because […]