BluePrint Tool

I attended a talk by folks from BluePrint and LexisNexis at BAWorld on Tuesday. The first bit of the talk was just an intro to agile and why it is useful on the projects. The part that I found most interesting was from someone who owned business analysis on lawyers.com - she effectively gave a verbal case study of their team using agile and BluePrint to deploy this site. This was refreshing because she was brutally honest about the state of their organization 2 years ago, some of her dislikes about other tools, and their experiences with agile not going well. However, she also then talked about how their culture is changing now and what is working really well. This talk was great because it was effectively a great sales-pitch for BluePrint, but it was given by an actual user....and you could tell she was being honest about it.

BluePrint is meant to be a BA tool. They are closely partnered with HP and it integrates to Quality Center for QA use as well. From a quick glance of things she mentioned or showed, it looks like it allows you to manage the list of features in a backlog, low-fidelity wireframes, diagrams that look a lot like visio, export to Word, and import from Excel. We are still using Borland's Caliber happily, but I'm obviously always looking at all the tools on the market to see what people are really liking and/or disliking, what new features are coming about, what's easy to use, etc.

A bit about the lawyers.com project - they were executing 3-12 week sprints and the requirements definition is about 2 weeks ahead of sprint cycles. She made a very wise comment - templates and processes

I haven't used BluePrint myself, but I am certainly interested to hear others' experiences with the tool, so please comment if you have used it.

Project Pulse - Constraint Tracker

I was just wrapping up a project co-writing a 90 page requirements document for a client and I am so proud of my work! Unfortunately our statement of work with the client says that we would only document at most 45 pages estimated at 3 pages per requirement. With this data in hand we were able to approach the client about this potential budget buster. We were both able to come away from the situation happy due to extended budgets and robust requirements. What if this happens to you? What if you aren’t working on a project that has the luxury of flexible resources? Are you prepared to protect it from hitting that brick wall?

You probably need some sort of daily gauge letting you know where your project is in relation to your constraints. Some common project constraints are pages of documentation, number of requirements, hours, or budget. Try to keep track of these stats daily to maintain a dashboard both for yourself and for the stakeholders on your project.

It could look something like this:

These graphs will provide you with a quick easy to understand overview of where you are with your project constraints. With this understanding, you can better direct your work or your teams and when needed, go to your stakeholders and tell them that they may not get what they wanted with evidence why. It could motivate them to provide you with the additional resources you need to get the project completed right!

Out of Scope Out of Mind

Be wary the out of scope feature pile. Sure it is a quick and easy way to kill off an entire new project's worth of work, but did you kill it the right way? Make sure that when moving requirements to an out of scope status that the reasons for the decision are recorded and who made those decisions.

The best case will be where the feature has been mapped against a business objective that will not contribute enough to the organization's end goals. Can't argue when someone's favicon didn't make the cut since it would provide an estimated 2 cents to the yearly income from bookmark recognition.

The worst case will be a project's funder coming to you asking why his requested feature to save sales proposals in the system didn't make the cut while you stare blankly at your documentation looking for anything.

What is the Value of that Feature?

Alright. You've just identified the features that your client doesn't need going forward, the ones they can hold off on for now, and the ones that have to be implemented with the project. How did you come to that conclusion?

Were all the different group's champions in a room with you giving the thumbs up or down? Did the project funder push their features through? Maybe the cries of anguish from users as you held a feature over the out of scope bucket let you gauge how much it was needed. Are any of those a sound business case for the need of a feature?

Depending on the grandeur of your project, maybe it is. My bets are that it isn't enough. To really know what should or should not be implemented, every feature should be tied to a business objective. At the highest level you should have something along the lines of increase sales and decrease costs. From these you can have supporting objectives such as training sales, increasing client meetings, reducing cost of proposals, etc.

So did the project really need the feature to search for client information? I would imagine that kind of feature would be tied to an objective to allow for easier access to operational data, which ties to another objective to reduce costs of supporting client request. Given that, you should have a list of measurable KPIs (key performance indicators) for these objectives. This case might have a measure of the number of client requests for data per day and how long it takes to resolve the request with and without the search capability.

Now you will have to compare how strongly this feature affects the objective to reduce costs of supporting client requests. If there are a few other objectives that tie into this one, then you might imagine that the easier access to operational data could have a 20% correlation to the parent objective. From there you can take your current costs, multiply it by how important reducing costs of supporting client requests is and then multiply that against how important easier access to client data is.

So for example, let us say that our costs are $25,000. Turns out that reducing the costs of supporting client requests objectives is 30% of that cost. Now all the sub objectives are worth some part of $7,500. We said that the objective to provide easier access to client information was contributing 20% to its parent objective. This means that it is worth $1,500 of your costs.

Now you know that not having the feature costs you $1,500. You can estimate the implementation costs of the feature as well. If the implementation is higher, then arguably the feature should not be built. If the implementation cost is less than the value of having it, then you may want to build it, but at that point, you should compare the value of all the features in case you cannot build them all – choosing the ones with the largest value.

Live from REFSQ'09 Begins

This week I’m at the International Working Conference on Requirements Engineering: Foundation for Software Quality (REFSQ’09) and the Conference on Advanced Information Systems (CAiSE’09) in Amsterdam. The first two days are at REFSQ where there are just over 30 experts in requirements engineering in attendance, primarily from academia and a combination of Europe, USA, and Canada. It’s been great fun to catch up, share ideas, and find new collaboration opportunities with colleagues in the field. And after a few years of attending conferences with many of the same people, it’s really quite fun to develop a community of friendly people who I look forward to seeing at each conference.

I’m actually here to present a paper I co-wrote with James Hulgan, also from Seilevel titled Experiences with a Requirements Object Model (our ROM) - more on that a bit later. And as always in my “Live from…” posts, I’ll post a few summaries of talks or inspiring ideas that come up this week.

The format of the REFSQ workshop is really one of my favorites. Only about a third of the workshop is spent listening to presentations, with the rest focused on discussions inspired by those presentations (or other random stories). For each talk, there is a template for the last slide that everyone follows, including:

• Which quality features are addressed by the paper?
• What is the main novelty/contribution of the paper?
• How will this novelty/contribution improve RE practice or RE research?
• What are the main problems with the novelty/ contribution and/or with the paper?
• Can the proposed approach be expected to scale to real-life problems?

Then they have a discussant assigned to each paper who also read the paper, and this person presents answers to these same questions from their point of view about the paper. And this leads us into the Q&A or discussions.

As a side note: In case you don’t know how to say REFSQ, it rhymes with “rescue”. In fact, every time I hear it said here, I think they are saying “rescue” instead of “refsq” and perhaps this is a sign of what we are doing here!

REET'09 Workshop - Call for Papers

Hey everyone, I'm co-chairing the REET09 workshop again this year. It's held in conjunction with IEEE's Requirements Engineering 09 conference in Atlanta this year. I'd like to encourage all of you to submit papers or training activities related to educating people on requirements! If you don't feel like you have enough to do a paper, you could even just submit a fun activity you've done to teach people about them. Here is the formal call for papers:

The 4th International Workshop on Requirements Engineering Education and Training (REET09)
Held in conjunction with the 17th International Requirements Engineering Conference (RE09). The workshop will be held in Atlanta, Georgia, USA on August 31, 2009.
http://users.cscs.wmin.ac.uk/REET09/

PAPERS DUE ON MONDAY 29 JUNE

This workshop will address issues related to RE education, both as part of a formal university degree and as ongoing skills training within the workplace. The workshop is intended to go much deeper than a surface discussion of curriculum issues and will examine specific ideas and techniques for teaching skills needed by an effective requirements engineer.

Papers are solicited in any of the following areas or in any other area related to Requirements Engineering education or training:
* Curriculum design for undergraduate and graduate courses. Incorporation of RE topics into more general SE and CS courses. Curriculum for industrial training programs.
* Techniques for teaching specific RE related skills such as stakeholder identification, requirements elicitation, negotiation and consensus building, requirements writing, and other critical RE skills. Specific examples of educational tools, exercises, and assignments.
* Reports on surveys and other studies conducted into the effectiveness of various teaching methods. Assessment methods and practices of RE knowledge and skills. Strategies for assessing of learning soft skills. Methods of objectively measuring assessments.

Papers will be accepted in either of the following formats:
* Position papers (3-5 pages) - Short papers stating the position of the author(s) on any of the topics within the scope of the workshop. For example, positions papers could describe experiences with a particular method for teaching an RE related skill, or could describe an innovative approach to incorporating RE education into the degree curriculum. Position papers will be evaluated based on their potential for generating discussion, and on the originality of the positions expressed.
* Full papers (8-10 pages) - Full papers describing requirements engineering educational techniques, survey results, or experiential reports. For example, a full paper might describe a specific technique for teaching an RE skill and include a case study describing its implementation and evaluation of its effectiveness as well as lessons learnt. As another example, a full paper might describe a mature tool for supporting RE training.
* Pedagogical activity papers (2-4 pages + supporting documentation) - Pedagogical papers will describe a teaching activity and provide all of the materials needed to reproduce that activity in the classroom. Authors of full and position papers, plus anyone else interested in attending the workshop are encouraged to also submit a pedagogical activity. Teaching activities will be documented using a predefined format, and will focus on one or more RE skill, define target audience and learning goals, provide step-by-step guidelines for conducting the activity, include student hand-outs or associated slides, describe the context of the activity, and briefly comment on its prior use in the classroom.

Submissions will be reviewed by at least two members of the program committee for relevance to the workshop topics of interest. Accepted submissions will be archived in a workshop proceeding in IEEE Xplore. Papers must be formatted to conformto the IEEE Computer Society proceeding guidelines and submitted electronically in Adobe PDF to the EasyChair service:
http://www.easychair.org/conferences/?conf=reet09

Workshop format:
The format of REET09 will be an interactive one focusing on practical ideas and approaches for teaching RE skills and for constructing effective RE curricular. Paper presentations will be used to foster discussion. Demonstrations of specific teaching techniques and materials will be encouraged. The workshop will conclude with break-out groups working on specific topics such as the initiative for sharing RE resources or discussing RE curriculum and developing appropriate templates.
We encourage the following to submit papers and/or to participate in the workshop:
* Educators currently teaching or planning on teaching RE courses
* Academics intending to integrate RE content into existing more generalized courses
* Practitioners interested in developing or improving RE training in the workplace

Important Dates for you to remember:
* June 29, 2009 - Paper Submission
* July 20, 2009 - Author notification
* August 3, 2009 - Camera ready
* August 31, 2009 REET09 Workshop

Workshop co-chairs:
Joy Beatty joy.beatty@seilevel.com
Ljerka Beus-Dukic l.beus-dukic@wmin.ac.uk

Program Committee:
Ban Al-Ani University of California, Irvine, USA
Ian Alexander Scenario Plus Ltd., UK
Dan Berry University of Waterloo, Canada
Al Davis University of Colorado at Colorado Springs, USA
Don Gause Binghamton University of the State University of New York, USA
Vincenzo Gervasi Dipartimento di Informatica, Universita di Pisa, Italy
Martin Glinz University of Zurich, Switzerland
Olly Gotel Pace University, NYC, USA
Ellen Gottesdiener EBG Consulting, Inc, USA
William Heaven Imperial College, London, USA
Ivy Hooks Compliance Automation, Inc., USA
Soren Lauesen University of Copenhagen, Denmark
Emmanuel Letier University College London, UK
Lemai Nguyen Deakin University, Australia
David Randall Requirementeering, Australia
Lucia Rapanotti The Open University, UK

Don't Forget Your Checklists

I have got to be one of the biggest proponents of checklists, I literally live by checklists. I have a personal belief that people just cannot remember everything they need to do in a specific situation if it’s more than a few actions - whether it is going to the grocery store, kicking off a project, doing weekend house chores, or hiring a new employee. There are mindless activities we do every day, many of them habitual and easy, but without checklists as reminders, it seems reasonably likely that we’ll forget at least some portion of the things that need to be done.

For example, if I’m going to the grocery store and I need 30 things, then without a list, I may be able to remember 9 of them, or using categorizations of things like meats, vegetables, etc. even 25 of them, maybe even 29, but if I don’t get all 30, I feel inefficient because I’ll have to go back to the store again.

If I’m starting a new project, there are easily 50 things that I have done for years when starting projects, so you might think I can do them out of habit. But the reality is, it’s really quite hard to remember all 50 of them every time. And maybe doing 40 is enough, but I’m the type of person who doesn’t want to take a chance that one of the 10 tasks I didn’t remember is the one that will most impact the project success.

In requirements, I have lots of checklists for things such as: which requirements models to do at specific points in the project, which questions to ask stakeholders, which materials to take to workshops, which quality checks to do before delivering a document to the customer, and which information to ramp my team on first.

My theme of using checklists isn’t based on any novel concepts. From the 1950’s, we have Miller’s Magic number which says humans can remember only 7 +/- 2 items. It’s true – you can test yourself, or I can test you – it’s really hard to remember more than that without a formal model in place. Then there are concepts which David Allen presents in Getting Things Done who contends that writing things down and getting them out of your mind allows you to be more productive because you aren’t focusing brain power on trying to remember them.

But most recently, I read an article from The New York Times which made me light up. It is a recap of research that showed surgeons can save more lives if they use checklists. In this study, they found using a checklist “that includes steps as basic as having the doctors and nurses introduce themselves can significantly lower the number of deaths and complications”. It further explains the success - that by using a checklist with under 20 items, the average death rate fell more than 40% and complication rates fell by 33%.

Saving lives is certainly way more impactful than my checklists (at least so far!), but you can see why I was thrilled to find yet another point of validation behind the checklists that run my life.

(As a side note, my weekend checklist has 18 things on it to complete, and this was not one of them!)

Software Requirements Plagiarism

I was talking a program manager recently who described a funny requirements situation from her past that topped most of the stories I have heard.


She had assigned the team’s business analyst do some requirements for a particular feature of a system they were implementing. He was dragging his feet for weeks on this, delivering no drafts along the way, but insisting he was working on the requirements. Well it came time to deliver the actual requirements, and he delivered. This individual had done requirements documents in the past for her projects, so she was familiar with and expected some of the typical writing issues by this person. Well, when she got the requirements document for this new system, she noticed that the typical writing issues were not present. While this seemed suspicious, one could chalk it up to having a proof-reader help out. But she also thought the requirements lacked any real substance around how to implement the feature for their business environment. It had no details about business rules, configuration needs, actual roles and permissions for their organization, etc. In fact, she noticed they seemed like they were very generic descriptions of what this feature would look like.

So after a bit more thought, she decided to do a Google search on some key phrases from the requirements document. Sure enough, she found them on the internet. It turns out, this business analyst had gone out and found a spec for an off-the-shelf product for the feature they were implementing and he submitted that as his requirements for development on their project.

What I will say is that if you can re-use requirements from your internal projects, I say go for it. I highly encourage requirements reuse using requirements patterns! The key difference here is you aren’t violating confidentiality, you aren’t stealing someone else’s work (since it’s the property of the company!), and it’s actually a useful re-use.


Creative? Perhaps.
Lazy? Likely.
Useless? Mostly.
Good story? Definitely!

Do You really Believe in What you Do?

I have a question for all of you BA/ RE/PDM people in the world. Do you really believe in what you do for a living, or is it just a job? My wife needs a new mode of transportation. Her current ride is 12 years old, has more than 240K miles on it and is beginning to require more repair than I’ve got time. So now we’re out looking at all the different vehicle options. I have to say that that I find this very frustrating because she really has no idea of what she wants. We get home from our first shopping trip and she can see that I am obviously put out by all of the "I don't know" answers she gave me while trying to find her a car. She says, “So I guess you don't want to go look again in the morning.”

Ding! The light bulb went off.

I told her we needed to figure out what our requirements were before I set foot on another car lot.

The next morning we set down with pen in hand and I started asking her what was important to her -What her needs were. We created a nice long list of items. Next, we looked at each item on the list to determine what need each of the items addressed. Finally, we prioritized the wants from the needs. We talked about number of passengers, baby seat mounts, fuel efficiency, heated seats, number, size and placement of cup holders, as well as just about anything else you can imagine. I now have a more defined idea of what she needs and what she wants in her next car, but more importantly, so does she. After all of the headache, I wondered why I did not complete the exercise sooner. This is what I do for a living. I help customers define their needs, identify requirements, separate wants from needs and prioritize it all.

If it works everyday for the job, why not use it at home? It’s hard to beat having a job that’s so helpful in so many situations.

When was the last time you found your BA/RE work to be helpful outside of work?

There is Value in a Good Passdown of Software Requirements

Several years ago, my sister in law (Cathy) went to visit my parent’s at their home. She arrived at the house while my mother was out running a quick errand.

Cathy noticed that there was a pot on the stove with some freshly brewed tea. Being thirsty and the ever-helpful daughter-in-law, she decided to go ahead and pick up where my mom had left off, so she finished mixing the tea.

My mother arrived at the house a few minutes later to find Cathy sitting on the couch enjoying a nice glass of ice tea. Mom walked into the kitchen and asked Cathy where she got the tea. Cathy explained how she had just finished what my mother started and made the tea. At that point, my mom asked her “so where did you put the sock?

Not quite understanding the question, Cathy sat there and just looked puzzled. Mom started laughing and found the blue pitcher where Cathy had made the tea. Calling Cathy into the kitchen, Mom took a spoon and pulled out a ratty looking sock from the mixture.

See, Mom had started out trying to die an old white sock tan for a hand puppet for a school project. She had seen tea used many times as a child to turn things to white material to tan and figured that no one would mess with what she was doing.

Although Cathy had good intentions, she totally missed the mark. Cathy thought she knew what was required to finish the job, so she took over without really getting a good pass down. All of her efforts produced what she thought was the end goal, but had she missed the goal of the original project. As a result, Cathy was embarrassed and had to restart her project of making Ice Tea and my mother ended up with a slightly different sock to use with her puppet.

When transitioning into a project, it is critical that we get a good pass down of not only our role, but understand the expected outcome as well. This way, we can decrease the risk of creating an unusable product. We should never assume that we understand what needs to be done.

Prioritizing Your Software Requirements, Part II

In Prioritizing Requirements, Part I, we covered the reasons to prioritize requirements and the basic technique. We’ll now address what to do when there is disagreement about prioritization.

Unfortunately, requirements prioritization exercises can degrade into arguments very rapidly. This is particularly true when there are conflicting requirements that each side feels they must have. The best way to avoid this type of emotional response is to discuss the facts – what will the impact to the business be if we don’t implement this requirement?

The only way to understand this impact for each requirement is to make sure each maps back to one or more business objectives. These objectives provide a measurable, quantitative impact for each requirement. Tracing back to business objectives allows you to rephrase the question from: “Which requirement do you want – System shall allow a player to play in more than one game at once. vs. System shall allow players to create and maintain teams of other players.” to “Which requirements is better for the business with respect to the objectives of this project?”

The trickiest thing here is setting up these relationships in the first place. If it is not clear how each feature enables the business objectives, it is certainly worth the time and effort to uncover the correct links to ensure that the features and requirements being implemented actually will help solve the problem!

The important thing here is that you are reframing the conversation from “what I want” to “why this feature/requirement will help achieve our goal.”

Happy prioritizing!

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 creature of habit. I get into a routine and like to stay there. So, even though I could see the benefits these changes would bring, I felt myself digging my heels in to argue against the ideas. My reaction was emotional, not rational ... but it was also typical. I could feel myself resisting the changes even while I thought they were the right thing to do. Based on that recognition of the benefits to the changes (along with the obvious frustration my boss was feeling with my comments), I knew that I needed to find a way to embrace the ideas. But how?

I realized that I knew the "what" of the situation, but not the "why". It was easy to understand what the changes were and how they would be helpful. What I didn't know was why we needed to make a change. I didn't understand the background, the context, or the situation that had led to the need for the change. So I asked. And, as is most often the case, there was a good reason for the changes. They HAD been well thought out, and they WERE good solutions to the problem. And once I understood the need, my attitude changed.

I talked with my boss about my reaction after the meeting. She suggested a great way to understand my reaction. She said that I was the developer, and the presenter was the Requirements Engineer. I understood what was being asked for, but I didn't understand why. The RE didn't set the context, and I didn't ask for it (at first). The RE knew why the ideas he presented were good ones (they met the business objectives), but I didn't. It was only after I knew the business objectives and how the requirements supported them that I felt good about the changes. I also felt like a part of the team which was solving the overall problem, not just an interchangeable resource performing a task.

Remember that any change, whether it's to an existing system or to someone's behavior, is difficult. Use your RE skills and experience to help yourself and others accept and support changes by providing them with the right information. When you do, you'll make the change easier and more effective for everyone involved ... and you may even come to love change, too!

How Do You Make Requirements Processes Environmentally Green - Part 2

On yesterday's post, I covered how we can reduce the use of paper in requirements practices. Today I’m going to look at how we might reduce the travel as well.

Reduce travel

The second area for improvement is in reducing the necessity of travel. With the globalization of the industry, there is significant travel around the world, for teams to meet to elicit requirements. In large companies, there is even quite a bit of site-to-site travel within the same city.

Remote Tools

In order to reduce our travel (local or long distance), we need better tools for working remotely with teams. Video conference can work, as long as it’s a reasonable cost and internet bandwidths are sufficient. The technology needs to be seamless (i.e. easy to use, no delays). There need to be whiteboard solutions that make it possible for remote teams to see the same work on the board as the people in the room.

Videos

There is a time difference issue when teams are globally distributed. Currently, teams often document requirements separately and email the thoughts back and forth. They might send documents to share or emails with questions and comments. One suggestion would be to use videos to capture each team’s ideas to share back and forth. The body language and tone would not be lost as it is in text. Obviously this has to be very easy to use technology, or text will win out. Ideally some sort of voice recognition would minimize having to speak and type the thoughts.

Team rooms

For the teams in the same room, having a team room environment can work well. For some period of time, people could sit in the same building and the same room and get a lot of work done together. This would include main stakeholders, subject matter experts, requirements analysts and even the development team. The company can avoid shifting permanent desks around by just temporarily locating them to this environment. They will have more opportunities to whiteboard solutions. They could keep lots of diagrams and other thought up on the walls without having to print them to look at. It would also minimize the need for video conferencing if they were to relocate for a period of time.

Today’s take-away thought:What are your current successes and issues with video conferencing solutions you have tried? Post your comments here.

It would seem that there are many opportunities that the requirements work we do could can be less environmentally impactful. However, I think much work has to be done on software and hardware tools for users to adopt such solutions.

How Do You Make Requirements Processes Environmentally Green - Part 1

Subtitle: It’s not easy being green

The theme for IEEE’s RE08 conference is “Requirements engineering for a sustainable world”. The obvious topics that relate to this theme are about how we gather requirements for projects that are targeted at being “green”. However, I decided to look at the problem from a different viewpoint. I was curious about how we can reduce our impact on the environment when eliciting, documenting and reviewing requirements.

The two areas that jumped out at me were:

1. Reduce the amount of paper we use
2. Reduce the amount of travel we do, particularly on airplanes

Today’s post focuses on the paper reduction and my next post will cover the travel aspects.

Reduce Paper

The first suggestion for greener requirements processes is to reduce the use of paper. It has been my experience that people print more “stuff” for requirements activities than for most other parts of the software development process. My initial thought is that we print so much because we need to see things next to each other that do not fit nicely on a screen. For example, we like to quickly flip between pages of text, look at large diagrams of a system, and draw on documents. A document is inherently linear in its organization. If requirements relate to multiple sections of the document, it’s hard to switch between non-adjacent sections. And, for whatever reason, it’s easier to read some things on paper than on a screen. A few immediate solutions come to mind around software and hardware tools.

Requirements Tools

A well-designed requirements tool that is widely adopted in an organization (over using Word and Excel) would reduce a lot of the need to print requirements documents. Ideally, a requirements management tool would manage text requirements and associated diagrams and allow you to link objects at any level, quickly and intuitively. Unfortunately, the requirements tools offered to date are not solving this problem well.

Bigger Viewing Areas

I recently increased the size of the monitor on my home computer. It’s amazing how useful the increased size is for working on large volumes of information, simply because I can view more items at once. Potentially, we could use larger LCD monitors in our primary working spaces. This would require less flipping around within documents and reduce the urge to print everything out.

Portable solutions

I sometimes see people print documents to bring to meetings to read once or share with others. The first obvious solution to this problem is to ensure the people creating requirements have laptops. Secondly, we need projectors to easily share information with others. I’d like to see a projection option built into a laptop so we can avoid lugging projectors around. Imagine you could run to someone’s desk and just project onto their wall without any setup. A final suggestion here is to use tablet PCs. I have no personal experience with them but, if they allowed us to easily sketch diagrams, move things around on the screen quickly, and jot notes on existing documents, tablets could be easier to use than the current common solutions (and require less paper of course!).

Reusable resources

When there is no option other than hand-writing and drawing things, we should use whiteboards as much as possible (ideally scanning ones that can capture your work electronically). We could also use sticky flip-chart paper that is reusable like a whiteboard. Heck, maybe even use reusable whiteboard-style sticky notes!

Disclaimer: There are some obvious assumptions here around the technologies being more energy efficient than the resources used in paper waste.

Take-away question: Notice every time you print something in the next week. Why did you need to print it? Post your realizations here.