Seilevel
Seilevel Home
Back to Blog Home - Requirements Defined

Monday, December 22, 2008

Happy Holidays From Seilevel

Thank you for helping us make 2008 a great year. We want to take the time to acknowledge our friends, family and customers for the dedication and support you've given us.

Enjoy the holidays! We'll see you in 2009.


The Seilevel Team
Requirements Defined Newsletter Bookmark and Share

Thursday, December 11, 2008

The Seilevel 2008 Holiday Software Requirements Medley

It seems that we have an official tradition here at Seilevel.
Every year, we like to spread a little SeiCheer with our medley of holiday requirements songs.
If you enjoy these, you can go back to see the 2007 songs and 2006 songs.

Expert SME is Comin’ To Town
You better watch out
You better ask why
Better not tout
He’s breaking the tie
Expert SME is coming to town

Eliciting a list
Reviewing it twice;
Gonna decide which scope to slice
Expert SME is coming to town

He sees you when you're typing
He knows when you are late
He knows if the spec’s good or bad
At least try to hit the date!

O! You better watch out!
You better ask why
Better not tout
He’s breaking the tie

Expert SME is coming to town

Expert SME is coming to town

Requirement Drummer BA
Come they told me, pa rum pum pum pum
A new born SME to see, pa rum pum pum pum
Our requirements we bring, pa rum pum pum pum
To facilitate for the SME, pa rum pum pum pum,


rum pum pum pum, rum pum pum pum,

So to honor SME, pa rum pum pum pum,

When we’re done.
Newly found SME, pa rum pum pum pum
I am here for you too, pa rum pum pum pum
You have some scope to add, pa rum pum pum pum
That's fit to give to dev, pa rum pum pum pum,

rum pum pum pum, rum pum pum pum,

You will smile at us, pa rum pum pum pum,
When we’re done.

Last Christmas

Last Christmas, I gave you my scope
But the very next day, you cut it away
This year, to save me from tears
I'll give it to a new BA

Once bitten and twice shy
I keep my distance, prototypes catch my eye
Tell me BA, do you recognize the GUI?
Well it's been a year, agile’s working for me
I wrote it up and sent it

With a note saying "high priority", I meant it
Now I know what a fool I've been
But if you facilitated now I know you'd fool me again
Last Christmas, I gave you my scope
But the very next day, you cut it away
This year, to save me from tears

I'll give it to a new BA

Oooh. Oooh BA

A crowded room, SCRUM team’s tired eyes
I'm hiding from you and the process advice
My BA, I thought you were someone to rely on
Me? I guess I was a user to deny one
A face of a coder with a fire in his heart
Ready to build, but you tore it apart

Oooh Oooh

Now I've found agile BAs, you'll never fool me again

Product Bells
Jingle bells, product bells
Whistles all the way
Oh, what fun it is to plan
For a product launch today

Dashing through the code
With a one man team BA
Thru the halls we go
Writing all the way

Bells on testers ring
Making spirits bright
What fun it is to scope and sing
A requirements song tonight

Oh, jingle bells, product bells

Whistles all the way
Oh, what fun it is to plan
For a product launch today

Labels: ,

Requirements Defined Newsletter Bookmark and Share

5 Ways To Create Successful Projects With Fewer Resources

We are certainly living in interesting times, and according to conventional wisdom, it is a curse to live in interesting times. Changes in our world happen almost overnight, from the political to the geographic to the financial. Pundits, pollsters and prophets may disagree on many things, but for now, most agree that the global financial outlook for 2009 isn’t good. Recent publications targeting everyone from requirements analysts to CIOs have espoused the importance of good software development practices in the face of bad financial times. While those articles may speak the truth (and I believe that they do), unfortunately some of us will face cutbacks in resources in the coming year.

Also unfortunately, requirements management is one of the software development areas that often gets put on the chopping block during resource cuts (along with other important areas like usability, user documentation, testing, architecture and even coding itself). As software requirements practitioners, it behooves us (yes, I said "behooves") to be prepared for any reduction in requirements management resources, whatever the reason. Given the current financial environment, though, the need to be prepared may take on additional importance today. Hopefully the following five simple suggestions will help you be prepared in case you’re faced with this challenge in the coming year.

1. Establish and use a requirements management framework
Many times, requirements management teams sprout out of necessity. The ways in which requirements are elicited, documented and managed may be ad hoc, or even haphazard. When there are enough people to manage that sort of process and catch things before they fall through the cracks, such an ad hoc approach may suffice. When resources are limited, though, expending energy to reinvent the process wheel on each project is no longer an option. By establishing a requirements management framework complete with standard methodologies, processes and templates, you will take the guesswork out of your requirements work. A standard framework also helps you evaluate each project’s needs objectively, making those inevitable conversations about what can and can’t be done within a limited timeframe and with limited budget a bit easier.

2. Use tools effectively
One common piece of a requirements management framework is a suite of tools. Requirements tool categories range from document management to team collaboration to requirements documentation and traceability. While each type of tool certainly has a place in requirements management, they are often viewed as quick-fix solutions. An attempt to put a toolset on top of a broken process, or to simply replace requirements analysts with a requirements management tool, is likely to fail. Instead, recognize the specific tasks for which tools are good and use them for those. Version control, traceability management, spell-checking, and document generation are easy tasks for a computer. Talking with users, pulling together different pieces of information into a sensible whole, and drawing conclusions are better done by people. Remember that tools alone can’t fix a broken requirements process -- tools are aids for, not a replacement of, skilled analysts.

3. Use metrics to reinforce the value of requirements management
Unfortunately, just saying that you have a framework in place and that you’re using tools effectively might not be enough evidence of the value of requirements management. If you’re not already doing so, begin capturing metrics in order to reinforce the value your work provides -- you can start small and expand the scope of your metrics in order to fit your particular organizational situation. Some sample requirements metrics include rate of requirements change, percent of requirements implemented, and average time spent to document a requirement. While these metrics may be interesting for a single project, they begin to provide real value when they are compared over time, indicating how the framework is improving requirements practice. In addition to capturing requirement-specific metrics, it is extremely valuable to capture project-level metrics, including user adoption, user satisfaction, usability, achievement of project objectives, and return on investment. When you can show how your requirements work positively impacts the company’s bottom line, you take requirements management off the table during discussions of resource cuts.

4. Employ a satisficing approach, focused on what’s important right now
Generally speaking, satisficing is an approach which focuses on adequacy over perfection -- you’re done when you have a "good enough" answer, rather than "the ultimate" answer. For example, I recently sent an SRS document out for review even though it wasn’t complete. The information I did have was good enough for comment by my reviewers, and the feedback I received from the team helped me know what other information was required in order to move us to the next step in the development process. Another example of satisficing in requirements management would be documenting the high-priority use cases in formal detail, while simply capturing a skeleton of the lower-priority ones. Satisficing allows you to continue to make progress on the overall project even when you don’t have all of the information that will be required eventually. It also shows the rest of the team that you’re interested in working together on the highest priority issues, rather than sacrificing "the good" in an effort to reach 'the great." Chances are, "the good" is indeed good enough.

5. Strengthen interpersonal relationships, both horizontally and vertically
When there are fewer people around to do the work, you may have to rely more heavily on others to help you succeed. It’s easy to see how important your relationships with other requirements practitioners are, but your other relationships within the organization are also more important than ever. Being able to turn to your documentation specialist for a review of your SRS, or getting an early heads-up from the development team about the feasibility of implementing a requirement, or simply knowing that your team is functioning as a team rather than a group of silos, can be invaluable during lean projects. In addition to shoring up relationships with your peers, this is a great time to establish or strengthen ties up the org chart. Many people aren’t as comfortable speaking with managers, directors, and VPs, but having their support for you and your work can help prioritize requirements management among their peers, and any support we can get from management is great!

Interesting times often call for simple, direct solutions. If your requirements management group isn’t impacted today, hopefully these suggestions will provide you with ideas for ways to make sure that you won’t be tomorrow. If you do face challenges as a result of the current financial environment, these suggestions should help you do more with less.

Labels:

Requirements Defined Newsletter Bookmark and Share

Wednesday, December 10, 2008

Ask Joy: Managing Culture Differences on Global Teams

Question: Julia from New York asks, "How do you handle cultural differences across global teams?"

Answer: Thanks for the question, Julia. Various regions may have different culturally accepted behaviors, but remember that this does not mean that their requirements are less important. Hear them out. Figure out how they communicate and work with them in the way that works best for them.

Use the culture training you all go to to understand what to look for. For example, be careful of getting a yes or a no answer, because people may just give up or some cultures are more discreet they won’t be direct.

Use the global business objective to align the team. You might find that the business users from different regions have different priorities. Set a global objective together, and use it when there are conflicts.

Also, avoid an “us” vs. “them” feeling. Include everyone in every discussion. Don’t talk in the halls, stop and get them on the phone.

At times, it may feel like you are going through motions, but think about other people, it does matter to them and they will notice you are doing it.

Labels:

Requirements Defined Newsletter Bookmark and Share

Tuesday, December 02, 2008

Four Ways To Get The Most Out Of Borland CaliberRM

We have been using Borland's CaliberRM for awhile now. Overall I really like the tool, but as I mentioned in another blog post there are definitely some issues. We tend to not let the user population and management have direct access which means that we have to be able to generate output in a variety of forms.

In this post I want to provide a few tips that have helped us to generate output in some pretty flexible ways.

1) Getting Appropriately Styled Headers In A Word Doc

Document Factory is the tool which uses a very simple set of commands in a word doc to iterate through your requirements and output them into Microsoft Word. Over time you will grow to love or hate document factory, but the reality is that while it may be difficult to bend to your will, it will generally let you produce the kind of documents that you want to produce.

One of the biggest issues that we have had is how to get doc factory to work with autonumbering. When we modified our existing requirements document templates to work with Document Factory and output the hierarchical numbers from CaliberRM, all of our items were numbered twice.

Plus it was impossible to get CaliberRM to use multiple header level styles. We ended up finding a macro on the Web that solves this problem. First you use a document factory template that labels the headers with special characters. Then you run the macro which parses the "." in the hierarchical number and applies whatever style you want. This is actually a very quick process and allows you to use whatever styles/formatting you want to format your requirements document

2) Getting The Images To Actually Be In Your Document Rather Than Be Referenced By Your Document

When we first started using document factory we discovered that images were not by default stored in the document produced by CaliberRM. What would happen is that we would send the document to someone and all the images would be broken.

It turns out that document factory uses a command called MERGEFORMAT /d which only uses links to images not the images themselves. Joe wrote a messageboard post on the subject here.

The short of it is that you need to reveal codes with Alt-F9. Then do a global search and replace "MERGEFORMAT/d" for "MERGEFORMAT". Hit Alt-F9 again to hide codes and then Ctrl-a to select the whole document. Then hit F9 to update all field codes. Save the document. The way we are sure that it has been updated is that the size of the document should be substantially larger.

3) Outputting A Subset Of The Requirements

If you select a requirement in the tree, then run document factory, document factory will give you the option to only generate requirements for the selected requirement and all its children. This is quite handy and we use it all the time.

More commonly though we use the requirements grid to filter a subset of requirements in the way we want and run document factory on those requirements.

4) Getting Tables Into Your Output

It turns out this is somewhat obscure. In document factory instead of using the BEGIN_SECTION and END_SECTION, you use BEGIN_ROW and END_ROW. Here is an example from a template that we actually use:





































































SprintHierarchyIDVersNamePriorityStatusEffort
$BEGIN_ROW


$SORT{hierarchy}


<<Release>>

<<hierarchy>><<id_number>><<version>><<name>><<User Group Rating>><<status>><<Expected Effort>>


$END_ROW





You can either copy the table into a .dot Word template, or you can download a sample word template. Once you generate the Word doc with document factory, you can just open, select all, copy and paste it into Excel. The table will be maintained.

These are the most common ways of outputting in Borland CaliberRM. There are more advanced techniques as well that involve using the CaliberRM API. But we have found that these steps are good for most cases.

What tips and tricks have you found with Borland CaliberRM? Post your ideas below or put them on the messageboard at www.seilevel.com/messageboard.




Labels: , , , ,

Requirements Defined Newsletter Bookmark and Share