DOORS Information Architecture Workshop. Part 1 of 4

Setting up a new project in DOORS can be a little daunting.  The tool comes with an open and flexible way to structure your data, which is great if you are experienced, but not so great if you are new to it. The options are seemingly endless and the opportunities to back yourself into an unintended corner are certainly present.

The good news is that for experienced DOORS users, the flexibility is powerful, the options allow tailoring to the individual circumstances, and the whole usage experience controllable. An Information Architecture Workshop (IAW) can help to match the implementation to the project and organisational needs. Over this series of four articles I will go through the format of an IAW and some of the key activities undertaken.

The workshop consists of three parts:

1. What do you have (as-is)?
2. What do you want (to-be)?
3. A plan to move from as-is to to-be

This series of articles will cover:

1. What information needs to be collected for the as-is
2. How to collect the information for the as-is
3. Identifying the to-be solution
4. The plan to move from as-is to to-be

 

Step 1 is the hardest part and is the focus of the majority of the time. Step 2 is easier because much of the to-be is uncovered during the as-is discussion.  Step 3 is often straightforward; once we know where we are and where we want to be, planning a route is a task with clear boundaries.

What information do we need about the as-is situation?

The nature of all the data that will go into DOORS, where it is now, how it is related, how much there is, how many projects, what sizes of projects and any other information that exists. We are looking for information about the scope of the intended deployment, including server sizing, and possible performance issues.

How does the intended DOORS data link to other data in the project, which tools and databases are they held in, is there expected to be traceability, and at what level of granularity? Is there some of this data that doesn’t have a good home and would be better placed in DOORS? Here we are looking for potential integration points to the new deployment, and any opportunity to simplify by, for instance, removing a home grown spreadsheet solution.

What processes are in place, or need to be in place? Reviews, signatures, work tracking, change management, configuration management, risk management, and of course requirements management. Are these processes adequate for the business requirements? The tool is not going to be useful without process, and the processes will influence how the tool is configured. Any standards that have to be adhered to are also important, CMMI, ISO15288, ISO26262, DO178… the list is long but each organisation should only be working to a small handful of these.  There are requirements in the standards that influence the configuration of the tool, and these need to be understood.

What reporting and analysis is currently in place, is this adequate and is it useful? We need to ensure that we will capture all the information necessary to achieve the analysis, and we can potentially enable more detailed analysis that was previously desired, but too time consuming to enact.

Are there any known weaknesses with the current situation? – almost certainly the answer to that would be yes if someone is investing in a new tool, such as DOORS. Understanding the current weaknesses allows us to create a better vision for the to-be solution. Opening this area up for discussion can be difficult; either there is insufficient trust for people to highlight weaknesses, or there is insufficient restraint and this can lead to a general griping session. Internal politics will be at play here and a good facilitator is essential.

Finally, who is working with the data?  Understanding the experience of users is important, along with geographical distribution, willingness to change, and background. By understanding the users, training can be planned, roll out can be scheduled and the set up of the tool can be tailored to suit the users.  Geographic dispersion is important; setting up a tool for a collocated team is not the same as for a team that operates across multiple time zones. Network delays may also be a consideration for widely dispersed teams and the deployment should take account of this.

The set of questions is not fixed, and identifying the questions to ask is all part of the art of running an Information Architecture Workshop.

In the next article I will look at how this information is collected.