$15.$ A common problem during communication occurs when you encounter two stakeholders who have conflicting ideas about what the software should be$.$ That is$,$ you have mutually conflicting requirements $.$ Develop a process pattern $($this would be a stage pattern$)$ using the template presented in the textbook, see the figure below of the patternAn Example Process Pattern

The following abbreviated process pattern de$-$

scribes an approach that may be applicable

when stakeholders have a general idea of what must be

done but are unsure of specific software requirements.

Pattern Name. RequirementsUnclear

Intent. This pattern describes an approach for building

a model $($a prototype$)$ that can be assessed iteratively by

stakeholders in an effort to identify or solidify software

requirements.

Type. Phase pattern.

Initial Context. The following conditions must be met

prior to the initiation of this pattern: $(1)$ stakeholders have

been identified; $(2)$ a mode of communication between

stakeholders and the software team has been established;

$(3)$ the overriding software problem to be solved has been

identified by stakeholders; $(4)$ an initial understanding of

project scope, basic business requirements, and project

constraints has been developed.

Problem. Requirements are hazy or nonexistent, yet

there is clear recognition that there is a problem to be

solved, and the problem must be addressed with a

software solution. Stakeholders are unsure of what they

want; that is$,$ they cannot describe software requirements

in any detail.

Solution. A description of the prototyping process

would be presented here and is described later in

Section $4\mathrm{.}1\mathrm{.}3.$

Resulting Context. A software prototype that

identifies basic requirements $($e$.$g$.,$ modes of interaction,

computational features, processing functions$)$ is

approved by stakeholders. Following this, $(1)$ the

prototype may evolve through a series of increments to

become the production software or $(2)$ the prototype

may be discarded and the production software built

using some other process pattern.

Related Patterns. The following patterns are

related to this pattern: CustomerCommunication,

IterativeDesign, IterativeDevelopment,

CustomerAssessment, RequirementExtraction.

Known Uses and Examples. Prototyping is

recommended when requirements are uncertain.