Business Requirements in BambooRM
Okay we all know that business requirements are pretty important to a successful project. We also know that requirements' gathering (data and process) is also a vital part of successful project management and application development. In this week's blog I would like to showcase the ease with which BambooRM can be utilized to define the business data and system requirements at the start of a development project and how that will help ensure your project is delivered on time and on budget.
Let's look at how we can use BambooRM business requirements to correctly gather all the needed data for our requested development project. In a previous post, I discussed using the discussion board feature in BambooRM as a way to interact with team members as well as keep project related discussions available and centrally located for your project. In this blog I would like to take the discussion data and move them into a business requirement. In the before mentioned blog, this sample project team has used the discussion board to hash out a request from HQ for an internal corporate portal.
From Discussion Board to Business Requirement
Okay so now let's look at the actual business requirement feature itself. By clicking on the requirements management tab you are brought to the business requirements landing page.
From this page click on the link for...you guessed it, Business Requirements. You'll notice in the above screen shot I have already created three business requirements for our project deployment. Due to the fact that our team utilized the discussion board feature, I was able to quickly and accurately pull the three main business requirements for this project, directly from the discussion board.
For this project, using the project discussion board, we have determined that there are three business requirements needed for this project. They are, Deploy and configure the server infrastructure, Create and configure a shared service provider, and Create site collections and SharePoint sites.
Let's take a look at the data contained in the business requirement, "Deploy and configure the server infrastructure".
The fields for a requirement are as follows, title, description, difficulty, status, risk, owner, priority, estimated total hours, parent reference, and discussion item. There you go; you have a direct link to the determining factor for this requirement. This will help you later on down the road when your PM or customer says, "Why was that considered a requirement in the first place?" You're given the ability to say, "It's in the requirement itself...look at the associated discussion, we talked about this and determined it was a requirement that needed fulfillment". That is but one level of traceability in BambooRM. I don't need to tell you how essential traceability is to successful project management. Also it should be noted that I have only just scratched the surface with regards to traceability within BambooRM. In the upcoming weeks you should be seeing a blog on traceability alone. Another aspect of traceability that I wanted to point out is the versioning feature built into BambooRM. Notice on the screen shot that each requirement gets stamped with current version of this requirement, when it was created and by who, as well as when it was last modified.
In this screen shot you'll notice that I have modified the risk, and est. total hours. Those changes are logged and reflected on that requirement. You can access the requirement versioning by clicking on the versioning history tab on a particular requirement. All your changes are tracked and stored for easy reference
Alerts for changes made to requirements
No problem...Another built in feature is the alerting feature that is standard with WSS. By accessing the alert me feature you have the ability to assign alerts for yourself or your team. Clicking on the alert me feature brings you to the alert configuration page for a particular requirement.
It's on this page that you can configure the alerts title (or accept the default title which would be the requirement title) you can determine who will receive the alert, yourself, another team member, or the team as a whole. Also you have the ability to specify whether to filter alerts based on specific criteria; if anything changes, if someone else changes an item, if someone else changes an item created by me, and if someone else changes an item last modified by me ... it's not as iffy as it sounds...zinger!!! Excuse my digression; the last configuration aspect of the alerts page is when the alerts should be sent; immediately, a daily summary or a weekly summary.
Work flow for requirements
Another thing I want to highlight is the workflow capability behind BambooRM requirements. With BambooRM you have the ability to set up a review workflow for a requirement that you determine a team member needs to review. By clicking on the workflow button, on the particular requirement you want workflow to be on, you are brought to the workflow configuration page.
On this page you simply click on the review workflow link, which then brings you to the review workflow page, it's here where you set up who is going to receive the review workflow and include a message for that team member.
Once you do that an email is generated that informs the user that he or she has been assigned a task related to a particular requirement. In this case it's to confirm that there are no planned upgrades for WSS in the near future and if there are make sure to spec out the hardware to accommodate our eventual migration to the newest version.
We can go back to the project site and see that automatically the task is created for the team member. The team member is required to check on the latest version vs. any upcoming new versions.
Here is a sample of the email generated by the workflow….
The user needs to click on the Edit the task to mark the task as complete….
The respondent has indicated that this task is now completed...Well then, what's the difference with workflow in BambooRM and just sending an email to your team member. I know...I know one of my major points with regards to potential problems for projects is lost or useless communication via email. In my own defense...even though BambooRM workflow is actually using email to notify the team member that a task has been created in connection with their project site, the difference between "just email" and a BambooRM requirements workflow is the fact that its recorder and stored within BambooRM and your particular project site. It's also available for all team members to review anytime from anywhere. No longer is it stored in an individual team members email account, personal folder, or desktop, file share.
On the onset the requirements in BambooRM seems a little simple. And in my mind that's how they how it should be. Good requirements should be free of implementation specifics (state what, not how), they should be accurately stated in few words, and they should support the stated business, system and project adjective. With BambooRM you get that and a whole lot more!
Stay tuned for my next blog when I go over functional requirements in BambooRM and how they can be associated with parent requirements and functional groups.
Posted
Mar 17 2010, 01:05 AM
by
Steve DaRonco