Loud and Interactive Paper Prototyping in Requirements Elicitation: What is it Good for?
This addresses requirements engineering challenges for software development teams, but it is incremental as it builds on existing prototyping methods.
The paper tackled the problem of error-prone requirements engineering by comparing Loud Paper Prototyping (LPP) with Silent Paper Prototyping (SPP) and face-to-face meetings, finding that LPP is more efficient for managing non-functional and UI requirements, adding/removing requirements, and capturing functional requirements in a study with 50 mobile app development teams.
Requirements Engineering is a multidisciplinary and a human-centered process, therefore, the artifacts produced from RE are always error-prone. The most significant of these errors are missing or misunderstanding requirements. Information loss in RE could result in omitted logic in the software, which will be onerous to correct at the later stages of development. In this paper, we demonstrate and investigate how interactive and Loud Paper Prototyping (LPP) can be integrated to collect stakeholders' needs and expectations than interactive prototyping or face-to-face meetings alone. To this end, we conducted a case study of (1) 31 mobile application (App) development teams who applied either of interactive or loud prototyping and (2) 19 mobile App development teams who applied only the face-to-face meetings. From this study, we found that while using Silent Paper Prototyping (SPP) rather than No Paper Prototyping (NPP) is a more efficient technique to capture Non-Functional Requirements (NFRs), User Interface (UI) requirements, and existing requirements, LPP is more applicable to manage NFRs, UI requirements, as well as adding new requirements and removing/modifying the existing requirements. We also found that among LPP and SPP, LPP is more efficient to capture and influence Functional Requirements (FRs).