Can't we all just get along?

I got a notice today regarding the next meeting of the Austin PMM chapter where the topic will be Agile Software Development Techniques and Their Impact on Product Management. A discussion around the role of a PdM in an Agile environment is one that has been kicking around our office for a while now and it has certainly been a topic that I have wanted to explore on the blog. As I started to look through some of the source material I have been saving on this subject I found myself diverted on a trip down memory lane - a detour that struck me as worth sharing.

I started my career a while back working for a CASE tool pioneer. I remember hearing during the IPO hype how our pretty little graphical tools were going to put developers out of work by making it easy for business analysts to drag and drop their way to system creation.

END RESULT - developers still in business while that CASE tool vendor...not so much

A few years later I jumped to a software test tool company. A raison d'etre that was forced upon us was to help put software testers out on the streets by simply recording the actions of users for later playback in the form of automated "tests." We didn't really believe it in the least, and almost always revealed this explicitly to our sales prospects, but the economic buyers we dealt with sure wanted to think it could somehow be true.

END RESULT - testers still collecting paychecks but that company no longer writing them

Today, I feel like I am now finally facing the pointy end of the spear. In my current role I am a Product Manager who focuses on software requirements. Aligned against me and my job are hordes of Agile advocates and the belief that some of them hold with regards to my niche in the IT ecosphere. "Hell yeah" opined one XP devotee when posed the question as to whether the PdM/BA job is soon to be extinct in an Agile world.

END RESULT - to be determined...but you can guess where I'm placing my bets

Why does the software industry seem to focus on the notion that progress can only come at the expense of discarded roles? It's as if we've collectively decided that the only way to appease the software beast is to regularly offer up a sampling of our colleagues like so many Ann Darrows to the giant ape. Agile is the ultimate solution in the eyes of some adherents because it manages to kill two annoying birds (testers and Product Managers) with an elegantly simple, single stone.

I am not advocating that we should adopt some form of "perfect" team structure and then never change the way we work again. Our industry's track record reveals that we have far more improvement ahead of us than behind and part of getting there must include experimentation around the various roles involved with the effort. That being said, I will state unequivocally my belief that success can only be achieved when all of the groups currently involved in building a software system begin to optimize the value they each bring to the table. Just like the Empire State Building required a host of trades in order for it to reach the sky, the electronic steel at the heart of our information systems will only rise straight and true through the efforts of all the craftspeople involved.

A future post, most likely after the PMM forum, will look at the role of requirements and the PdM in an Agile environment. My initial reading of some excellent sources suggests that the "Hell yeah" zealot I mentioned earlier is most likely outside the Agile mainstream, but I've seen enough advocacy around removing the PdM role altogether that I felt compelled to preempt my publishing calendar with this quick rant.

Requirements Model 1 - The State Table

As Anthony C. said in an earlier blog post, requirements models are a great way to discover missing requirements in your software system. Without a good model, you have no way to be sure that you captured every requirement and seeing the missing requirements becomes nigh impossible. One of my personal favorite requirements models is the state table.

One of the reasons I like state tables so much is that they are very easy to create. The first step in the creation of a state table is the identification of a business object that you want to analyze. For example, in a loan approval system you might want to examine the loan application.

After you select a business object, you identify all of the states that your object can have. In our example, a loan application may be blank, ready for submission, submitted, approved, or rejected.

To construct the actual state table, you list all of the states along the X and Y axes of a table (letters A-E in the diagram above). The Y axis represents the initial state (e.g., submitted) and the X axis represents the final state (e.g., approved).

Now the fun begins. Every intersection of two different states represents a transition. These transitions, numbered 1-20 in the diagram above, tell you how your business object (the loan application) moves from the initial state (submitted) to the final state (approved). In our example, the transition between submitted and approved might lead to a whole set of requirements around the approval process, what must be present for an approval, and who gets to approve loan applications.

Why use a state table? Besides being incredibly fun to produce (okay, that may just be me :-)), they allow you to put a structure around your requirements that lets you discover holes. If there is no requirement related to one of the transitions in the table, there will be no way to transition from one state to the other in the final system.

In our example, imagine there were no requirements around the transition from rejected to approved. This may be an intentional aspect of the design, but chances are that this is not the case. If this were so, loan applications would get rejected and never be able to move out of that state by any means. The state table lets you quickly find these 'dead-end' scenarios and discuss them with the SMEs.

I love these so much because I used them very successfully on a project I worked on earlier this year. We were commissioned to create a financial system that managed millions of transactions a month. The system revolved around these transactions and their flow through the system. The SMEs had a very clear understanding of the different transaction states that they wanted to see but they didn't know all of the possible transitions. We constructed a state table and systematically moved through each possible transition to discover almost all of the requirements of the system.

These models may not work well when your SMEs don't already have states in mind. It can be difficult to impose that kind of structure on a problem where it doesn't already exist.

State tables have made complex system analysis problems much simpler and easier to digest for me and I hope that you will find some use for them on one of your projects.

Shall we require - part 2

I was reading through some of our older blog postings and saw the Shall we require post. Joy had asked the question of why use shall and there is a comment by Melissa about the confusion of using will and must. One point of view on this was presented at the Compliance Automation Training that I attended last week. According to Compliance Automation:

Shall unambigiously states that the system is required to implement the functionality.

Will is a statement of fact.

Should is a goal

Must is unambiguous, but shall has stood up in court as being a legally valid requirement, therefore it is better to use shall.

In her book Customer Centered Products Ivy Hooks writes about the following exchange that occurred on an internet forum.

A lively Internet discussion took place on the Software Engineering reflector about the use of the terms "shall", "will", and "should" in requirements.

One contributor said. "We don't need to do that anymore because that was U.S. Department of Defense terminology and they threw out those standards."

The response from an Australian contributor was, "Your DoD may have thrown out those standards, but here is a list of international standards that mandate the use of those terms."

A computer science professor at a not-to-be-mentioned university wrote, "This is too difficult. What we need is a simple symbol or icon for requirements."

The prompt response was, "We have a simple symbol for requirements. It is the word shall."

This little bit of ancient history at least gives a clue to the origins of shall.

Finding missing requirements

I went to a two day requirements training course the last week which did a great job of covering the basics of requirements. The course was taught by Cheryl Hill at Compliance Automation http://www.complianceautomation.com. I thought the content was great, but that there was a hole in their methodology for finding missing requirements. They felt that using a traceability matrix was the main way to find missing requirements. In my experience, the traceability matrix is a good way to ensure that you have at least some low level requirements mapped to high level requirements. However to truly find missing requirements you really need something more.

Imagine that you have a jumble of letters in front of you and you have to find out which letters of the alphabet are missing. If you just stare at the jumble or even line them up in a row, it is going to be incredibly difficult to find the missing letters. However, if you order the letters alphabetically, all of a sudden the missing letters jump right out.

The key to finding missing requirements is to take advantage of the fact that each requirement is related to other requirements in some way. It is virtually impossible to find missing requirements given a list of shall statements, but if you add some structure to the requirements that take advantage of their relationship, it becomes a lot easier.

Some examples of models that help to create structure around the requirements are use cases, decision trees, decision tables, data flow diagrams, click-action-response tables, flow charts and many more. Most people writing requirements have never heard of many of these!

One key concept to keep in mind that using these models doesn't absolve you of the need to write shall statements, they are simply used to provide context to create order around the requirements. We have seen many organizations try to use use cases as the requirements rather than as a model with which to find missing requirements.

Keep dropping by as we discuss these models in depth.