Requirements Defined - Seilevel's Software Requirements Blog

How To Choose A Software Requirements Model

2008-07-02T08:20:00.001-05:00

Do you find that you're always trying to use process flows on your projects, but they just don't seem to fit your needs?

Do you need to start modeling requirements, but can't quite decide what models to use?

There are quite a few requirements models out there to choose from, ranging from the mundane (process flow), to the amorphous (use case) to the exotic (fishbone diagram). Knowing which models may be most helpful to you can be a bit tricky, but the following tips can help!

Choosing the Right Software Requirements Model

If your application has:

Lots of User Interaction - useful models can be Org Charts, Use Cases, System Context Diagrams
A Complex UI - useful models can be Org Charts, Use Cases, Wireframes
Lots of Involvement with Different Systems - useful models can be System Context Diagrams, Data Flow Diagrams
Data Processing - useful models can be Entity Relationship Diagrams, Data Flow Diagrams, System Context Diagrams

And don't stop with these - there are many other models to explore! Take the plunge, and break away from process flows today!

Check out these detailed explanations.

How to Prepare for Requirements Sessions with Your Users - Tip 1

2008-06-30T08:13:00.000-05:00

This is the first part of a four part series on how to prepare for software requirement sessions to be most effective with your users' time (and yours!).

Can You Get All of Your Requirements In One Session?

There is general agreement in the software industry that talking to end users to gather requirements is critical to the success of the project. However, a common issue is that users are particularly busy. For example, if an organization decides to add features to a call center application, talking to the call center representatives is critical, but it’s also costly to pull them away from taking calls. In addition, requirements analysts are extremely busy and may have to limit how much time they spend with any one user.

A common issue in gathering requirements is leaving a stakeholder meeting where you missed major requirements because the “next question” to ask did not occur to you at the time. It is unreasonable to think that this will never happen. The reality of software requirements efforts is that they are iterative. In addition, there is quite a bit of critical analysis that must take place, and that analysis cannot always happen immediately in a meeting environment. Whatever the reason, there is certainly a need to get the most out of time spent with the users. So how do you best prepare for meetings with your end users?

Software Requirements Sessions Tip 1: Organize Your Time

Requirements analysts should realize that the software requirements life cycle can be time intensive - including time to analyze, edit, review, and update. The key is to maximize the value from everyone’s time.

Make sure that requirements sessions are well planned, inviting the minimal group of people necessary to get value out of the meeting. The burden of extra time spent should be on the requirements analyst, not the users who are being taken away from their primary jobs. Prepare an agenda and appropriate artifacts prior to the sessions in order to keep the meeting focused on making valuable progress.

In dealing with any super-users who are unable to commit much time, it is important to zero in on specifically what information they must provide. Then allow these users to suggest alternative users to meet with to provide additional information, ensuring them you will allow them to review what the alternative users provided.

Come back soon for part 2!

How do you prepare for a requirements session? I'd love to hear your answer in the comments.

Why Traceability (by itself) Is Worthless

2008-06-25T07:52:00.000-05:00

Performing traceability of delivered functionality to requirements without tying them back to Business Objectives is in my opinion an exercise in futility. To anyone engaged in this exercise, I ask “So What?”

At first blush this might seem like an extreme position to take. The benefits of requirements traceability seem readily obvious whether or not they are tied back to Business Objectives. You can determine what requirements were implemented, when they were implemented, what still needs to be done and so on. All of these are good things in and of themselves.

Do You Need Business Objectives For Software Requirements Traceability?

By way of answer, imagine that you are writing requirements for an Experiment Management system. Consider the following scenario.

The first set deals with setting up the experiment. The other set deals with analyzing the results of the experiment.

One of them is responsible for the team that defines and sets up the experiments. The other manager leads the team that analyzes the results of the experiments.

Each set had a total of 10 requirements each. The users prioritized their requirements and each team came back with 4 “critical” and 6 “nice to have requirements”. Assume that all the “Critical” requirements are equally important and deliver approximately the same amount of functionality each to the final delivered product.

They satisfied all of the “nice to have” requirements of both sets. All 4 critical requirements of the experiment analysis requirements were satisfied, but only one of the critical requirements of the experiment set up requirements.

Business Objectives Are Your Yardstick For Success

Simple traceability that did not tie back to Business Objectives would show something along the following lines:

By any yardstick it looks like a spectacularly successful release.

But consider for a moment if the Business Objective for the release has been defined as “reduce the amount of time taken to perform experiment set up by 90% so that the company can increase the probability of successful new product creation by increasing the number of experiments that can be set up by our team of scientists.” The company came up with this objective because it is far easier for them to hire analysts than find skilled scientists who can dream up new experiments that will result in new products.

If we were to apply this knowledge to traceability and coverage of requirements, a very different picture of the success of the release emerges.

All else remaining the same, from a Business Objective stand point, we have about 25% coverage of what is really important to the company for this release. So, this was a pretty dismal release though the raw statistics that do not tie back to Business Objectives seem to indicate otherwise.

At the end of the day, companies build software that advance their prospects and help them achieve specific business goals. As requirements professionals, we need to tie back the outcomes to the Business Objectives. So, if we are not tracing requirements back to the Business Objectives, we are generating data that may or may not be useful or relevant in the grander scheme of things.

There is definitely some virtue in generating data for its own sake. This would be the case in doing all the hard work to trace requirements to specific functionality that has been delivered. But not taking the final step and tracing it back to Business Objectives misses the whole point of the exercise. We are guilty of generating data without giving it the proper context that Business Objectives provide.

So the next time, someone tells you they are tracing delivered functionality back to the requirements, ask them if they are tying them back to Business Objectives. If the answer is no, ask them “So What?” I would.

Controlling Changing Software Requirements

2008-06-24T07:53:00.000-05:00

The CCB (Change Control Board). It is their responsibility to oversee and approve any proposed changes to your software project. They're officially in charge of moving the cheese around - or approving completely new cheese.

Once they get to work, your nice, safe plate of Pepper Jack could morph overnight into something rich and strange, like English Farm Cheese with Dried Currants.

Project changes happen, but they aren't always easy to deal with. And they don't just affect Development (Nacho Cheese Doritos(tm)) or QA (Swiss Cheese).

It's critical that CCBs recognize that scope changes also affect documented requirements and the people who manage those requirements.

Scope Changes Affect Software Requirements Tasks

Changes approved by the CCB may generate requirements-related tasks, such as:

Identify all requirements impacted by the change (requirements traceability will make this much easier)
Update impacted requirements documentation and related models
Manage review and approval of changes to existing requirements
Elicit additional requirements to supplement or replace existing requirements
Communicate all changes to impacted parties

Keep Business Analysts in The Loop

All impacts of a requested change must be identified and agreed upon so that informed decisions regarding the request can be made.

Even seemingly small or simple requests can easily become big changes when all of the related activities are considered.

Be aware, actively participate in controlling change on your project, and when your CCB hands you a wedge of Vieux-Boulogne (the world's smelliest cheese), you won't even blink.

Signing Out from INCOSE 2008

2008-06-21T16:44:00.004-05:00

Well, I hate to say it, but my week here at INCOSE 2008 has come to an end. And though I must say goodbye to my INCOSE friends, I'm not headed home quite yet - first I will enjoy a few days in Amsterdam, just up the road from Utrecht.

A few final comments from this side of the pond (some of these are purposefully non-INCOSE related to keep it interesting!):

After hours of listening to talks about process, I have to say - systems engineering processes are heavy! There are images dancing in my head of things like a project plan circle diagram that even in a 3x3 foot printout, you have to squint to read the tasks. Or there are the matrices that don't even come close to fitting on a page, yet they try to squeeze them in for demonstration of a concept.
I spoke with some systems engineers who, when I explained what Seilevel does, said things like "Really? Requirements as a job?" or "You have a business around that?" or "I never thought of them as a separate thing, they were just some other task on my project that maybe got done." or my favorite "Why are you at a systems engineering conference then?"
It's a small world. In a city of more than a million, today I ran into a fellow INCOSE member from San Antonio, TX on my way back from the Rijksmuseum.
Most all of the presenters like to use words on slides! Seriously, I almost think it must have been in the presentation requirements - "Must have wordy slides". Perhaps I can suggest Beyond Bullet Points.
I enjoyed reconnecting with my friends from what I like to call "Seilevel Europe", the HOOD Group (and mind you, they would and should probably call us "HOOD Group USA"). We have very similar companies, with similar methodologies, in different parts of the world. If you haven't heard of them, I encourage you to take a look at their work.
Sadly, Holland just lost in the quarter finals of the Euro 2008. I say sadly because I've actually become quite fond of watching the "Oranje" games (or maybe just the crowds hanging outside of bars).
I once again was reminded that so many Americans have a tendancy to focus on just us. This is by no means a generalization though. I personally like to intermix with those from other countries, though I'm also quite guilty of speaking American and little else. Anyway, it was frustrating to listen to talks from Americans who would only quote American statistics, or American events, or American disasters. My European friends were quick to point it out for me "Oh another American talk!". Thankfully some of the talks were very different than that though, making me much more proud.
We should do more peer reviews, but not for the obvious reasons. A systems engineering organization requires team members to be on peer review boards, not so much for improving the quality of the deliverables, but more importantly, to expose the engineers to more projects and ideas that they can then apply to their own projects. Brilliant, I say!
The field of systems engineering has many many many outstanding success stories, ranging from the Airbus 380 to the ProRail system of the Netherlands. There are lots of great lessons to be learned here that can be applied to much simpler projects. But really, how cool would it be to build a network of thousands of kilometers of rail or to put a new airplane in the air?

Anyway, in a few days, I will return home with many fond memories of the Netherlands and INCOSE 2008.

INCOSE 2008 - Can You Build an Airplane with an Agile Approach?

2008-06-21T16:12:00.003-05:00

With all of the buzz about Agile, I have to mention that here at INCOSE 2008, I did not hear a single mention of it (except when I asked about it directly!). Actually, that’s not true, at one point I was excited to see a speaker’s slides which referenced applying agile processes as a step in a project. Then he spoke to the slide and I started to suspect he meant agile in the pure definition of the word, to move quickly. At the end, someone asked him the specific question as to whether he meant the agile software methodology and he clarified that he did not. So I left the conference wondering - with all the discussions about processes at a conference like this, why are they not ever speaking about agile?

Airplanes Are Not Software Requirements

My first guess - this probably relates to some of the core differences between systems and software engineering. I am going to over simplify this and just say that it is about scale. Systems projects are just a superset of software and hardware projects, integrating and deploying some combination of these. The teams of people deploying systems projects are quite large. And many of the projects discussed here are for government or regulated systems where specification and traceability is necessary. I could see how subsets of systems projects could in fact be developed using agile (pure software components), but I’m not convinced that an entire end-to-end project can. To put this in context, imagine you are building an airplane - a very commonly referenced type of systems engineering projects. Can you see this working using agile?

All skeptism aside, I do think that iterative development most certainly could work well on systems projects, and most people here would not argue that. In fact, I would love it if we could find examples of agile working on systems projects, because the number one feeling I get at systems engineering conferences is a craving for lighter processes.

I decided to do a little research outside the conference walls, and low-and-behold, I found a great article on this exact topic – “Toward Agile Systems Engineering Processes” by Dr. Richard Turner of the Systems and Software Consortium. The article is very well laid out, and I highly recommend reading it. He defines what agile is and what he believes the issue why most systems engineering projects are not agile. For example, he suggests that executives and program managers tend to believe that the teams involved have perfect knowledge about systems we are building, so we can plan them out in advance and work to a perfect execution against a perfect schedule.

Agile Can Work With Complex Systems

He talks to how to the agile concepts can work in systems projects. Here are a few examples summarized from his article:

Learning based: The traditional V-model implies a one-time trip through, implying one time to re-learn. However, perhaps the model can be re-interpreted to allow multiple iterations through it to fulfill this.
Customer focus: Typically systems engineering processes do not support multiple interactions with the customer throughout the project (just up front to gather requirements). That said, he references a study indicating the known issues with that on systems projects. Therefore, perhaps processes should be adapted to allow for this, particularly allowing for them to help prioritize requirements throughout projects.
Short iterations: Iterations are largely unheard of because the V-model is a one-time pass through the development lifecycle. That said, iterations of prototyping through testing could be done in systems engineering in many cases. The issue is in delivering something complete at the end of each iteration. He suggests that this is not as important to the customer in large deployments as is reducing risk, validating requirements, etc. This is a great point to rememember the airplane example! Could we have even a working part of an airplane after 2 weeks? What about even the software to run a subsystem on the aircraft?
Team ownership: Systems engineering is very process driven, so this one is tricky. Dr. Turner puts the idea out that perhaps allowing the systems engineers to drive it instead of the process to drive them, while more uncomfortable for management, might produce more effective results.

So while he does give some suggestions to adapt systems engineering processes to be more agile, I don’t think this will qualify as purely agile. And frankly if it we tried it, I think I'd be fearful to be in the airplane! But to quote Dr. Turner directly “…other hand, agility is much more a state of mind or philosophical approach than a set of rules that have to be followed regardless of appropriateness.” Using that idea, combined with what I saw at INCOSE 2008, I can see some definite opportunities for improvements for the field systems engineering.

INCOSE 2008 - Technical Team Accountability for Requirements and Delivery

2008-06-19T01:41:00.001-05:00

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

2008-06-18T01:56:00.006-05:00

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

2008-06-17T01:23:00.004-05:00

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

2008-06-16T15:22:00.001-05:00

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!

Live from INCOSE 2008

2008-06-16T14:50:00.002-05:00

I think this is becoming a new favorite pastime, blogging from conferences! I’m here at INCOSE 2008 in the Netherlands, specifically the beautiful old town of Utrecht. In case you are not familiar with it, Utrecht is the oldest town in the Netherlands, about 30 minutes by train from Amsterdam.

I have been here a few days now, acclimating from jet lag and touring about. In some ways it feels just like home – a university town, with people in orange running around the streets celebrating at night (and drunk). The difference is that instead of cheering for UT’s latest victory, they are cheering for the Netherland’s football wins at Euro2008.

Anyway, I'm here and hope to do some posting "live from INCOSE 2008" all week, as I've done in the past.

Just a quick intro to INCOSE - it is an organization in support of systems engineering. This international symposium occurs each year, to encourage sharing of new ideas in systems engineering. I'm particularly interested in the conference because I get to learn about working on large systems projects. We see a variety of both large software application projects and systems projects, and so it's fun to see the distinctions. Honestly, many of the concepts, methods, and tools apply to systems and software projects. But in some cases, there is much more complexity in large systems projects that brings out new requirements challenges.

One of my favorite parts of this conference is hearing people's examples. There are a lot of people from the transportation industries in Europe, with fantastic projects for railroads, waterways, and aerospace.

Are UI Requirements Software Requirements?

2008-06-16T13:30:00.000-05:00

User Interface design is often assigned responsibility for look-and-feel. While I understand the importance of UI design, I am highly dissatisfied by its reliance on "heuristics" and, frankly, the uneven quality of those who profess expertise in the subject.

I submit that UI needs a haircut -- that we should limit the scope of what falls into the realm of UI. I think look-and-feel might be a better overarching category, but even that is too broad. The underlying flaw is that practical UI is rarely formally tested and less frequently permanently linked to business objectives.

The next revolution in requirements will be traceability or -- as I prefer to say -- connectivity. To me, traceability implies a one-way progression from objective, to requirement, to specification, to development, to test, with each transition as a one-way gate, during the passage through which one must abandon all hope of returning. Connectivity, on the other hand, is the continuous, two-way link between

Business Objectives

Marketing Objectives

Functional Requirements

Development

Testing

Usage

Such that any shift in one puts pressure on the others. It is connectivity that provides for not only rapid development, but presents the possibility of instantaneous development. Being able to modify a product this way depends wholly on being able to pick up the thread and see where it tugs. Before this was left to intuitive judgments, which were imprecise and incomplete leading the product into an inevitable "slow drift" away from the original business objectives.Imagine that you wanted to capture a certain "feel" as a marketing objective...

Why? Well, let's say that you believe "slippery" is the feel that would increase sales for a certain segment (amphibian programmers, say). If you can make that testable connection, even if it proves that there is no correlation, you have created an underlying framework to test your inference.

Even the softest requirements should be "connected" to business goals. If creating such connections seems like too much trouble for the requirement, chances are you're not dealing with a requirement in the first place.

Thomas the Tank Engine on Software Requirements

2008-06-12T08:23:00.001-05:00

At my house, we recently entered the phase of fascination with Thomas the Tank Engine. If you're not familiar with Thomas and his many, many, many friends on the Island of Sodor, then you must not know anyone between the ages of 2 and 10, because they're a hit with that crowd. In fact, my son has decided that he'd rather "watch Thomas videos?" (said in his cute little "please" voice the first time) ... "watch Thomas videos" (said a bit more directly the next time) ... "WATCH THOMAS VIDEOS!!!" (you get the picture) than do just about anything else. So, I now am learning a lot about Thomas and his friends.

One of the most important things on the Island of Sodor is to be "really useful." The engines spend a lot of time worrying about whether or not they're being useful and trying to find new ways to be more useful. The highest praise a tank engine can receive is for Sir Topham Hatt (who runs the place) to tell the engine how useful he or she has been.

Being Helpful Isn't Enough

I've spent more time than I'd like to admit wondering why being useful is the most important thing on Sodor. Why not being helpful? Or being friendly? Or sharing? Or eating your vegetables? Or any of the other lessons that kids need reinforced? Is rail baron Hatt on to something?

When I put the question in terms of requirements work, it makes much more sense to me (which probably says something about the odd way I think). When working on a requirements project, it's great to be helpful and friendly and share (eating your veggies is a good idea, too, but of less importance in this case). However, all of those qualities may not actually help you do the job a requirements engineer is supposed to do.

Provide Useful Software Requirements Work

If I'm helpful in supporting existing processes which enable the project to fail, that's no good. If I'm friendly but let the stakeholders change requirements willy-nilly, that's no good either. And if I share the requirements information with the development team but they can't understand it, then what good have I done?

What's more important is that I do things which are useful to the project. I suggest (dare I say "implement"?) process changes which will help the project succeed. I force the business to make hard decisions about scope. I work with the dev team to make sure that the requirements are understood. And in doing so, I am "really useful indeed," as Sir Topham Hatt would say.

And then I eat my lima beans.

Is Your Product Knowldege an Asset or Liability?

2008-06-10T14:27:00.001-05:00

There was recently an interesting post by John Mansour on the Austin PMM Forum (registration required) discussing whether Product Knowledge was an Asset or Liability to product managers.

The author makes several claims about how product knowledge is a liability:

"In a nutshell, the more product knowledge you have, the less product
management you're doing because your product knowledge gets you sucked
in to a plethora of non product management issues."

"Furthermore, too much product knowledge leads to micro management - the kiss of death for anyone in a leadership role."

"Detailed product knowledge = liability because you can't see the forest from the weeds."

"Detailed product knowledge = liability because it forces you more into 'how' features should work instead of 'what's needed and why' from a business perspective."

"The more you know about your product the more difficult it is to position its true value. "

I have to disagree with Mr Mansour that these are true liabilities, in the sense that the absence of product knowledge doesn't truly mitigate the liabilities. Good product management is fundamentally about good product management.

It's your job as a good product manager to avoid running down the ratholes that you could run down as a result of your product knowledge.

Secret Skills and Qualities of a Great Product Manager

2008-06-05T08:35:00.000-05:00

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.

Get More Productivity Out Of Your Email

2008-06-03T08:02:00.001-05:00

Have you ever received an email and all you could think was “Okay, so now what?”

Or, even worse, you go off and do some work in reaction to it and then find out the email was FYI, no action expected?

Unfortunately, I have. Both cases. And, I'm afraid to admit, I’ve probably sent a few emails that had the former reaction, if not the latter.

After a less than productive email exchange the other day, I remembered a guy I used to work with who had a hard and fast rule: “Before I send an email, I ask myself what action I expect the recipients to take, and make sure that it is clear.”

Good advice. It sounds so simple, so obvious. Yet, since a coworker and I both needed the reminder, I thought I’d share it.

Six Requirements Models For Agile Projects

2008-05-28T14:51:00.001-05:00

When working on any agile project, most people will agree there is still a need to understand requirements. With the quick iterations of these projects, it’s more important than ever, to use visual models to capture the requirements. When done correctly, they are easier and quicker to create and understand than a list of written requirements. Selecting the appropriate models will vary by project; however, we can suggest a few common choices that work well.

High Level Models
At the beginning of the project, it is important to get a quick picture of the breadth of the project. This picture will help the team determine where to dive for depth. It is really important that these models are done as broad strokes, with just the bare minimum information. To get a sketch of that big picture, consider these models:

Context diagram – This diagram simply sets the landscape of the project, clearly indicating the scope boundaries.

Org chart – This is a model that often already exists in the organization. It can quickly help identify all the possible users or user groups that should be included in the project discussions.

Data flow diagram – This is a quick sketch of the key pieces of data flowing through the system, including where it is created, changed and deleted. The data in this diagram should only be data that is important to the users of the system. They will help to identify the most important data and systems to work with.

High-level process flow – Let’s start by saying this is nothing fancy or complex. The flow diagram should describe the major obvious steps. Again, the purpose is to sketch it simply, to give the big picture. In no way is it meant to be comprehensive or detailed.

Imagine one of your iterations requires bringing in new users to the team. These four models will give them an opportunity to quickly see the big picture of what this project is and where it is going, without having to read a 200 page spec (since there isn’t one!). You can also use them with your users to prioritize the most important pieces of the system for the iterations.

Models in the Iterations
Once you have prioritized the work for the first iteration, the two most popular models are likely to be:

User stories – You can write these for the most important parts of the flow. They will be less detailed than the traditional use cases, supplying just enough depth to be developed.

Wireframes – These will be connected to high-risk user stories, when sketching an interface might be a good aid to help the users explain what they need. These should be done in a quick modeling tool, or just by hand.

There will be other models. Sometimes you won’t even use these. The common theme in all of them is to create a visual representation of the requirements because it is faster to create and read. And with them all, only do the bare minimum necessary.

Four Ways To Improve Agile Requirements Management

2008-05-28T14:27:00.006-05:00

One of the challenges of Agile projects is ensuring that the requirements remain “Agile”. While requirements are not necessarily neglected on Agile projects, an Agile project may erroneously take a waterfall approach to requirements.

Here are some simple techniques to adapt your requirements management effort to an agile project. The quotes at the beginning of each section are from the “Principles Behind the Agile Manifesto” at http://agilemanifesto.org .

1. Communicate Requirements Often And Effectively

“The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”

Two problems with email is that it is inefficient and easy to ignore. Email thread discussions can be long, tedious, and annoying. Despite the advances in emoticons over the past several years, it is also impossible to interpret non-verbal communication in email.

Resolutions to discussions around requirements, scope, and implementation will be resolved much quicker and to the satisfaction of more stakeholders through a meeting or hallway conversation.

If moderating a large number of email discussions is part of your current requirements process (for example, after the initial draft of the requirements doc is published), perhaps it’s time to schedule regular meetings at key points during the release cycle.

Established method: Email discussion

Suggested method: JAD, daily stand –ups

2. Use Collaboration Tools For Requirements Management

“Business people and developers must work together daily throughout the project.”

This is related to the other “C”—Communicate.

Communication on a project should be visible to all stakeholders in the project. Changes to requirements should be pushed out quickly and universally, without having to remember whether the developer who started last week is on the dev@mycompany.com mailing list.

Manage requirements in a central location where all stakeholders have immediate and easy access. An internal website for requirements and product management information is a much more efficient way of reaching your audience than emailing copies of documents to your stakeholders.

If possible, include collaborative tools like wikis and discussion boards as part of your website.

Established method: Word documents attached to emails

Suggested method: Wiki/Web page with automated change notification

3. Add Models And Wireframes To Your Requirements

“Continuous attention to technical excellence and good design enhances agility.”

If applicable, use wireframes or mockups with callouts as a supplement to your requirements.

This is especially useful on projects which call for enhancements to existing interfaces. A wireframe with brief text descriptions is easily consumable, and conveys a large amount of information very efficiently.

Include more detailed descriptions of wireframes and mockups in your user stories, and publish it on your internal product management website (see #2 above).

Established method: Design document/specification; Text-only documents.

Suggested method: Internally-hosted website with wireframes and bulleted descriptions

4. Keep User Stories Simple

“Simplicity--the art of maximizing the amount of work not done--is essential.”

Ensure your user stories describe one and only one feature, and only the functions necessary for that feature.

Looking through a large, monolithic document which describes multiple features to be implemented across several releases wastes time.

Breaking your user stories down into descriptions of the most basic functions required for a feature also helps maintain release discipline.

Resist the temptation to include requirements for “nice to have” or “future” functionality. This clutters the user story with unnecessary information.

Established method: Large document which describes many features

Suggested method: Wiki page/website with a single page devoted to a single feature. Include links to related features.

ProductCamp Austin Is Almost Here!

2008-05-28T13:24:00.008-05:00

ProductCamp Austin is coming in a couple of weeks - it's a "collaborative un-conference/workshop on Product Management and Marketing topics."

It's free to attend!

Seilevel will be sponsoring the event and offering up a volunteer to photograph the event! We'll put the pictures on Flickr for everyone to see after.

My personal thought about it all - Austin has a lot of outstanding people in the space of product management (anecdotally evidenced by the fact I read more product management blogs written by people in Austin than anywhere else!). This event is a place to get those minds all in one place and have really interesting discussions! Unfortunately I'm unable to attend as I'm going to be on my way to the International Symposium of INCOSE 2008. However, I encourage you all to attend and write about it after!

Your Requirements Best Practices Are Not Your Reality

2008-05-22T10:02:00.000-05:00

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?

2008-05-21T09:00:00.000-05:00

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

2008-05-19T08:43:00.000-05:00

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.

Why Should You Use Requirements Models?

2008-05-15T10:21:00.001-05:00

Why should you use requirement models? Isn't it faster to just start listing the functional requirements? In this post I'll explain why you shouldn't do that - and why requirement models are so powerful.

Provide Context
You cannot pick up a list of 500 system shall statements and quickly get a grasp of what the system needs to do. Higher level models, such as System Context Diagrams, Entity Relationship Diagrams, Process Flows, and Organizational Charts are great ways to understand the complete picture. Other models can provide important contextual reference for developers, testers, and others that need to consume the requirements (Use Cases are great for doing this).

Help Derive Requirements
Models can help you generate requirements quicker than you could than without them. Use Cases are a great example of this - once you've generated the series of interactions, it is relatively easy to examine each step and ask the question "what does the system need to do to support this step?" Likewise, you can examine interfaces within a System Context Diagram and start thinking about what requirements are necessary to support them.

Prevent Missing Requirements
Going back to the proverbial list of 500 system shall statements - it is nearly impossible to look at a list like that and determine if anything is missing. There's a post here that describes this in more detail.

Easy to Utilize
Most models are easy to read and use. If you've ever had difficulty getting stakeholders or end users to review your 200-page document (and who doesn't love to read those!?), consider leveraging models to shorten the review time. It's a lot easier for someone to validate requirements while using a Process Flow or Use Case than it is without them.

So avoid the temptation to jump straight into the requirements - your requirements will be more complete, have more context, and will make it easier for others to validate and use your requirements.

A 2-year old can do this

2008-05-14T07:57:00.001-05:00

I was driving somewhere with my 2-year old daugther the other day when she started asking me questions. More specifically, she asked me one question, "Why are their no clouds today?" I quickly gave an answer, and (those of you with kids know where I'm going with this) she proceeded to follow up every answer I gave with, "Why?" It forced me to really get to the root of what we were talking about (and recognize the limits of my knowledge of cloud formation. :) However, I also realized that a 2-year old would make a great Business Analyst! One of the fundamental rules of elicitation is to ask "why?" Keep asking "why" to get to the bottom of whatever topic you are discussing with a SME, and you'll almost always find out what the real issue is. In addition, you will gain a deeper understanding of the topic being discussed. So if you ever find yourself at a loss for words when eliciting requirements, just remember to act like a 2-year old.

Know Thy Product

2008-05-13T07:37:00.005-05:00

I read a post recently in the Austin Product Managment Yahoo Group stating that Product Managers should not know their products. The author's theory is that PdM's who know their product will not be able to effectively manage their product.

"In a nutshell, the more product knowledge you have, the less product management you're doing because your product knowledge gets you sucked in to a plethora of non product management issues."

I disagree with his underlying premise that product knowledge and product management are incompatible. I think a good product manager does need to know their product, but as important, they need discipline. As it turns out, the author partially agrees with me.

"Product managers need to know their products, but not so well that they mortgage their ability to lead others, influence key decisions and articulate value."

However, he appears to believe that once a PdM has too much product knowledge, the discipline needed to perform the duties listed above is lost. While it may make being a PdM harder, it doesn't make it impossible. In the end, a PdM with strong knowledge of their product and discipline to excute their responsiblities is a winning combination.