The emphasis of this half-day workshop is have participants -- the attendees and panel -- discuss provocative issues such as the following:

 

Do “correct” requirements ensure high reliability?

How can we tell that requirements are correct?

How do we know that requirements are consistent?

Can we tell whether the requirements are complete?

How do we judge whether requirements are realistic?

Are we sure that the requirements satisfy customer needs?

Do we know how to verify requirements?

Are requirements traceable to system functions?

How should we express requirements?

 

These issues were inspired by Shari Lawrence Pfleeger, Software Engineering: Theory and Practice, Second Edition, Prentice-Hall, 2001. To address these issues, criteria are required. For example, for requirements to ensure high reliability, rather than focus on reliability predictions related to time, mapping requirements to system functions is important. While the time between cell phone failures is a relevant reliability metric, it pales in significance if a cell phone user cannot connect to another user!

 

The objective is to maximize attendee participation. This will be accomplished by the panel frequently soliciting attendee ideas concerning the above issues or other topics they may wish to discuss. All interested parties with interest or experience in requirements development are welcome to attend and actively participate in the discussions!

Introduction: brief statement of purpose of the workshop, issues to be discussed, and request for additional issues from attendees.

Statements by Panel Members: brief statements of technical issues by panelists, who wish to do so. For example, the thoughts of Sam Keene and Norm Schneidewind below.

Attendee-driven panel discussion: panel members will be encouraged to lead issue discussions and to energize attendee participation!

Summary: wrap up of discussions and summary of conclusions, if any!

 

Mike Hinchey

Sam Keene

Michael Lyu

Norm Schneidewind

 

“If I had asked my customers what they wanted, it would have been faster horses.”   Henry Ford

Developing and understanding product requirements for new products is a significant challenge. First the customer typically has not thought through all of the product features and needs. There are functional requirements, which jump out first. Other requirements seem to take time to discover. Then there are requirements of what the product should not do and how the product should behave when presented with off-nominal inputs (product robustness). Additionally there are requirements to meet business and regulatory needs. Then there are questions of infrastructure, which often are not specified. They are just typically assumed to be present and only noticed in their absence.

[Davy and Cope, 2008, 58] cited: “In 2006 C. J. Davis, Fuller, Tremblay, & Berndt found accurately capturing system requirements is the major factor in the failure of 90% of large software projects, echoing earlier work by Lindquist (2005) who concluded” poor requirements management can be attributed to 71 percent of software projects that fail; greater than bad technology, missed deadlines, and change management issues”. This requirements challenge has been long recognized and cited. 

This module will teach tools (that ask defining, development questions) to build systematically build world-class requirements.

Six Sigma tools will be presented, designed to elicit deeper thinking in developing better requirements. The tools I use include GQM, Mindmap, DPP, TQM, FMEA, to name several. These are systematic and fun to execute and enhance the planning process (e.g., traceability)

Norman Schneidewind

Requirements engineering, being the core of software development, is concerned with identifying the purpose of a software system and the contexts in which it will be used. It also facilitates effective communication of the requirements among users. Some requirements are not properly communicated and documented, which results in incorrectness, inconsistency, incompleteness, and even misinterpretation [TJO01]. More important, the inherent ambiguity of natural language is another issue of requirements represented in natural language [DEN01].

 

In our studies of real requirements documents, we notice the frequent use of “and”, “or”, “and/or”, “but” and “both” has caused the introduction of ambiguity in requirements statements. The word “and” is generally used to represent several combinations of requirements in one requirements statement. From the analysis on the requirements documents, the use of “and” in requirements statements has occasionally made the requirements ambiguous [TJO01]. For example, the requirement: “software reliability shall be achieved by time to next failure exceeding the mission duration and greater than 20 days”. The problem with this statement is that if the mission is to last only 10 days, the second part of the requirement is superfluous. Therefore, the requirement should read: “software reliability shall be achieved by time to next failure exceeding the mission duration”. In our requirements examples, we will avoid this ambiguity by using simple declarative statements sans conjunctions.

 

In addition, there are two major issues in requirements engineering. One is the loss of representation in transitioning from requirements analysis to design, to coding, to test, to operation, resulting in software products at the end of the chain that may bear little resemblance to the requirements. The second is the content of the requirements -- the content may not reflect the reality of the environment in which the software is to operate. For example, a requirement may specify that software reliability is to exhibit reliability growth but the available data may have an increasing failure rate.

 

[DEN01] Denger C., Jőrg D. and Kamsties E., “QUASAR A Survey on Approaches for Writing Precise Natural Language Requirements”, Fraunhofer IESE, 2001.