Comparing and Contrasting Requirements with Work Items
Hi
Welcome to this new forum on systems engineering and embedded software. To kick things off I thought it might be good to start a conversation around the use of requirements and work items together in a systems context.
As more and more development support tools become integrated, the similarities and, perhaps more importantly, differences between terminology and process are brought to light. This can be most often true for requirements management and traceability tools, the most powerful of which allow for the traceability to artifacts across the entire lifecycle, and therefore interact with, and have an impact on, the terminology and processes of all manner of other tools. Requirements and Work Items are not only totally different artifacts, but they also each serve a separate purpose and can only do their job if they are not conflated or forced to represent one another for the purposes of traceability. Requirements and Work Items are key elements in managing projects and should each be treated accordingly.
Here are some questions for consideration:
How would you best define the difference between a requirement and a work item?
How do you relate requirements and work items together through the lifecycle?
Welcome to this new forum on systems engineering and embedded software. To kick things off I thought it might be good to start a conversation around the use of requirements and work items together in a systems context.
As more and more development support tools become integrated, the similarities and, perhaps more importantly, differences between terminology and process are brought to light. This can be most often true for requirements management and traceability tools, the most powerful of which allow for the traceability to artifacts across the entire lifecycle, and therefore interact with, and have an impact on, the terminology and processes of all manner of other tools. Requirements and Work Items are not only totally different artifacts, but they also each serve a separate purpose and can only do their job if they are not conflated or forced to represent one another for the purposes of traceability. Requirements and Work Items are key elements in managing projects and should each be treated accordingly.
Here are some questions for consideration:
How would you best define the difference between a requirement and a work item?
How do you relate requirements and work items together through the lifecycle?
10 answers
It seems to me that requirements result in some related set of work items being created which can each be tracked to completion. The set of work items can be related or dependent upon one another in all sorts of ways.
What is most important is that by starting with any one item (work item or requirement), that a developer, tester, designer, or project manager can find all the interdependent other items (be those requirements which inspired the work item or other work items that are dependent upon or work items that were created to address the requirement).
What is most important is that by starting with any one item (work item or requirement), that a developer, tester, designer, or project manager can find all the interdependent other items (be those requirements which inspired the work item or other work items that are dependent upon or work items that were created to address the requirement).
Hi
Welcome to this new forum on systems engineering and embedded software. To kick things off I thought it might be good to start a conversation around the use of requirements and work items together in a systems context.
As more and more development support tools become integrated, the similarities and, perhaps more importantly, differences between terminology and process are brought to light. This can be most often true for requirements management and traceability tools, the most powerful of which allow for the traceability to artifacts across the entire lifecycle, and therefore interact with, and have an impact on, the terminology and processes of all manner of other tools. Requirements and Work Items are not only totally different artifacts, but they also each serve a separate purpose and can only do their job if they are not conflated or forced to represent one another for the purposes of traceability. Requirements and Work Items are key elements in managing projects and should each be treated accordingly.
Here are some questions for consideration:
How would you best define the difference between a requirement and a work item?
How do you relate requirements and work items together through the lifecycle?
Hi
Here are some questions for consideration:
How would you best define the difference between a requirement and a work item?
How do you relate requirements and work items together through the lifecycle?
Requirements, when tracked formally, can exists at various level, e.g. system/software specification level (system/software requirements), design requirements & test requirements.
At each level, against each requirement, you can create a work item to assign a task to someone, track the changes/progress and link to the checked in deliverable. You would also assign a release tag to the work item, to identify which iteration release, the results of the work item will be present it (e.g. feature, enhancement, etc).
A parent work items should also be able to spawn multiple child work items, so that a manager can split a large chunk of work, to smaller chunks to a team or a set of individuals.
Interesting and timely questions. I would define a requirement as a system capability or characteristic that makes a stakeholder happy. In smaller systems or programs, requirements and work item can take the same form, ala user stories, epics. Most would agree that larger systems and programs need a separate, up-front effort to understand requirements (DOORS) and a schedule that shows when each capability will be implemented. Frankly, I dont think we can talk about relating work to requirements without discussing schedule. Customers spending large $s on a large program need confidence to award and start funding their project what will I get and when will I get it. Small projects can begin with little investment and little risk and therefore dont go through the up front effort of making requirements and schedule assumptions.
Regarding work and schedules, traditional projects build a master schedule (IMS) up front showing the work required to accomplish the requirements. The IMS has milestones tied to awards ($$) for the program, so meeting those tasks is critically important. So we typically have a bunch of people (managers) running around with disconnected spreadsheets and MS Project plans trying to make sure people are working towards the IMS very chaotic.
I say this question is timely because one of our customers is beginning a very large program and replacing the running around part with RTCs hierarchical work and planning. The goal is to track engineering activities directly to the IMS. IMS tasks are imported into RTC, decomposed by managers (vs. spreadsheets and MS Project) into tasks assigned to engineers. RTC provides automatic progress and roll-up as engineers complete work. And all work and progress is available to everyone. Lots of upside less chaos, more accurate where are we, less miscommunication from segments on how far along they are, etc. And the work will be related to requirements in DOORS. We hope to have a nice progress presentation on work types, etc. at Innovate 2011.
My .02 on requirements and work.
Regarding work and schedules, traditional projects build a master schedule (IMS) up front showing the work required to accomplish the requirements. The IMS has milestones tied to awards ($$) for the program, so meeting those tasks is critically important. So we typically have a bunch of people (managers) running around with disconnected spreadsheets and MS Project plans trying to make sure people are working towards the IMS very chaotic.
I say this question is timely because one of our customers is beginning a very large program and replacing the running around part with RTCs hierarchical work and planning. The goal is to track engineering activities directly to the IMS. IMS tasks are imported into RTC, decomposed by managers (vs. spreadsheets and MS Project) into tasks assigned to engineers. RTC provides automatic progress and roll-up as engineers complete work. And all work and progress is available to everyone. Lots of upside less chaos, more accurate where are we, less miscommunication from segments on how far along they are, etc. And the work will be related to requirements in DOORS. We hope to have a nice progress presentation on work types, etc. at Innovate 2011.
My .02 on requirements and work.
I say this question is timely because one of our customers is beginning a very large program and replacing the running around part with RTCs hierarchical work and planning. The goal is to track engineering activities directly to the IMS. IMS tasks are imported into RTC, decomposed by managers (vs. spreadsheets and MS Project) into tasks assigned to engineers. RTC provides automatic progress and roll-up as engineers complete work. And all work and progress is available to everyone. Lots of upside less chaos, more accurate where are we, less miscommunication from segments on how far along they are, etc. And the work will be related to requirements in DOORS. We hope to have a nice progress presentation on work types, etc. at Innovate 2011.
I used to do something similar with Synergy/Change a long time ago. It had a MS Project integration, so we define the master schedules, and attach Synergy/Change tasks from the CM repo to MS Project. All engineers get their work allocated through the change management system (action item, defect, enhancement), and the status in MS Project gets updated automatically. Someone has to take care of importing tasks as and when they get created, that was the only downside for that integration.
Coupled with the DOORS integration with Change, it allowed you to have a good control over integrated requirements/change/project progress tracking.
The newer platforms take this integration even further, but I haven't tried it yet. Seen the videos but haven't tried it first hand. But I would imagine, the goal is to achieve this type of integrated project control, coupled with project management using an iterative development lifecycle.
Hi
Here are some questions for consideration:
How would you best define the difference between a requirement and a work item?
How do you relate requirements and work items together through the lifecycle?
Requirements, when tracked formally, can exists at various level, e.g. system/software specification level (system/software requirements), design requirements & test requirements.
At each level, against each requirement, you can create a work item to assign a task to someone, track the changes/progress and link to the checked in deliverable. You would also assign a release tag to the work item, to identify which iteration release, the results of the work item will be present it (e.g. feature, enhancement, etc).
A parent work items should also be able to spawn multiple child work items, so that a manager can split a large chunk of work, to smaller chunks to a team or a set of individuals.
I think this is somewhat of a loaded question. IMHO, traditional scheduling in MS Project-type tools work well for structural part of complex systems (hardware, facilities, technical docs, etc) because the risk and uncertainty is relatively bounded. The software aspects are where traditional requirements and planning efforts struggle and where other approaches (lean and agile) appear to offer significant benefit.
So frankly I don't think the answer lies in solely in an agile planning approach. One is not going to collaboratively plan and schedule a facility roll-out with stories and epics as dependent tasks in a WBS with a critical path, EV, etc. is a more appropriate choice. But the behavioral aspects are better understood and tracked with an agile planning approach - continuous review and feedback.
The problem is which tool? Traditional PM tools (MS Project) look at the problem one way and agile planning tools (RTC, VersionOne, Rally) look at it the other way. I think RTC 3.0's traditional planning additions may really offer an important sweet spot for allowing both planning methods to co-exist. And I expect over the next few months we will see some practices emerge based on these new capabilities.
My .02.
Try RTC ExpressC. Its brilliant collaboration tool, very easy to setup, jazz based (web and rich client), not very light but not too huge also.... and it is community edition (FREE). For a small team of 10 developers its ideal.
So frankly I don't think the answer lies in solely in an agile planning approach. One is not going to collaboratively plan and schedule a facility roll-out with stories and epics as dependent tasks in a WBS with a critical path, EV, etc. is a more appropriate choice. But the behavioral aspects are better understood and tracked with an agile planning approach - continuous review and feedback.
The problem is which tool? Traditional PM tools (MS Project) look at the problem one way and agile planning tools (RTC, VersionOne, Rally) look at it the other way. I think RTC 3.0's traditional planning additions may really offer an important sweet spot for allowing both planning methods to co-exist. And I expect over the next few months we will see some practices emerge based on these new capabilities.
My .02.
I see a number of references to MS Project. I've always found MSP to be somewhat clumsy and difficult to work with but have yet to locate a suitable alternative. Does anyone have any suggestions?
Try RTC ExpressC. Its brilliant collaboration tool, very easy to setup, jazz based (web and rich client), not very light but not too huge also.... and it is community edition (FREE). For a small team of 10 developers its ideal.
Harry,
You are on the right track in noting that real systems have large integrated master schedules (IMS) that attempt to get all of the different disciplines (electrical, mechanical, structural, computing, and whatever else you might need) on the same page. The core issue is that these engineering disciplines each has their own best practice towards how they work the best. The key is to identify the core pieces of information that are common to each approach, and have that information integrated into that IMS.
The key here is that there are no surprises, and that risk be identified early. So I think having some way to highlight risk, some way to make REAL status and progress more transparent, and having a way to gauge the value added/earned is really what is critical. I would hazard a guess that RTC would suffice for the planning of the computing (software) pieces, but I would be willing to bet that the mechanical engineering community already has a way to track their work/progress, and that it works fairly well. You might want to utilize the Jazz infrastructure to help integrate the data, that would make sense.
You are on the right track in noting that real systems have large integrated master schedules (IMS) that attempt to get all of the different disciplines (electrical, mechanical, structural, computing, and whatever else you might need) on the same page. The core issue is that these engineering disciplines each has their own best practice towards how they work the best. The key is to identify the core pieces of information that are common to each approach, and have that information integrated into that IMS.
The key here is that there are no surprises, and that risk be identified early. So I think having some way to highlight risk, some way to make REAL status and progress more transparent, and having a way to gauge the value added/earned is really what is critical. I would hazard a guess that RTC would suffice for the planning of the computing (software) pieces, but I would be willing to bet that the mechanical engineering community already has a way to track their work/progress, and that it works fairly well. You might want to utilize the Jazz infrastructure to help integrate the data, that would make sense.