The One Thing You Need To Be A Team Player

Mike A’s earlier post on being useful, Thomas the Tank Engine on Software Requirements, brought to mind thoughts I’ve had about what it means to be a team player. What Mike defines as being useful, I consider a top characteristic of a team player—doing what is best for the team to succeed on the project.

Do a search on the topic “Team Player” and you’ll find a lot of articles about the characteristics of a good team player or how to be one. But, you won’t find much about the objectives of a team player. It’s one of the classic requirements problems: lots of strategies and solutions, but no one is stating the goal.

Understanding the goal is important, for example:

• I’ve worked with people who defined the objective as making everyone happy. Unfortunately, “happy” is sometimes a short-term thing. What makes people happy now, may make them very unhappy later, if the happiness comes at the expense of unnecessary work or a less successful project.


• There are also the well-intentioned people who work very hard to do their best, who end up unthinkingly maximizing their own performance at the expense of the team as a whole.

My objective as a team player is to do what I can to maximize the performance of the team to meet the goals of the team. The “Team Player” search results provide a lot of strategies for doing that. I think being useful is one of the best.

Oh, and, as Mike implied, eating your vegetables usually won’t make the top 10; but, that’s no reason not to eat them.

How To Prioritize Your Software Requirements, Part 1

One would think that since requirements are the necessary and sufficient list of behaviors needed to meet the business goals, prioritization is a non-issue. Everything is necessary, so why prioritize? Prioritization becomes an issue in the following ways:

• The initial vision is too costly or time-consuming to implement, we must scale back.


• The development effort will be done iteratively, and we must prioritize for the iterations (roadmap).


• Unfortunately, prioritization is also occasionally a proxy for controlling scope; the initial list of requirements represents more than the necessary features, so must be prioritized.

When you do need to prioritize requirements, don’t bother trying to put them in order. In the end, it doesn’t matter if one requirement should be ranked a little higher or lower than another requirement. You just want to figure out what to build. If you absolutely need 5 requirements fulfilled, ordering them 1-5 really doesn’t have any benefit. Determining that the 5 are absolutely necessary does.

You should use priority categories instead of an ordered list. The classic “high, medium, low” is easy, but doesn’t really map well to the real world. “Medium” is often just code for “not in this release, but not a bad idea”.

More realistically, you can use MoSCoW ratings (must, should, could and won't have). You may need to further prioritize the “should” or "could" requirements as “high, medium, low” so the team knows what to work on first when the “musts” and "shoulds" are done (wishful thinking!). Remember - these categorizations must be based on the business objectives.

So, what do you do when there is disagreement about the prioritization? I’ll cover that in Part II.

How to Prepare for Software Requirements Sessions with Your Users - Tip 4

Our final suggestion on this topic is to Sit With Your Users.

If your users are extremely busy, and the project involves changes to or replacement of an existing solution, then turn the challenge into an advantage. Sit beside the users while they perform their job tasks.

Typically this is a good way to elicit requirements because users cannot always articulate their needs if they are used to completing tasks without thinking about them. This technique will require follow-up meetings with the users after, but then those meetings can be prepared for as above, with intelligent questions based on the observations, thereby shortening the time that users are away from their work.

Let's recap, we've now offered the following suggestions to prepare for requirements sessions with users:

1. Organize Your Time
2. Prepare Your Requirements Models In Advance
3. Prepare Your Elicitation Questions in Advance
4. Sit With Your Users

There are many ways in which requirements analysts can intelligently prepare for requirements sessions with users. Typically a mix of the above suggestions will work well on any project. These tips will help the analyst and users get the most value out of the available time.

By the way, you can download all of these tips in a whitepaper that I've written. Enjoy!

INCOSE 2008 - Technical Team Accountability for Requirements and Delivery

James Andary, Maria So & Barry Breindel from the NASA Goddard space center presented “Systems Engineering Technical Authority: A Path to Mission Success”. The goal behind this program they call “Technical Authority” (TA) is to give a voice to the engineers on projects. Under the previous model, project managers were the central path to communicate with upper management. Looking at a history of success, this old approach worked well on their robotic missions, but not for human space flight missions. As an example from the Challenger report, there were specific technical warnings from people that were ignored, never making it up the chain to the people who had the authority to delay a launch to investigate them.

Under a TA model, the lead systems engineer on a project still has a dotted line reporting to project managers, but ultimately they report up to the engineering director, up to the center director and finally the NASA chief engineer. This means that an engineer can take an issue to the top of the chain if they believe it’s not being addressed properly. Part of the reason for using this model is that, there is a natural conflict between engineering (who wants to build a perfect system) and program management (who wants to launch on time), and this model is supposed to help eliminate issues from this conflict. They gave an example of a battery engineer who was about to quickly escalate an issue – there had been a series of launch delays which meant some specific batteries on the flight had expired. He brought the issue to the attention at a director level and they employed the appropriate people to quickly research it to determine if it should delay the launch again.

A result of this organizational model is that the engineer now has accountability for the product – and while generally a positive thing, this will probably be hard for some people to accept. The engineer now also has responsibility for understanding and implementing both enterprise requirements and project specific requirements. I admit that when I first heard this, I thought “You mean they were not accountable before if the space mission failed for a technical reason?” I think the point is not that they were negligent, so much as they were not being heard – more of a communication failure.

With this model, there no longer should be finger pointing “the project manager didn’t listen to me” and instead a focus on everyone doing their part to have a successful launch.

One final point made - when dealing with large systems project, it is important that someone on the project has a holistic view of the project. This team is working with MIT to study how you infuse that in people. They are trying to do a few things to improve this, such as exposing engineers to more of the overall mission activities, holding focus groups to share experiences, and requiring engineers to participate on peer review panels. I think there are some great take-aways from this that we can apply to all organizations, encouraging cross-project awareness.

INCOSE 2008 - Imagine the Complex Systems for Hydrogen-Based Transportation

Tuesday's favorite talk for me was "A System-of-Systems Framework for the Future Hydrogen-Based Transportation Economy" by Michael Duffy & Debra Sandor of the National Renewable Energy Laboratory. This was an interesting talk, less because of any discussion of requirements and more because it represents a complex systems engineering challenge. Also, I just wanted to share some of the topics that are prevalent at this conference outside discussions about requirements specifically.

In 2003, Bush allocated $1.2M towards developing clean hydrogen-powered automobiles. The administration has actually followed through and by the end of the year, will have spent just about $1.2M. The work at the National Renewable Energy Lab is using this funding to research and develop technologies to support the aim, including determining how they might guide the transformation of energy sources in application.

So “conveniently”, the generalized hydrogen supply chain looks a lot like the supply chain of petroleum. First, there is what they call feedstock (natural gas, biomasss, coal, or water) which logistically must be delivered (by pipes, trucks, rails, barges) to hydrogen conversion plants (this part varies by feedstock), and then from there, the hydrogen must be distributed (by trucks, etc. to fuel stations).

However, over the next 30 years, there is an expectation that as a society will move through internal combustion engine improvements, cleaner renewable fuels, then to hybrid electric and eventually to hydrogen fuel cells. The big systems engineering challenge is in the transformation from petroleum to biofuel to hydrogen systems. There is no single solution for the future, the mix of technologies will change over time, and there will never be a "flip the switch" moment in transition. Add to this a challenge that corporations will not build hydrogen cars if there aren’t convenient fueling stations for drivers to refill. But they won’t build the stations if there aren’t cars to use them.

Ultimately, the described projects at the laboratory to solve these challenges are a long way from complete – they are currently focused on system definition, and nowhere near design and development. Though, I suppose at this early stage, they are spending more time now on requirements than anything else! Dr. Duffy's presented timeline looks like 2015-2020 for the government to be using hydrogen fleets, around 2020-2030 we will have personal vehicles powered by hydrogen, and by 2040 everyone would have one.

(*All data here is sourced from the talk at INCOSE 2008, and the actual paper should be review for references).

INCOSE 2008 – How to Deal with Vague Software Requirements

Mary Bone presented a paper “Cyclone Process: Dealing with Vague Requirements” at INCOSE 2008 in the technical track. I’m going to try to summarize her work here.

Her premise is that existing requirements models do not deal with vague requirements, but rather they specifically aim to remove any vagueness from requirements. However, she contends that sometimes you will have vague requirements, and therefore need a way to deal with them.

As an example, she spoke to a requirement that said a system must work in all countries in which a unit is deployed. Well, clearly any good requirements engineering will ask “which countries”? The issue here is that this was a military application, and the list of countries was constantly changing.

A New Model For Software Requirements

Mary proposed the cyclone model which defines requirements to a risk level that is sufficient for the stakeholders. Pictorially, the model resembles the spiral model with a 3rd dimension, risk. The phases look similar as well. There is an elicitation phase in which she encourages all requirements to be captured, with any initial risk information. During analysis, this information is reviewed and a risk assessment is done on the requirements, where a risk factor and rationale for the risk is assigned. Vague requirements are just given a higher risk factor. In particular, the higher risk requirements are re-reviewed, and during a negotiation and commitment phase, stakeholders agree on the requirement, rational, risk, and risk rationale.

I think the key take away here is that you are adding a couple attributes to the requirements to reflect the risk of each one, when the requirements cannot be written clearly. While I’m inclined to avoid excess attributes on all requirements when there is no need for them, perhaps you could just assign a default “normal” risk to all requirements, and when you have a few that are still vague, you assign a high risk to only those. The project can continue forward without requirements being fully defined.

She did not speak to this, but I see this technique being most applicable to projects with strict criteria for requirements sign-off, regulatory projects, etc. In many projects, I think it’s pretty common to move forward with some vague requirements, knowing they’ll be iterated on in a future phase. It’s almost implicit in the iterative methodology.

INCOSE 2008 – Systems Engineering Railroads - So Many Requirements Stakeholders

The opening talk on Monday at INCOSE 2008, “Crossing Borders by Applying Systems Engineering”, was by Bert Klerk, the CEO of ProRail, who runs the railway system of the Netherlands. Behind Japan and Switzerland, this country is 3rd in the list of most densely used railroad networks. They have 6500 km of track and because they are a land of much water, 4500 bridges to cross. This is clearly a large system which has had great success from applying systems engineering principles.

This is not the first time I’ve heard a talk about a project for Europe’s rail systems. I find it to be a very interesting topic, and though I have never worked on a railway project, I can see the challenges so clearly. This talk highlighted an example of a track to be laid that in particular had to cross a small river. They put out bids to contractors to see who could most cleverly navigate this river while staying under budget; and the winner’s solution was implemented. But the point here is systems engineering on this scale involves hundreds of stakeholders. When dealing with these large scale systems – you cannot just think about the users at all, the scope spans way beyond that. It’s not just those people using the tracks, those operating and maintaining them, but also those who are impacted by the train system deployed – the town people who enjoy the river. And while they are not direct users, you cannot ignore them – they might actually put up big roadblocks to deploying the system.

Anyway, if you can imagine how hard it is to get 200 users aligned – now imagine you have 30 types of stakeholders with a couple hundred of each and most of them will never actually use the thing you are building. Try to keep that group satisfied!

Secret Skills and Qualities of a Great Product Manager

I was giving some thought to what it meant to be a good product manager. There are many good posts written about the typical analysis skills found in a product manager, so I wanted to think a little outside the normal box. Here's what I came up with:

• Thinking on their feet – We spend a lot of time in front of busy users, project managers, and developers, who are smart and know their business well. At times, they are intense. They will ask tough questions of us, and probably even more challenging than that, they will state things that we need to be able to understand quickly and ask questions back intelligently. Too many blank stares, uncomfortable silences, and “uh, I don’t know”s will help us lose your credibility fast.


• Thoughtful – We are interviewers often, and so with that we must be willing to listen and think about what they say. This is different than quick thinking, but rather truly deep thinking. It will require some skills of empathy and understanding when the teams are frustrated. It will require just being someone that cares (and not faking it!).


• Likeable – I hate to say it, but we have to be likeable. We work with so many different people through the course of our work, and we really need these people to want to help us get information from them. People enjoy helping people they like, so be likeable.


• Must like people – Again, we work with so many different people who believe in us, trust us with their products. So complimentary to the last point, we must like the people we are working with. We have to want to talk to them, to tell them how it’s going, to ask them questions – simply put, we must be willing to engage in conversations. While being an introvert is very helpful to the analysis work that must sometimes be done quietly alone, being an introvert all the time will not lead to successful product management.


• Passionate –We have to love things! It sounds silly, but passionate people can feel things, both positive and negative about products around them. We can recognize and engage passion in the users we are working with. It shows itself as excitement, which can be addictive in a group.


• Excellent Reviewer – Not only must we elicit and document requirements, we have to self-review and peer-review the work. Being able to find missing items, or inconsistent requirements across volumes of data is not trivial. There are models and tools to help this, but so far, none of them completely take the thinking out of it. I have found that this is one of the most challenging skills to teach someone to do.
  

Your Requirements Best Practices Are Not Your Reality

To begin with an analogy: I have a friend that can be unreliable sometimes and show up late when we have plans to meet. This is especially difficult to manage when we are meeting to see a movie – if she shows up 30 minutes late, then the movie date is off because the show has already started by the time she gets there. She’s a great person to be around, just difficult to manage at times. We agree that we need to meet 15-30 minutes before the show time (best practices), yet something happens and she shows up after the movie starts.

If our plan to see a movie was instead a project for which I was the requirements expert and she was the project lead, then the concept of showing up 15-30 minutes before show time would be a recognized best practice. So what to do when an acknowledged best practice conflicts with what the project lead wants (the right to show up late in the case of the movie example)? The lead wants the benefit of the best practice (seeing the movie), but things happen or constraints are in place that create a situation where this cannot be done.

What I should do (Best Practices) ≠ What I’m going to do (Reality)

The first step I take in these situations is to first fully understand the project lead’s reasons for not being able to apply the best practice. From the movie example: perhaps my friend is taking college classes at night, and they end right before the movie meeting time. In that case, we could just meet for a later movie, or wait until the weekend. Can the lead and I find a “movie time” that works for everyone where we can still apply the best practices?

In the very rare case that the project lead is simply in disagreement with the use of the best practices, then I determine if it is something worth arguing for. How will the project be affected if we do not apply the best practices in question? If the impact is minimal or can be easily negated and/or managed, then it makes sense to apply the practice that the project lead is requesting. If the impact is too great to ignore, then I work to convince the lead to trust me and let me demonstrate the benefits of applying the best practice.

By the end of the project, we are laughing and munching on the last of the popcorn together as we exit the theater.

Is Your Halo Blocking Your (Requirements) Vision?

There is a correlation between projects that meet documented needs (but not the business needs) and the ‘Halo Effect’.

The Halo Effect, as defined by the American Heritage Dictionary, is "an effect whereby the perception of positive qualities in one thing or part gives rise to the perception of similar qualities in related things or in the whole". More practically speaking, it is when someone who is an ‘Expert’ on a subject area is appointed as the project manager because of that expertise. However, being a Subject Matter Expert (SME) does not automatically make someone a Good Project Manager.

One of my first project management experiences came when I had asked our company to address a customer service issue that was affecting the operation of my department. Being the person closest to the problem, I was assigned as the PM and sent on my way.

I started off listing all of the things that I thought were requirements in as much detail as possible. I then had my team look at everything and off we went. The project team worked really hard and we completed my project on time and on budget.

Once completed, the problems started. We were only able to address part of the original issue that we set out to fix. We had fixed my side of the problem. The rest of the issues were still there. I was appointed to the PM position because I was the expert, but that ended up hurting the project. I had failed to get other experts involved because I thought I knew it all.

While I have learned my lesson, I have seen this same scenario play out over and over again. Time after time, subject matter experts are put into PM positions because they know “what’s best”. Many times the projects requirements turn into being all about the SME’s opinions rather than company needs.

The next time you think you have it all figured out, perhaps you should stop and make sure to evaluate whether or not the full realm of expertise had been explored". It just might make a difference.

This is Going to Bite You

Unfortunately, many of us have been in situations where we are asked to produce work that is not up to our quality standards. Typically this is because of deadlines. We know that a lack of quality will cause us problems now (documents that are hard to understand, possibly misinterpreted, and documents that are hard to maintain). We’re also concerned about the foundation we’ve created for the next iteration of the requirements. We know it’s wrong, and may even argue against sacrificing quality with statements like “this is going to bite you in the future”.

Need a more tactful argument? Scott Sehlhorst’s article Code Debt: Neither a Borrower… is a great discussion on the cost of sacrificing quality in a development effort; the lack of quality is a debt you will eventually have to pay back. Although the article focuses on pressure to deliver code without quality, the points apply to requirements as well.

Scott summarizes with a great quote from Mishkin Berteig’s article Technical Debt: "In other words, every time someone asks a team to let quality slide, they are asking the team (and the organization) to take on debt with an unknown interest rate. Which is lunacy."

Give these articles a read; don’t get bitten.

Frequency of Use, It’s Not Just a Use Case Template Item

Unfortunately, most of us know about projects that had low user adoption because users found them:

• Too slow.


• Too hard to learn how to use.


• Too inefficient to use.

How does this happen? Performance and usability requirements are missing or unfulfilled. Frequency of Use is part of the use case meta-data. A use case's frequency of use combined with number of users helps us determine the importance and benefit of writing performance, ease of learning, and ease of use requirements for it. (I’m assuming you have limited time and must prioritize which requirements you write).

Consider the following graph:

When you have a use case that falls in the upper right quadrant of the graph (B), high number of users-high frequency of use, the reward for optimizing usability and performance is high; it is compelling to write usability and performance requirements. For example, consider a use case that 10,000 people use 50 times a day. A 1 second difference in the performance has a potential impact of 17 hours per day. Further, if it is not obvious how to use the system, this will lead to training and/or frustration for 10,000 people.

When you’re in the lower left quadrant (C), low number of users-low frequency of use, the risk you incur by allowing developers to deliver suboptimal solutions is low. A feature used once a month by 5 people which performs 5 minutes slower than perhaps you had hoped has a potential cost of only 25 minutes per month.

As far as the other two quadrants, they are also strong contenders for usability and performance requirements. However, what you need from the development staff may differ by quadrant.

In the low number of users-high frequency of use quadrant (D), optimizing performance and ease of use may be compelling, but ease of learning how to use the feature may not have much benefit (e.g., training costs for a low number of users are low).

On the other hand, if you have a high number of users who perform a task infrequently (A), making it very easy to (re)learn may have a high reward, whereas sub-optimal performance and/or ease of use have a low user impact; users just don’t use it often enough to care if it is a little bit slow or takes a few extra clicks.

As you can see, the data helps you make the right decisions; frequency of use is not just a use case template item.

The Business Use Case

Use cases are an indispensible tool for capturing the behavioral requirements of a software product and many analysts employ them exclusively for that purpose. But use cases can also help describe the interaction between external entities and a business. And, there are some very good reasons to develop the business use cases that describe the business to be supported by your product.

The actors for business use cases are the suppliers and customers of the business. Money flows from the customers to the business and from the business to the suppliers. Customers exchange money for the ‘result of value’ that is the outcome of a business use case. For suppliers the result of value is the money they receive for delivering materials or services to the business.

One way to identify business use cases is to look for ‘business events’. The business reacts to things that happen in its external environment. One of the most obvious and important events is when a customer signals an intention to buy. Other events include: a customer submitting a payment or a supplier delivering a shipment. The business use case describes the step by step interaction between the actor and the business in much the same way a ‘product’ use case describes the interaction between an actor and the software product.

The real value of a business use case is that it allows (or forces) you to step back from your focus on the product and ask questions about what is happening from a business perspective when an event takes place. Software development projects are commonly initiated after a decision has been made to implement a software product. That makes sense. But, it can be a mistake to just accept a list of desired features or other artifacts as given. If you limit your focus to identifying the requirements of the product you eliminate the possibility of finding innovative ways to change the business.

Your project may be strictly defined by a project charter that does not allow for much business process innovation but if possible, spend some time upfront writing business use cases for the business process area your product will support. Think about the real problem to be solved or the opportunity to be captured. Document the business event that triggers each use case and the goal of the actor. Look for innovative ways for technology to deliver the desired result of value. Then, derive the product use cases and requirements from the business use cases.

Here’s an example of how this can work: One of the features desired for an accounts payable system was the ability to automatically match purchase orders with invoices before making payments to suppliers. Rather than write a product use case for invoice matching, the product team explored the business events and the goals of the actors. They were able to show that the supplier’s goal of getting paid and the business’s goal of paying only for what was ordered and received could be met by issuing payments to suppliers based on matching what was received with what was ordered. The business was able to negotiate cost savings with suppliers and no longer need to process invoices.

Indeed, Why Bother?

In his post Why Bother?, Mike A. used an interesting example. He questioned whether or not it was worth the effort to make a bed. He concluded it was. I disagree with one of his reasons, “it’s the right thing to do”. Here are two reasons to make the bed:

• To keep the sheets clean, when you are using the bed or bedroom for activities other than sleeping (such as a child playing on the bed).


• Because you find it sufficiently aesthetically pleasing to be worth the effort of making it.

How does this apply to requirements? We must always ask--what is the benefit of performing an action? Why are we doing this? Answers such as “because we always have” or “it’s the right thing” are insufficient. Why have we always done this? Why is it the right thing?

Controlling scope is one of the most valuable functions we provide and we must make sure there is value in everything we do. If we only use the bedroom for sleeping and don't care how it looks, it's not worth the effort to make the bed.

Scalability Requirements

Scalability is the ability of a system to grow in its capacity to meet the rising demand for its services offered. System scalability criteria could include the ability to accommodate increasing number of
· users,
· transactions per millisecond,
· Number of SQL statements that can run and provide results simultaneously.

I know many small and large applications having the scalability issues, mainly due to the lack of good requirements specifications, besides not having a sound architecture necessary for the scalability.

How important are the scalability requirements? Today, where the database sizes are growing left and right, the system performance expectations are growing equally rapidly. Keep in mind, no matter how efficient the hardware and the processers are, sound system architecture which can make optimal use of it is equally important. What I mean, for example is that the database architecture needs to be scalable to serve the anticipated increase in number of similar type of SQL queries submitted by online users, with no noticeable performance decrease and without any errors or holds or locks. On the other hand, it should accommodate the growing number of batch transactions without overstraining the batch processing time.

In a recently deployed software application that I know, a concept of event based triggers was implemented. Each event of change to the case data was recorded as a trigger, to be later consumed by batch processes. After the initial deployment of less than fifty thousand caseload, the application started generating swelling number of triggers day and night. It became a bottleneck and severely affected the performance. Finishing the batch processing cycle in time became a challenge! Within few months of operation, a breakdown occurred in the middle of batch processing. The system couldn’t manage the triggers explosion. Ironically, this system was touted as capable of holding a million of case load in its full capacity.

Incorrectly defined scalability requirements could adversely impact the software usage.

Scalability requirements could be broadly categorized based on the things such as user audiance, database usage, critical performance needs etc. For a highly user centric web application for example, the scalability requirement needs to be in terms of the concurrent number of users the system can support today, as well as in future, without letting the performance degrade. While these are categorized as the user scalability, the database scalability is the ability to respond to the increasing number of queries within the desired time concurrently vis-à-vis the ever growing database’s performance against the multi-transaction batch processing. The system scalability discusses requirements belonging to the server capabilities scalable to support the anticipated future number of open connections, the response time per user request etc.

The advantage of identifying scalability requirements early in the software life cycle is that it allows the architectural framework to become sound enough as the development proceeds. There are measures available to address the scalability, such as:
· efficient hardware resources to counter the user needs,
· database schema definitions, partitioning,
· complexity of the database queries and optimization techniques, etc.
However, it’s a difficult task to establish the benchmarks, and to simulate the test conditions to match them.

Scalability is an act of balance amongst the requirements, the software architecture, performance configurations and the choice of environments.

The BABOK Ate My Laptop

I was doing some research to gather various industry opinions on a topic. So like any good requirements person, I thought I would check the BABOK! I headed out to the IIBA website to open it. I opened it online and remembered it was 329 pages, so I saved it to my hard drive, thinking that would be better for performance. And while it might have been “better”, it was far from usable.

I had to quickly jump into the document to get what I needed and close the PDF so that I could actually do other things on my laptop again. I checked my system resources and it was using 88% of my CPU and about ½ a gig of memory! And what should have taken about 2 minutes, took me 15 minutes.

This is my primary issue with the BABOK - usability. There may be fantastic information in it, but it’s so hard to find it, that I’m completely resistant to do so. The irony is that I think we all know how unusable 300 page requirements documents are. And we know how important it is to understand how your user will use a product in writing the requirements. Are we the shoemaker’s kids here? If you are going to have over 300 pages of “how to” data, surely there is a better representation of that than a flat file. For example, a navigable wiki-site would be more easy to use. It could be more of a tree-like implementation that allows varying views of the data and fast paths to get down into the details.

Now all of that said, I’d hate to just complain and not try to help fix the problem! The BABOK version 2 is coming out end of March for review, and so I hope to be able to provide my input if this has not been improved.

The Actors in your Requirements Model are Not Just Stick Figures

When gathering requirements there is a natural desire on part of both the requirements analyst and the subject matter expert to “just get on with it.” Both sides want to see models, use cases, functional requirements, non-functional requirements and all the myriad other artifacts that are created as a prelude to the actual creation of the software. In the process of doing this one thing that very often gets a short shift is properly identify and defining ALL the actors – the people who will actually be using the software that is being built.

This point hit home last week when I was surfing the web looking to see if I might be able to refinance my current home mortgage at a lower rate. On the one hand, with the current melt down of the housing market, they tell us that the sky is falling on our head. On the other hand, the Federal Reserve seems to be cutting rates every 30 minutes. So, I figured that this might be a good time to see if I could save some money with a better mortgage rate.

The first site I went to was one that advertises heavily on any number of television channels. They had gotten my attention and I figured this was as good a place as any to see if it was possible to shave a few points off my current rate.

To my dismay, I was confronted with a one page form that I was asked to fill out BEFORE I could even get an idea of what current rates might be. I looked around in other parts of the web site to see if the information I was looking for was available. No such luck. After a few minutes of this futility I gave up and moved on to another site that did not make me jump through hoops just to see what rates were.

I was mouthing some choice expletives under my breath about the sheer stupidity of the first site and how many potential customers they were losing this way when I started thinking as to whether this whole fiasco could have been avoided in the first place.

I could not have possibly been the only person who had come by their site looking for some information before delving deeper. And again, my behavior was not particularly unusual or radical as to be a corner condition. Many, if not most, potential customers were likely to first check out the rates before they spent fifteen minutes or more filling out an online form. So, how could a company that spends hundreds of thousands of dollars on advertising get something so basic as who is using their web site so wrong?

One possible answer might be that they did not spend enough time fleshing out their “actors.” In the above situation if you describe your “actors” as people who are applying for loan, then the rest of the site makes sense.

On the other hand, they are missing a whole lot of potential customers like me. People, who, while they might be in the market for a loan are not yet ready to apply for one. These are people who want to see what you have to offer before they start giving you a whole lot of personal information.

If this is indeed the case, a little bit of time spent up front in properly fleshing out their actors would have resulted in a radically different user experience and web site. If this is not the case and they are really looking only for people who want to apply for a loan, then their site should reflect clearly the kind of “actors” they are looking for. So, you either have missing requirements or actors who were not properly fleshed out. Not good whichever way you look at it. The sad part is that this is eminently avoidable with basic requirements methodology and techniques.

The next time you are starting off a project, spend some extra time up front properly identifying your actors. A few simple tips / questions you can use when identifying your actors.

1. Who else will use this software?
2. In what way are they different from the actors we have already identified?
3. Are there any other subject matter experts I need to be talking to who could identify other potential users of the software? In the above example, if you just spoke to the people who approved loans, you are likely to have just one actor identified – “borrowers.” However, spreading the net out wider to the Marketing or Sales Department could have netted you “browsers”. “agents”, “dealers”, etc. that someone in loan approvals did not even consider.
4. Try to be as precise as possible in describing your actors. For example, do not just identify your buyers as “customers.” Something more descriptive like “browsers”, “agents”, “bargain hunters”, “dealers”, etc. is a lot more useful.

Obvious? Yes. Common sense? Yes. Rocket science? No. Done always? Unfortunately no.

Resist the temptation to just get on with it and pay attention to your actors. Actors are real people not much different from you or me in many ways. So, if you are part of a project building software that is likely to get under your skin or drive you up the wall, chances are that you are not alone. Stop them.

You are not a stick figure. Nor are the actors in your requirements models.

Why Bother?

Why even bother? When's the last time you asked yourself that? Was it something trivial -- "Oh, I forgot to get canned lentils on aisle 6, but I'll be back in the store tomorrow, so why bother to go back and get them now?" Or was it something more meaningful, like, "Nobody ever reviews my process flow diagrams for this project, so why bother to spend any real effort on them?" Hopefully the majority of your "why bothers" are trivial, but I'd expect there's a more serious one every now and then.

My personal favorite "why bother" is around making the bed. I've had this argument with every person I've lived with for decades now, from my mom and dad, to my college roommate, to my wife. For the longest time, I simply couldn't see the point to making the bed! I go to sleep at night, get up in the morning, and then will go to sleep at night again ... so why do I need to make the sheets neat and tidy for a few hours in between? Their answers, invariably, were "because it's the right thing to do," and I simply didn't buy it. It wasn't until I saw a more personally meaningful benefit that I believed in the importance of making the bed.

So what does my opinion on making the bed have to do with requirements? Well, probably not much ... but hopefully it'll provide a good parallel with a common frustration on requirements projects. It's easy to get caught up in the day-to-day challenges (aka frustrations) of software development efforts, and when you're caught that way, it's easy to have those challenges carry over into your perspective on your own work. At home, you may feel like you're already doing too much housework and making the bed is just one more chore you're too tired to do. At work, you may feel like your deliverables don't matter, or like there's nothing you can do to have a positive impact on the project, or like ... well ... why bother?

If you've been involved with requirements engineering for a while now, this may sound like an all-too-familiar scenario. I know that I've found myself feeling this way more often than I'd like over the years. What I've discovered, though, is that these "why bother" moments are opportunities for me to learn and, more importantly, make a positive impact on my project.

Chances are that if you're feeling frustrated, others on the project are too. If you can recognize the challenge, you can use your requirements role to help shake the entire project out of its slump. Play games in your next requirements workshop. Bring cookies to a document review "just because you think everybody deserves a cookie." Open a meeting by saying that you don't see any reason to keep creating requirements and see what the reaction is (OK, maybe this one isn't the BEST idea!). By shaking yourself out of the "why bother" mindset, you make a difference to the other people on your project, and hopefully you can also see how your work makes a difference to those people and the overall project itself.

One simple change of perspective can impact countless numbers of people - and that's why we bother.

(Editorial Note: I now DO make the bed, and I do it because it's important to my wife, it's what I want my son to learn to do, AND it's the right thing to do!)

The Glossary--Project Litmus

The Project Glossary defines terms/acronyms relevant to the project.

You all probably know that.

What may be news to some of you is that it singlehandedly provides a valuable and telling insight into the overall health of your project.

Here's how.

Our project roles are primarily about communicating and ensuring common understanding of what is communicated. I have not been involved in a single project that did not have its own argot and tangle of acronyms.

When there has been a concerted effort by the entire team to define and understand these terms/acronyms it is an indication that this project team has made an investment in at least one task/artifact that will contribute signifcantly to the goal of clarity of project communication. And I believe the converse is also true, namely, that a project that fails to invest time in defining the terminology that is elemental to the project communication sets a dangerous precedent for sloppiness and imprecision of its communication.

Analyze like a Quantum Physicist

People are often intimidated by the word 'quantum'. It has a whole set of connotations behind it that make people afraid they're going to get in way over their heads. In truth, quantum mechanics isn't all that hard to understand, it just isn't very useful in everyday life. Some of the methods used to analyze quantum mechanical systems, however, have analogues in the world of requirements analysis.

The first thing to understand about quantum mechanics (QM) is that you can't fully understand anything about a quantum mechanical system. One of the postulates of QM is that you can't ever know a particle's total momentum. You can get close, but never pin it down 100%.

The second thing to know about QM is that real systems are incredibly complicated. There is no theoretical reason you can't describe every atom in the universe with an equation, it's just that those equations would be mind-bogglingly complex.

How do scientists get around these problems? They use a model that simplifies things in order to gain a better understanding of the system. They also use different types of models to examine different aspects of a system. Through iterative refinements on these models, they learn gain valuable insights into the system without ever knowing everything about it.

The classic model professors use to describe a quantum mechanical system is known as the 'particle in a box'. By thinking of an electron as a particle in a one-dimensional box, scientists were able to realize that it can only exist in discrete (quantized) energy states. This model is an extreme simplification of the behavior of an electron on an atom, but it still provided early scientists with key insights into the nature of the universe.

How does all of this relate to requirements analysis?

Software systems are nowhere near as complex as quantum mechanical systems, but they can still be quite hard to comprehend. In fact, it may not be possible for one person to fully understand every moving piece of a large enterprise-level system. It can also be hard to nail down everything there is to know about individual pieces of a system.

Models in requirements, as in QM, can help solve these problems. Let's look at the first one - systems can be very complex and hard to comprehend. Use of a model allows you to pare down your analysis to the parts that are important to you right now. You can use a model to focus on user interface, performance, usage, or any number of other system properties. The important thing to remember here is that the model is only showing one aspect of the system. You need several different models to fully understand what is going on. Furthermore, if you make any single model too complex, you lose the benefit of modeling the system in the first place.

Second, models can allow you to analyze every detail of portions of the system. In this case, you aren't interested in abstracting detail but rather exploring all the detail you can get. Models help here as well. Having a framework around requirements allows you to iteratively refine the picture, look for gaps and vague areas, and continually improve your picture. Without the model, you wouldn't know where you needed to improve.

At first, the connection between the world of quantum mechanics and requirements may seem like a bit of a stretch, but the concept of using a model to analyze a system is universally applicable. Next time you start requirements analysis for a complex system, remember that the abstraction, simplification, and structure that models provide can make even the most complex systems easy to understand.

The Secret to Making Sure a Task Won’t Get Completed

You attend a meeting, identify a task that needs to get done, and end the meeting with “We need to accomplish X.” And… nothing gets done. Why?

Identifying a task is the first step. But, assigning ownership of the task is critical to actually seeing it performed. In today’s world of multi-tasking over-allocated people, the old adage “When it’s everybody’s job, it’s nobody’s job” is truer than ever.

Want a task done? Assign it to someone. Simple, I know, but frequently forgotten.

Models. And Cake!

The other day I overheard someone say that all they needed to write code was the list of functional requirements--that they didn't need the accompanying use case (that we were producing as part of our reqs methodology for the project).

Well, here's a list of requirements (ingredients): sugar, flour, salt, butter, cocoa, baking soda, buttermilk, eggs, vanilla, powdered sugar, milk, and pecans.

Go bake me a cake.

Seems pretty obvious that the "order of things" is pretty important in this case. In fact, to not have the order of steps to take (and to follow them) means failure. (Full cake instructions below.)

Here is another set of requirements (muscle groups): triceps, abs, legs, chest, biceps, back, shoulders.

Go work out.

Order is also important here (although less so since each of these exercises is independent), but if I said that it is recommended that you work out large muscle groups before smaller ones, and that you should design your regime around working opposing muscle groups on the same day, you'd want to know this information.

A use case might not be the best model for defining a work out routine, but I recommend some model to help you extract the full set of requirments for the functionality.

A model is like alcohol--it gets people talking about stuff they wouldn't otherwise talk about under normal circumstances. "Under the influence" of a model, you are going to find more information--some of it extraneous, but some of it valuable and necessary.

Chocolate Sheet Cake


Combine in a mixing bowl:

2 cups flour
2 cups sugar
1/4 teaspoon salt

In a saucepan, melt:
2 sticks butter
Add 4 heaping tablespoons cocoa.

Stir together.

Add 1 cup boiling water, allow mixture to boil for 30 seconds, then turn off heat.

Pour over flour mixture, and stir lightly to cool.
In measuring cup, pour 1/2 cup buttermilk.

Add:
2 beaten eggs
1 teaspoon baking soda
1 teaspoon vanilla

Stir buttermilk mixture into butter/chocolate mixture.

Pour into sheet cake pan and bake at 350-degrees for 20 minutes.
While cake is baking, make icing:

Chop 1/2 cup pecans finely (optional).

Melt 1 3/4 sticks butter in a saucepan.

Add 4 heaping tablespoons cocoa, stir to combine, then turn off heat.

Add:
6 tablespoons milk
1 teaspoon vanilla
1 lb minus 1/2 cup powdered sugar

Stir together.

Add pecans, stir together, and pour over warm cake.

Is your software a project or a product?

One of the most common mistakes made by software development teams and others in thinking about software is the confusion between the concept of software as a project and the concept of software as a product.

When asked, most people would agree that software is a product, not a project. After all, the software will exist long after the project comes to an end so it is obviously something fundamentally different.

However, since most of the work we do on software is done by project teams, it is easy to fall into the habit of talking and thinking about the software in project terms. This can cause a variety of bad results, from confusion to outright project or product failure.

A project is a temporary endeavor that produces a unique result. Projects have start dates and end dates. Projects have life cycles. The words people use to describe the phases and artifacts of a project life cycle vary but all projects have some version of a project charter, an initial or start up phase, one or more intermediate phases, and a closing phase. A project has scope and constraints of time and resources. A successful project produces its intended result, a result that meets the needs and expectations of the project stakeholders within the time and resource constraints.

A product is the unique result of a project. A product also has a lifecycle. A product has scope, requirements, and constraints and we can measure product quality, in part, by assessing whether the product functions as intended.

We use many of the same words to describe projects and products: lifecycle, scope, constraints, quality, etc. For software development project teams the result is often confusion. Are we talking about project scope or product scope, project lifecycle or product lifecycle? It is a good idea to be clear about which you are talking about or working on.

The project and the product are obviously tightly linked and can’t realistically be considered completely in isolation. We should however avoid comingling and confusing the project and product lifecycle, scope, requirements, quality, etc.

I'm NOT Going to Read Your Requirements

Ever get the impression that your stakeholders simply aren't going to read the requirements documents you create? Better yet, have you ever had a stakeholder actually tell you directly that he or she just isn't going to read the requirements? I haven't, but I wish someone would. That sort of direct, honest communication would be a shock, but sometimes that's exactly what we need to shake ourselves out of familiar, yet unproductive, patterns of behavior.

In a recent post, Joyce explained the importance of context in our work. Her post was about providing context for both your current and future audiences. But what if those audiences can't or won't use the documents? Even if you provide context for your requirements like Joyce suggests, if you don't deliver your requirements to your stakeholders in a way they can or will use (in other words, provide them in the context of their use) then you've completely missed the boat.

Unfortunately, many times we don't find out that stakeholders can't or won't use the documented requirements until it's too late -- the system has been built, it doesn't meet the requirements, but it's too late to change anything and still meet the delivery date. When pushed to explain WHY the system doesn't meet the requirements, the stakeholders explain that they thought something was included in the requirements but it wasn't, or the development team explains that they couldn't understand the requirements so they just built what they thought was right, or the test team explains that they were unfamiliar with the format of the requirements so they tested against the existing system instead. Sound familiar?

It would be great if your stakeholders told you up front that they wouldn't use your documentation. That way, you'd have a chance to talk with them about what kinds of documentation they could or would use. You could discuss all of the options for capturing, documenting and managing requirements, and then you could choose the right set together. You could pick the right tools for the context of their use. If only those darn stakeholders would just be straight with you up front, right?

Let's be honest -- it's our job to know that requirements reviews and use are challenges in software development, and more importantly it's our job to find ways to make the process work. Talk with your stakeholders about past projects and requirements efforts. Find out what their context is for the work you're doing. And then use your expertise to come up with and use new approaches and tools that make this project better than the last for everyone involved.

What Problems Are You Spending Your Time Solving?

One of the things I find interesting is the news pundits who ask the question “If a woman is elected president, what will her husband be called?” To me, the answer is completely obvious. If the wife of a president is a “First Lady,” then the husband of a president is the “First Gentleman”. Question answered, move on to discussing a real problem.

I just asked this question to a group, and none of them came up with “First Gentleman”. When I stated it, the responses were that it made sense, but… “It isn’t snazzy enough”, “It doesn’t fit in today’s catch-phrase world” and “We’ll probably invent a new term and change the term for the First Lady as well.” All this in spite of the fact that “First Lady” has worked just fine for over 200 years.

This is very analogous to some of the problems we have in software development today. We spend our time solving fake problems instead of real ones. We look for the snazzy, catch-phrase, new solution. So much time and effort is spent on finding the “best possible solution,” when with the current state of software, most users would be pleasantly surprised by a reliable, adequate solution.

Think about it next time you’re solving a problem—is it a real problem?

Dr. Changelove (or how I learned to quit worrying and love change)

I was in a meeting recently in which some great ideas were presented. The ideas would result in a number of improvements which would benefit the company and the users, and they were all pretty easy to implement. However, the ideas weren't product features ... they were changes to behavior. While I wholeheartedly agreed with what was being proposed, I didn't LIKE the ideas because they meant that I'd have to change.

I'm a crea