Self directed teams

The concept of self directed teams has been around for several decades in the modern corporate world. And much longer if you consider all of human society. Often times in today’s command and control world we forget that those who are doing the work are the best to determine how it should get done. I recently read this article which reminded me that we should be applying the self directed team concept to our own requirements projects.


So what is a self directed team? Simply put it is a management concept that rather than instructing from on high what tasks will be performed and putting the responsibility on individuals for those tasks by a manager, instead defines objectives that the whole team is responsible for.


In the command and control world, we defined a single person who was responsible for client referenceability, document quality, growing the business and ultimate success of the client’s project. The rest of the team was responsible for implementing tasks given to them by the lead. The most common issue was that the lead simply didn’t have the time to accomplish all of the goals. The lead could have delegated various responsibilities to his subordinates on the team, but they didn’t feel the same level of accountability as the lead because they had different goals – specific project tasks. If the lead didn’t actively create an air of discussion, the team members simply accepted the leads’ edicts because the lead was the lead and no one wanted to rock the boat. We thought we liked this model because we had a single person to hold accountable.


In the self-directed team model, the whole team would be tasked with the objectives – client referenceability, project success, document quality, end user satisfaction etc. The team is then compensated based on achievement of those goals. If one member is dragging down the team with poor performance, the team as a whole can “fire” that person from the team. The team also may select a leader to help arbitrate decisions and facilitate team discussion. There are a couple of key points. The leader is chosen by the team, the natural leaders rise to the top. Because the leader is chosen by the team, the team is empowered to give more honest feedback as to the performance of the leader and the direction of the team.


We haven’t yet implemented this but we are moving towards this model. All the literature warns that like any change initiative you cannot just tell a team that they are now self-directed and walk away. The team needs to figure out how to use their new found freedom to avoid collapsing in on itself as they reassemble.


I will keep you updated as to our progress.

India Taxi Drivers Know How To Get Their Requirements Met

Taxi drivers in India are interesting. None of the taxis so far have meters, so the payment can be a negotiation. Sometimes they tell you it is 100 rupees. Sometimes it is 200 rupees (the return trip to the hotel is always more expensive!). But then you get some drivers who say “Pay me whatever you want. I will not ask you for money.” And finally there are the rickshaw drivers who spend more time transporting you and actually pedal a bike to do it for “free”, hoping for a good tip. They take the negotiation out of it completely!

Anyway, it made me think a bit about the tactic to get paid. I bet that the drivers who let you pay what you want make on average more money. I think that there was a study on this in Freakonomics that showed that tends to be the case. Well good for them, it worked on me!

So let’s apply this to requirements. Let’s say the business writes and prioritizes their requirements. Typically the development team has to then provide an estimate on the requirements or estimate which requirements they can build in the allocated time. Either way, it often becomes a bit of a contentious negotiation. Developers feel pressure to say they can build a lot of requirements in the time-box (and then are pressured to actually do so). Or they are pressured to say they can put an estimate on all of these requirements when they really have no idea how long it will take to do them all. So in the end, this motivates some bad behaviors – for example - they inevitably alter the estimates so they don’t get in trouble for not delivering it all.

So what if instead of this, the business simply says “build what you think is reasonable, just work in order of our priorities”. The business would be motivated to maintain a positive relationship with development – the power of “liking someone” can help you get more out of them! The developers are not pressured to lie, for back of a better word. Frankly, most people have good intentions and want to do good work, so they will work hard and deliver what they can. There would be a nice lever here if the business could actually choose their developers of course – that way if developers gold-plate or are not well intentioned, then they can choose not to use them.

RE07 - Yet Another NFR Classification System

Martin Glinz, from the University of Zurich, presented a paper titled On Non Functional Requirements. I will first summarize Martin’s points, before sharing my thought on it all.


First he stated something we all agree - there is no consensus on how to classify non-functional requirements (NFR). Sometimes we hear that what a system does is functional and how it behaves is non-functional. But this does not always hold, and he gave an example of how two different actors would each view the same requirement as a “what” and “how”.



He talked about the Volere model which separates functional requirements (FR) and NFRs from one another. But this does not work if the NFRs are not global. Then he mentioned the RUP approach where we attach them all to use cases, and that also has a flaw in that it won’t allow us to find all of them.


He proposes another classification system, with 4 facets:

• Kind (function, data, performance, constraint – the IEEE standards)


• Representation (operational, quantitative, qualitative, declarative)


• Satisfaction (is it a must have all or nothing, or part is ok)


• Role (prescriptive, normative, assumptive)

He suggested definitions, which are based on the concepts of concerns. For example, a functional requirement pertains to functional concerns. Per this classification then, system requirements as a category is broken into functional requirements, attributes and constraints. Attributes are broken down into performance, quality, etc. And together the requirements under attributes and constraints form the typical NFR set.

And then came the Q&A session which was full of heated debate. Someone proposed the now famous argument that we need to lose the term “non-functional requirement” – it implies something is broken or that it is “less-than” in value as relative to FRs. What bothered me was Martin’s response, though I didn’t have an opportunity to debate this with him yet. He said that academically he agrees he would love to stop using the term, but from a practitioner perspective, that is impossible because they are attached to it. I about laughed, most practitioners I know shy away from NFRs, I’m pretty sure they have no emotional attachments to the term. Maybe if we stopped using the term, used the actual descriptive terms (performance, quality, etc.), then they’d actually start to write them more consistently.

While I very much respect Martin’s opinions, I don’t entirely agree with where he took this topic. The question I really want to ask, but was afraid to ask for fear of flying tomatoes (it was a heated debate I assure you) is: what is the reason for the classification system? We keep seeing people who try to re-classify these, but not one of them talks about how the classification will be used. And for a bunch of requirements experts, I think that is pretty short-sighted to not consider our use cases. I am not inherently opposed to a new classification; I think we need a good one. But I mean we really need to think about how we will use the classification system before trying to create a new one that may work in terms of classifying, but not be used by anyone!

RE07 - Meet the Experts Panel Q&A

This is a follow up from the previous post on the Meet the Experts panel. The thing I loved about this panel is that 2/3 of the time was devoted to audience questions. Each question was to be addressed at a specific panelist, and then others on the panel could add comments. There were some very interesting discussions out of the Q&A, and I’m capturing some of the highlights here. I’ll try to capture the panel’s responses, but realize some of these have a personal slant to them as I couldn’t possibly capture all of the comments made.

Q: How do you handle quality requirements, particularly from the point of view of working with something like government agencies where there are various levels of contractors (prime- and sub-) passing the requirements through the organizations. Can you really effectively capture good quality requirements? And an add-on question came of what happens if those change, how do you ensure they are correctly passed around?

A: There was much discussion around what they call “key requirements”, or that I called “business objectives”. The organization needs to set a handful of these and ensure everyone is using them, every detailed requirement is mapping back to them. Ian proposed that this level of requirement doesn’t change very often, and when it does, it changes slowly. I don't think this actually is specific to quality requirements. I suggested that if you have traceability in place, when they do change or drop, you can find what at a lower-level has to change as well. Juha disagreed that they don't change frequently – which is a good point, in his product lines, the key requirements might change quite drastically and rapidly as technology changes and competitors products hit the market. (Discussion on the messageboard here)

Q: For those of us working in consulting, do our customers typically engage us because they are in crisis or are they thinking ahead to solve problems?

A: Simple answer – some of both! I think most of us have been brought into projects that are in a bad state and need help (though many won’t actually self-title it a crisis!). And with that said, we often see organizations realizing they need help in requirements and so they bring us in to help them because they know a project will be challenging or because they want us to help improve their organizations capabilities in requirements. Typically we are engaged by people at the management level, they are the ones with money to fund external help. (Discussion on the messageboard here)

Q: I’m totally paraphrasing here, but how do we handle the ridiculous requirements people might ask for. This was in context of service requirements and addressed particularly at the consultants who are external to the organization, though others had comments as well obviously.

A: Tread carefully. In consulting we do have to be careful of how we work with the people and guide them to the right conclusion. There is certainly a difference in being external to the organization (sometimes a good difference, sometimes an extra challenge!). Typically we might take the person offline and have a 1-to-1 conversation about the requirement and help them see why it may not be best for the organization. Taking a concept from Getting to Yes, I think it’s important to get beyond their "position" about the requirement understand their "interests" behind the requirement. Through that you might be able to help them drop it, change it, or realize you are wrong and figure out how to include it. And as Ian pointed out, this is not simply a matter of asking “why” over and over – it’s a bit of a more complicated conversation than that. Brian made an interesting point that sometimes you have to deliver the hard news and they just will not want to hear it, and you will be shown the door! (Discussion on the messageboard here)

Q: What are the differences in RE between internal systems projects and consumer product projects?

A: There are many similarities in the types of requirements activities you do. However, there are differences in your customers/end users. In consumer products you may have a variety of types of customers to address and you cannot possibly meet with them all. In addition, you probably have more of a marketing input to your requirements. (Discussion on the messageboard here)

Q: How do you handle the lack of requirements skills in your stakeholders? Do models help them understand requirements better? This was referenced in the context of a point Brian made about his SMEs are often from the medical field and whose roles have nothing to do with requirements engineering but are writing them anyway.

A: Absolutely models help. Pictures are easy, words are hard. However, let’s be clear – these people shouldn’t be writing requirements. REs should be writing requirements and working with these people to elicit and review them. Also, mdeling well is difficult. Brian contends that it takes 6 months up to 3 years for an RE to really be experienced at modeling requirements well. I suggested that you can dumb the models down a bit to the bare necessity. In many cases, it is not important that the RE really understands the complicated language of some of the models out there – they can simplify it and still get 80% of the value of the model. Also, Juha made the point that you still have to write text requirements – you cannot use just pictures to capture all of the details of a system – a few pages of diagrams does not replace a few hundred pages of shall statements. (Discussion on the messageboard here)

Q: Quality requirements are often best captured by “specialty engineers”. They have their own models to do this. How do we get these people to work with REs early enough in the process such that the functional requirements and quality requirements do not have a big gap?

A: First, do not separate your quality requirements and functional requirements efforts. Second, get the specialty engineers (not a term I use btw!) involved in the RE processes and meetings. They should work with you on some higher-level models and then they can go create their detailed models in their language out of that. (Discussion on the messageboard here)

Q: How do you measure the quality of requirements in a quantifiable way? Is there a sort of machine you can put them through to see if they are good? A follow-up question was on how do you measure the quality of the content of the requirements?

A: The million dollar question! So certainly you can test for some basic things like grammar structure, passive voice, use of particular words like “shall”, etc. But you really cannot quantifiably measure them otherwise. That said, we all seemed to agree you can look the success of your overall project in relation to the requirements. We measure things like end user adoption, end user satisfaction levels of the final product and numbers of defects caused by requirements errors. If you look at these metrics over time, you can get a sense of the quality of your requirements. The quality of the content is a challenge. You can do things to try to improve the quality though. First, hire smart people to do your RE – it’s a hard role and you need to be able to think to do it! You should do peer-reviews of each other’s works. And you can look at areas of your requirements where you are not being asked a lot of question by your development team – make sure they are reviewing it, because they will generate great questions allowing you to improve the requirements. Oh and finally remember that writing more quantity of requirements is not necessarily better! (Discussion on the messageboard here)

I definitely would encourage you to chime in on the message board with your own personal responses on these topics!

RE07 - Meet the Experts Panel

On Wednesday at RE07, I was part of a panel of requirements experts from industry. The other panel members were:

• Brian Berenbach (chair), a manager for Siemens’ RE focus program as part of the corporate research organization there.
• Kousik Sankar, a senior software architect in the Philips Bangalore CE Technology office.
• Ian Alexander, an independent consultant specializing in RE and author of a few. requirements books including Writing Better Requirements and Scenarios, Stories, Use Cases.
• Juha Savolainen, a principal member of the research staff at Nokia Research Centre in Finland.

We each presented what we believed to be the common and interesting problems we are seeing with requirements in industry. Here is a quick summary of mine which are based on discussions with all of our product managers:

1. Flavor-of-the-month methodology – where we actually do see project team members who believe they do not need to have written requirements. Obviously, I’m thinking of agile-like methodologies here. And while we love such methodologies for the right project, we unfortunately see people who misunderstand how to practice them, and that is the actual challenge.
2. Eliciting requirements in a global environment – the challenge here is in dealing with time, location, language and cultural differences. There are tools to help these, but our experience is that they still are not sufficient.
3. People do not really understand best practices for requirements…but they think they do – the issue is that they often read bad literature or got bad training and developed poor habits. We have to work with or un-train those habits.
4. Requirements tools are hard to use – we are seeing a lot of resistance to the use of requirements tools on projects with our customers. Our favorite saying “did they actually gather requirements for this requirements tool?”
5. People have made it boring to gather requirements – unfortunately, people have sucked the fun out of building new products. When people attend requirements sessions, they are bored and only in attendance because they really have to be.
6. There is a focus on number of features instead of quality features – we often see when our customers build a new product or add features, they want to cram in lots of features. They actually start with too many features and are never able to focus on how to build the really important ones to be usable.

I’m going to do my best to summarize the key challenges that each of the other panelists brought up, though I apologize because I’m quite sure this won’t be a perfect recount.

Brian’s top challenges are around working with very large projects, creating and managing end-to-end traceability, people other than RE’s are writing requirements and making verifiable RE work products. He works in an industry where the FDA requires the end-to-end traceability be complete, so this is of particular importance to them.

Kousik’s challenges included dealing with multi-site projects where domain competency levels vary and they are multiple product lines that share common requirements. Another challenge is with OEM development and things like making use of requirements patterns and capturing emotional requirements.

Ian’s challenges were divided into the types of work he engages with customers on. In workshops, a challenge he faces is in firefighting. In processes, his challenges include a tension between the people who demand we follow process and those who just want to get the job done. They want simple but comprehensive processes, for example. In the training space, the challenge is how do you fit a training class in 2-3 days and that it is very hard to change people’s behaviors. In tools, he finds people want to try to use the same tool for everything, they really want to integrate it to other tools and they try to force everyone to use them without success.

And finally, Juha’s challenges were that they have a huge number and variety of potential customers to please and they have a large number of products to develop each year (in the 100’s). They have some interesting challenges around innovation and what adding value looks like. And it’s not always clear who is playing the RE role.

Juha’s (and to some degree Kouski’s) challenges are interesting because they work on a consumer product line (i.e. cell phones!), whereas most of the rest of us are working on large internal systems projects.

The panel made for was a fantastic blend of experiences, roles and types of projects. I will say that participating on it was a lot of fun! Brian did a great job chairing the panel. In particular the focus of the panel was on the audience’s interests and questions, so we had very good discussions out of that. I have jotted down notes on some of the interesting questions asked by the audience, but I will post that on another day!

Live from RE07 – Visualization Workshop

I was only able to attend a couple hours of the REV workshop. I listened to about three talks on various types of visualizations. The papers were primarily focused on visualizations for product lines. There were some interesting discussions around modeling decisions visually.

The talks were:

• David Sellier presented Visualising Product Line Requirement Selection Decision Inter-dependencies
• Reinhard Stoiber presented Visualizing Product Line Domain Variability by Aspect-oriented Modeling
• Tobias Reinhard presented An Improved Fisheye Zoom Algorithm for Visualizing and Editing Hierarchical Models

As we approached my particular presentation, I was honestly quite concerned that my talk would not be very interesting to the group based on my observations of the talks before me. All of their content was much more…academic, and I’ll just leave it at that! But alas it was my turn. The paper I presented I wrote with Mike Alexander is titled Display-Action-Response Model for User Interface Requirements: Case Study. You can find more about this model here, though you’ll see we renamed the model when we worked through the paper! Anyway, I presented our paper and corresponding poster and expected very few questions for some reason. But I was pleasantly surprised. The audience was very much listening and had fantastic questions for me. Most of their questions focused around how you handle types of complicated scenarios in which elements of one user interface are based on states of another and whether we had considered formalizing the language instead of using natural language. They also had questions around whether we’d had any luck with putting this in a requirements tool yet. During the break I had more great feedback on the model from a couple people in academia who really wanted to know if we were planning to continue research and develop some tools for it.

In the end, I definitely found the REET workshop much more practical for where we are as an organization. However, I intend to look back at the presentations I missed in the REV workshop to see if there was more there that was applicable to us than I saw in the small bit I attended.

Live from RE’07!

Or should I say "sort of live" because the internet access onsite at the conference is hit-or-miss. But I am physically here in New Delhi, in attendance and writing in my spare moments!

Day 1 at the conference was rich with content and learning opportunities! I attended 2 workshops, one on Requirements Education Engineering Training (REET) and the other on Requirements Engineering Visualization (REV). The workshop format at this conference is setup to have presentations of full and position papers, followed by Q&A. And at the end of the workshop day, there is a full group discussion about some of the ideas presented during the day.
At the REET workshop, the first presentation was on a paper I wrote with Vassilis Agouridas from the University of Leeds, Developing Requirements Engineering Skills: A Case Study in Training Practitioners. I will definitely write more about this topic later.

The next talk was by Jorg Dorr from Fraunhofer Institute for Experimental Software and System Engineering. He spoke about RE-Wissen.de – A requirements engineering community portal in Germany. He gave us an overview of the structure and content of the portal. He spent a bit of time on the challenges they have had in creating a community through the portal. I thought an interesting point he made is that their portal has “practices”, not “best practices” because each company will have to decide for themselves which of the available practices are truly best.

We then had a presentation by Olly Gotel from Pace University who was presenting on behalf of her student, Renel Smith. This paper, RE-O-POLY: A Game to Introduce Lightweight Requirements Engineering Good Practices, was about how they are creating a game for RE training based on the game of Monopoly. She walked us through the play of the game. It is definitely a fun idea. Each trip around the board is meant to be an iteration of a project. And instead of jail, you might get sent to RE training for the day! There were some interesting critiques from the audience around the premise of the game. In its current state, the game is really meant to teach concepts to the students during the play of the game, and then quiz them on this. This does not necessarily promote deep learning, where the student understands how to adapt and apply those concepts on a project. In the discussion it was suggested some role playing elements might work well in the game.

Laurie Scheinholtz gave a talk on What Are Employers Really Looking For? based on her experiences in trying to capture a list of common skills that requirements engineers should have. She created this in an effort to then develop a training course aimed at teaching those skills. The discussion got onto an interesting tangent which was, is domain experience really a necessity. Most of the job descriptions she read (all except those for consulting organizations) required domain experience. The group was somewhat split on the opinions about whether that was a necessary requirement or not. And if it is, there was a bit of discussion about whether you can teach it in combination with an RE course through exercises or how a student might develop domain experience. My personal opinion on this is that we should not teach it in the RE courses, as that would be a completely different learning objective that takes away from the core point of a course. Students could take separate courses to learn a domain. But, more importantly, in our RE courses, we should be teaching students skills to learn a new domain. Given the nature of requirements engineering, everyone in the role has to be able to learn a new domain and assess the most important needs within it.

There were some other interesting presentations throughout the day, though I did step out for a few hours to attend REV. At the end of the REET workshop though, we had a very productive brainstorming discussion about best practices for RE training. Again, I’ll have to cover this in a separate post as there was much to be said!

As with last year’s conference, I’m always very wary of the academic research ideas getting so complicated that they will not be useful to most of us in everyday industry doing requirements. I really hope to do my part to influence this, particularly by continuing to work with academia on the best way to accomplish RE training.

Tune in tomorrow for some comments on the REV workshop!

RE 07 Reports this week

Joy Beatty is attending RE 07 in New Dehli. This year Joy is not only an attendee but is presenting two papers and speaking on a panel. You can find out more here.

As always, look for Joy's summary of the conference every day this week.

Borland SDK from .NET

I spent some time this month working on a requirements modeling application based on a connection to the Borland CaliberRM database using the Caliber SDK. This was a lot of fun, since I don't usually get a chance to write a lot of code, and I wanted to share some of what I learned. I did my work using C#, but this would be applicable to any other .NET language.



Borland has provided a COM library that gives you access to the CaliberRM database. You connect to it using References, the way you would any other COM library.



Connecting to the database basically involves creating a CaliberServerFactory object, and using this to get a CaliberServer. You then log in to the CaliberServer object to get a Session object. The Session object is the heart of your connection to the database.



There's a small bug in the Session object that manifests itself when you have deleted users from CaliberRM, but those users are still listed as being in Groups. The error occurs when you try to access a Property of the Session object. When you do this, you'll get a scary looking COM error:



com.starbase.caliber.server.RemoteServerException: Unable to find the following IDs in call to getAllFromServer():\n\t[com.starbase.caliber.UserID[idNumber=3263840,objectClass=class com.starbase.caliber.User,remoteObjectType=Caliber.eObjectType@15ed659,hashCode()=3263840]]



Don't sweat this. Just go to the Framework Administrator and make sure that you don't have deleted users hanging out in groups. One of the reasons I'm blogging this is that I spent some time looking for the answer and didn't find it, but google will catch this and file it away for others who run into this!



Once you have a Session object, you can access the Projects property to get a list of Projects and get your particular Project object. From the Project object, grab a Baseline, and you have full access to the Requirements hierarchy.

Agile Requirements – no BRUF just GRIT

The first principal of agile software development is that the highest priority is to satisfy the customer through early and continuous delivery of valuable software. This is a significant departure from traditional waterfall methods in which delivery of working software happens not early, but very late in the process. In waterfall type methods, the focus of the work early in the process is on understanding and documenting what the software product should do. Understanding and documenting the requirements is seen as critical to the success of the endeavor and for any non-trivial software product a significant percentage of the total project schedule will be devoted to the requirements phase before design and development can begin.

Unfortunately, the history of software development does not provide a lot of evidence that this Big Requirements Up Front (BRUF) technique works very well. There are a number of good reasons why it is a challenge to accurately and completely capture requirements before any implementation effort takes place, and some not-so-good, but commonly cited reasons as well. In any case, if one of our goals is to deliver working software early, we can’t devote a lot of time to BRUF before getting down to the business of writing code.

A common misunderstanding about agile methods is that not doing BRUF means not doing requirements documentation at all. This of course, is a recipe for disaster, or at least frustration, as many new agile teams learn. What we need is a new way of presenting requirements modeling and documentation concepts that emphasizes what is important. I like a term I heard recently, Great Requirements In Total or GRIT.

The idea of GRIT is that an integral part of delivering great software is delivering a great requirements model. Rather than trying to completely document the requirements in one big effort early on, the GRIT approach looks at modeling as an iterative process that runs in parallel, but slightly ahead of, the agile development iterations. Early in the project the requirements are typically not well understood at any level of detail but the business objectives should be clear. As the project proceeds through the initial iterations the high level requirements should tie directly to achieving the business objectives. Each subsequent iteration should add to the model, adding detail and precision to the requirements, ‘just in time’ for development. The end result, along with great working software, is a great requirements model.

If the objective is to produce quality working software, you may wonder, why we need to also develop a model. GRIT recognizes that software is a product and should be managed as a product, not a project. Each iteration results in a new release of the product. Minor releases introduce new or refined features, ultimately leading to a major release. The model provides stability across iterations and allows multiple small agile teams to work on large development efforts in an integrated fashion.

Over the total lifecycle of a software product there will be many projects that may add features, improve performance, or even move the product to an entirely new deployment environment. The model provides essential documentation of the requirements in a way that ‘documented in the code’ simply cannot.

Agile teams aspiring to move beyond small development efforts and disposable products should adopt GRIT as one of their guiding principles.

Becoming a REvangelist

The term "evangelist" probably brings up a pretty specific picture for most people. For me, I immediately see someone on television, often yelling and gesturing wildly, trying to convince me that his or her perspective is worth my monetary investment. That person might be a religious figure preaching a certain set of beliefs, a celebrity or other public figure raising awareness of a social cause, or a used car or furniture salesman telling me that "EVERYTHING MUST GO!" In any case, my impression is a negative one, and I imagine that the term conjures similar pictures for most people in the US.

And while the dictionary lends some support to that common perception, it offers another definition, too. An evangelist is also simply "an enthusiastic advocate" (http://www.m-w.com/dictionary/evangelist). So what's wrong with being an enthusiastic advocte? Other than your friends and coworkers getting tired of hearing your opinions on a topic, not much! In fact, there's a lot of power in evangelism (as evidenced by the abundance of examples of that "other" kind of evangelist), and with that power comes opportunity for requirements professionals.

I was recently speaking with a group of people who "do requirements" for a living. My job was to provide some suggestions for good ways to do their work. What I heard in response to many of those suggestions was, "Oh, but we don't do it that way here," or "That's a great idea, but it would never be accepted here." The group honestly seemed disappointed that they wouldn't be able to apply these new ideas to their work. My first reaction was to feel bad that I didn't have anything to offer which would be useful to the group. But then I started to realize that these new ideas might be even MORE useful to this group than to groups which are more open to new ideas.

It's easy to get stuck "in a rut" with our daily routines and patterns. We find the paths of least resistance through indoctrination ("here's what you need to do"), through trial and error ("well, I'll never try THAT again"), and through our needs to simply get things done ("I have one week to write the SRS, and this is the only way I'll have any chance to meet that deadline"). Over time, those paths become ingrained, and it's hard to break out of them, even if such a change would be helpful. That's where REvangelism can help.

In the case of the group I spoke with, there were fewer than ten people in the discussion, and there are probably hundreds of people in their company who work with requirements engineering in one way or another. Even if I helped energize ten people, giving them the ideas and enthusiasm to become REvangelists, what changes could they possibly make within such a large community? If all things were equal, the status quo of the vast majority would certainly overpower the new ideas of the few.

But all things aren't equal. Remember that an evangelist is an ENTHUSIASTIC advocate. Do the celebrities, preachers, and used car salesman on television get your attention because they're calm and quiet? No, the power of their evangelism comes not from the message but the delivery -- they bring a great deal of personal energy to their messages, and it's that energy that makes us take note. Requirements professionals can use that same energy to effect change within their organizations. In most cases, it will take that kind of energy just to get other people to see options outside the status quo, much less try them out. The energy a REvangelist exudes in her or his daily work inspires others, drawing those in a rut out of their patterns in order to share in the (dare I say it) fun of requirements engineering.

A journal of a thousand miles begins with a single step, and a REvolution in an organizations requirements practices can just as simply begin with a single REvangelist!

Reliability Requirements

Reliability is an important non-functional requirement for most software products so a software requirements specification (SRS) should contain a reliability requirement, and most do. But, one of our indicators of the quality of a ‘good’ requirement is that it is testable, so it is reasonable to ask whether the reliability requirements in a SRS are testable as written.

Tests for functional requirements are usually binary. The product either supports the requirement or it does not and therefore either passes or fails the test. Testing for reliability is not so straightforward. It may be difficult to say, in a binary way, that the product does or does not meet the reliability requirements.

For the users of a system it is the reliability of the system as a whole that is meaningful but for analysts and testers it is important to separate the software requirements from the hardware requirements as there are some significant differences.

There is no question that any piece of hardware will eventually wear out and fail so hardware product reliability can be stated and measured in terms of time to failure or time between failures. The random component of the reliability forecast comes from the fact that identical pieces of hardware will operate for various lengths of time before failure.

Software reliability can be a more difficult concept to grasp. A software product will fail under certain conditions, with certain inputs, and given the same inputs and conditions will fail every time until the cause of the failure is corrected. So, the reliability of a software product is more about the random discovery of faults resulting from various inputs with the system in various states. Although for small and simple systems it may be theoretically possible to test every combination of states and inputs, for a system of any size and complexity this is not feasible. The random nature of the fault discovery process means we must use probabilities when we refer to software reliability requirements and testing.

Reliability test results should be stated in terms of measurements. Measurements are taken during testing when we are collecting and analyzing data about the performance of the software. In other words, we are tracking the occurrence of failures during testing. But, a reliability requirement is a prediction or forecast of the performance of the product in the future. What this means is that while we can measure the number of failures per hour or per transaction in a system test environment we can only provide an estimate of the actual performance of the system in a future production environment.

Reliability is usually defined as the probability that a product will operate without failure for a specified number of uses (transactions) or for a specified period of time. To be truly testable a requirement for software reliability should be stated as a forecast and the test results should indicate the confidence level associated with the forecast that the product will meet the requirements.