Attendee Questions

At ICRE'98, we posed the question:

"If there were one question you would want to ask of a panel of experienced requirements engineering professionals, what would it be?"

During the conference, we formed a special panel to answer these questions.

Here, in no particular order, are the questions attendees asked. The questions have been categorized, but remain largely verbatim.

Basics

What is a requirement?
Is it useful to distinguish between requirements and design? If so, how can this be done?
Please contrast Requirements Engineering with Systems Engineering.
Studies show enormous productivity and quality differences between software engineers with similar training and education. How can the techniques discussed at this conference be applied to minimize the effect of how a software project is staffed and make software development more repeatable?
What is the most fruitful area of research within the RE discipline? Can we represent the social mathematically, and do we need to?
What level of domain knowledge should the requirements engineer have to be effective? What do you see as the benefits or weaknesses of a) having minimal, b) having moderate to expert?
Observations, experiences, ideas on interplay of Requirements and Project Planning.
What types of conflict are there between project management and requirements management are there? And how do we overcome them?

Gathering and Elicitation

Which techniques for requirements gathering work best for decision support/OLAP applications?
Do you have any guidance for capturing requirements when the company produces client-specific products rather than generic version-released products?
What are your thoughts of varying the elicitation approach by user style? What, if any conflicts will this create with
1. IT technicians
2. transitioning through analysis and design?
How do you gather organization requirements as well as technical requirements for the creation/design of a large scale socio-technical system (e.g. the new IRS system)?

Documenting

How does one decide on the mix of informal and formal methods to be used to represent requirements? What are the criteria to consider?
What's a "Pretty Good Notation" for expressing requirements?
There is much debate at my company as to how much detail should go into the system level requirements specification. Some say only the essential requirements and some say all user significant visible behavior. What is your belief?
Do you think the requirements engineering process is the specification of a solution or the definition of a problem? Why?
Will the UML specification language support systems level requirements specifications? If not, why not?
The traditional view of a requirements specification is a numbered list of shall/will statements. To what degree can other forms of requirements, e.g. scenarios, use case models, prototypes, etc., REPLACE these requirements lists. Must these alternative representations always be translated /transformed into traditional requirements statements?

Prototyping

In a project environment, where new technology is being introduced to the customer, is a successful project possible without prototyping?
Do you recommend increased use of early prototyping (to validate customer needs) during the requirements engineering process?
Is there a good way of understanding the complexity of feature interactions when dealing with a large system that has been around for many years (and much of the requirements specifications are no longer available)?
Does Internet e-commerce present a new challenge for requirements engineering? Are current approaches valid? Issues: who is the user/customer? It is unclear who will access the supplier site--users will be global and difficult to define. New systems are no longer based within one organization and most RE methods assume an organizational context.

Tools and Techniques

In your opinion, what is the best set of integrated tools that capture requirements and provide strong/good traceability through design and code and also support automated test generation?
What techniques do you use when writing the requirements specification to ensure your requirements specification will be traceable (manageable) in the requirements management tool? Do you attempt to understand the power of the tool before you begin documenting the requirements?
A success story on the use of a software tool to manage requirements... Does anyone have one?

Standards and Certification

What needs to be done to establish standards of good practice for RE (if they don't exist)?
What is your position on standards for requirements specifications?
What are your opinions of "certification" for requirements engineers? What are the problems with certification? What specifics should the certifications include (if one is offered)?
So what is the status of developing a US standard for system requirements specifications?

Object Oriented?

What are the major differences between the object-oriented requirements paradigm and the structured requirements paradigm? (Just a brief list)
What unique challenges are there in identifying, analyzing, and allocating requirements for software intensive systems that might not be issues in other systems?
What can ease the transition from functional system requirements specs to object oriented software designs?
In object oriented requirements specification should we be concerned with what the internal needs of the object are? Why or why not?

Adopting Requirements Engineering

Where are we?

Is one industry behind in the requirements management process acceptance than others?
How do you try to implement a requirements development effort within a program that has no defined processes?
Discuss the pros and cons of doing requirements analysis in geographically dispersed development environments.
Does RE provide any way to indicate when the point is reached that enough requirements are known and understood?
How do you determine what constitutes a fault? Failure is "in the eye of the beholder."
Should systems engineers (AKA requirements engineers) position themselves as strong customer advocates or champions? Please contrast with the traditional role of the typical marketing organization.

Barriers

What is the biggest obstacle to bringing in more formal approaches to RE (e.g. state diagrams, formal specs, etc.), and how can we overcome this obstacle?
Based on your experience, where in the overall systems engineering process (primarily from RE to component design) is the accurate flowdown/decomposition/allocation of requirements most problematic and what are your systems for mitigating the problem?
What challenges have you experienced and mitigation strategies would you suggest related to the role of requirements engineer beyond the initial requirements analysis phase? (i.e. how do you counter the belief that "requirements are done--now we can do real work..."
What is the single most important barrier to the successful introduction of good requirements engineering practices into IT organizations?

Selling the Idea

If the methods of requirements engineering guarantee coming in under budget and on time at a 10th of the cost, why don't we see them being used more often in industry?
How does one convince direct management that current requirements are not well written and improvements should be made to insure success of the project?
How do we convince managers about the importance of requirements engineering?
How did you sell your organization on the concept of doing enough requirements definition before the other stages of development?

This list was was transcribed into HTML by Brian Lawrence. Many thanks to Don Gause, Phil Fuhrer, and Jawed Siddiqi for serving as panelists answering these questions at ICRE'98. Further thanks to Jawed for initially categorizing these questions.