'Twas the night before launch day

'Twas the night before launch and all through that day
Not a creature had stirred not even QA

The requirements had been collected from the users with care
In the hopes that on launch day no bugs would be there

The project team was all nestled, snug in their beds
While visions of smiling users danced through their heads

When from my computer there rose such a clatter,
I checked my email to see what was the matter

And what to my wondering eyes should appear,
But another stakeholder with a last minute fear

More rapid than eagles, the emails they came,
And he added his feature requests like it was a game

I want dropdowns and buttons and menus and blogs
And Tabs, and tool tips and more dialogs

My eyes glazed over as I looked at the screen,
And my fingers danced on the keyboard, nimble and lean

A check of the requirements, a glance at the scope
Soon gave me to know I had plenty of hope

I spoke not a word, but replied straight away,
Cutting and pasting the specs, furiously that day

And laying my finger on the ENTER key,
I answered his questions so perfectly

We have the dropdowns, the buttons, the menus and blogs,
the tabs, the tool tips and every dialog.

We met with the users and left nothing unnamed
We designed, we developed, we tested and trained

He replied to the team, his fears were allayed
He was now confident in the software we'd made

And as I read his email, in which he felt so contrite
He IM'd me to say:

Happy Launch day to all and to all a good night.

A Christmas Medley

With the holidays upon us, I wanted to spread some holiday cheer. I hope I can make you smile, with my medley of requirement "blongs", to the tune of some of our favorite holiday songs!

Frosty the PM
Frosty the PM led a jolly happy team
With a strong dev lead and a key tester
and BAs charging on full steam
On time releases, are a fairy tale they say
They are made of scope, but the team must
know to control it every day
There must have been some magic in that
entire team he found
For when they launched it just in time
they began to dance around

The 12 days of Planning
In the 12th day of planning, my PDM gave to me….
Twelve coders coding
Eleven priorities changing
Ten directors weeping
Nine SMES designing
Eight users lurking
Seven swim lane drawings
Six schedule slips
Five gold plated features
Four written use cases
Three global actors
Two change requests
and an extra feature for free

It’s beginning to look a lot like a product
It's beginning to look a lot like a product
Everywhere you click
Take a look in the requirements spec, or maybe the powerpoint deck
I think scope is finally going to stick
It's beginning to look a lot like a product
New features finally ceased
But the snazziest sight to see is the feature that will be
When your product’s released

Away in a cube farm
Away in a cube farm, nobody has slept,
The tireless code warrior tried to fix his defect.
The stars in the bright sky looked down where he test,
The diligent test warrior asleep on his desk.

Joy to the Team
Joy to the team, the release has come!
Let users receive the installs.
Let every coder, leave their cube.
Launch features with fancy bling,
Launch features with fancy bling,
Launch features, and features, with fancy bling.

If you enjoyed these, find additional songs on the message board!

Requirements Review: Team Effort - Early and Often

How often should I be reviewing my requirements with members of my project team? By requirements I mean everything from high-level business needs (e.g. stakeholder requests, business requirements, vision and problem statements) to the most granular requirements (aka shall statements, functional and supplementary requirements and the like).

My answer (with only the slightest bit of hyperbole) is “all the time.”

When it is first articulated and then documented, a requirement just sits there on the page. Words. Words with multiple meanings and interpretations and implications. Ask a developer and you get an interpretation, ask a tester and they will have a different interpretation. Business resource, different interpretation. If these different (and usually conflicting) interpretations are allowed to stand through the project, there is high potential that someone will be disappointed when the project is completed.

So the team has to commit the time to discuss the meaning and implication of each requirement that is presented as a candidate for the system.

Does a tester have to review a stakeholder request like “Business wants to provide upsell and cross-sell opportunities based on items browsed/purchased on the website.” Probably not, but the business does. They need to validate the functional features that will execute this requirement.

One of those features might be “Should provide a 'Check Me Out' list on the website."

Does the business agree that this feature (along with others, potentially) effectively satisfies the stated stakeholder request? Do the architect and development resources believe that this feature is implementable and supportable given the current technology framework? Implied in the second question is the fact that I have chosen to get the development team involved at this point of feature identification. If I have identified a feature that I think is going to meet a stakeholder request and it is not technically feasible, I want to get that feedback to the business as soon as possible so they have the chance to provide an alternate feature to meet their stakeholder request.

Let’s say that my identified feature is technically feasible. I am going to have to provide more granular requirements for that feature that will specify additional detail and rules for the feature. One of those functional requirements might be 'System shall display products we recommend based on previous purchases or previously browsed or items.'. This then becomes a requirement that the development team and test team will want to review to consider how they will implement it and how it will be tested. I will also need to further bounce this requirement off the business to verify that this specific requirement fits with their vision of the final solution.

At all stages in the process, there should be time devoted to validating the requirement with the relevant team members. When a review and approval step is skipped, the requirement and the dependencies for that requirement are placed at risk. The greater the risk that a requirement carries, the more potential it has for being inaccurate from the business perspective and misunderstood from the development and testing perspectives. And a requirement that is either inaccurate or misunderstood or both runs a very high risk for negatively impacting the project and its success.

Where to start with use cases

We frequently find that software development teams defining requirements with use cases face a challenge in finding the right level to target as a starting point for their use cases. There is no widely agreed upon standard and team members often have differing opinions based on their background and experience.

The available tools and templates offer a wide variety of guidance from informal use cases and user stories to extensively detailed templates with sections for alternative and exception flows, «uses» and «extends» relationships, business rules, etc. Unfortunately, little useful guidance is offered to help the team decide where to start. Asking the users “What do you want the system to do?” seems like a particularly ineffective approach.

We know it is not good for use cases to be too big, or to small. The ‘Log on to system’ use case seems to show up in almost every use case diagram with a «uses» arrow from nearly every other use case. But really, what is it good for? And, a 200 page use case covering ‘Purchase Raw Materials’ for example, should probably be broken down into smaller use cases covering less territory. When multiple modelers with different perspectives try to work together the result can be confusion.

So, how do we find the right starting point and level of ‘abstraction’? Process decomposition is a modeling technique for breaking a business process down into progressively lower levels of detail until the ‘appropriate’ level is found. Although decomposition has not gotten a lot of respect in the world of object orientation it can be a very helpful technique if used correctly.

Start with an overall context diagram to encompass the entire business process scope of the project. Identify the high level steps involved in the process. There should generally be three to six of these steps. If you have more than nine or so look for a way to consolidate or group some of them to a higher level. Now, break each of the high level steps down to the next level of detail, again finding three to six sub-steps that make up the higher level step. Continue this process until you find the ‘elementary level’ processes. An elementary level process is one that is performed by a single person, and can be completed from start to finish in one session. (Breaking for lunch doesn’t count.) Stop decomposing at this point. Now you can write elementary or ‘primary’ level use cases where one primary actor performs each use case.

Most often it is best to resist the urge to further decompose the use case model. Use cases are a great requirements communication tool when they are written with that purpose in mind. Object models, collaboration diagrams, and other tools can be much more effective for translating requirements from the ‘language’ of the users to the ‘language’ of the designers. Start and stop your use case modeling at the right level and you’ll be happier and more successful even if you never model another «uses» or «extends».

Too busy to blog

It turns out that apparently a lot of companies have problems with requirements and we are getting hammered with requests for work. Not only do we have a blog backlog but we have a tremendous backlog with our clients.

We are so committed to you the readers, we are having a blog party (at 7 in the morning no less) to get everyone in a room and get at least one blog post out each. So over the next few months you should see a more consistent frequency of posts.

P.S. if you love requirements (I mean really requirements) then drop us a line at careers@seilevel.com because we would love to have you on the team!