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!