Usability Evaluation

Usability Evaluation

Software design engineers use different data gathering techniques for establishing requirements. Requirements come in many different forms and levels of abstraction, but need to be very specific and unambiguous. Of the two different kinds of requirements (functional and non-functional), speculate the challenges you may see in capturing both requirements. Provide a rationale for your response. Low-fidelity prototypes are mainly used to conduct research on a product and are not integrated into the final product, while high-fidelity prototypes may evolve into a final product. Compare and contrast the final product that evolves from a high-fidelity product and a product built from the ground up after studying and learning from a low-fidelity prototype. Provide one(1) example of each type of product to support your response.

Paper For Above instruction

Introduction

In the realm of software development, requirements gathering and prototyping are critical phases that influence the success and usability of the final product. Requirements are categorized into functional and non-functional types, each presenting unique challenges in accurate capture and implementation. Additionally, prototyping methodologies—low-fidelity and high-fidelity—play vital roles in iteratively designing user-centered products, paving the way for products that either evolve or are built anew based on initial research insights. This essay explores the challenges in capturing both types of requirements, contrasts the evolution of products from different prototyping approaches, and provides concrete examples illustrating each scenario.

Challenges in Capturing Functional and Non-Functional Requirements

Functional requirements specify what the system should do, describing features, behaviors, and functionalities, such as user authentication or transaction processing. Non-functional requirements, on the other hand, define how the system performs these functions, including aspects like usability, performance, security, and scalability. Capturing these requirements accurately is riddled with challenges. For functional requirements, ambiguity may arise due to incomplete stakeholder knowledge, language barriers, or misinterpretation, leading to requirements that are vague or inconsistent (Bodart et al., 2011). Moreover, rapidly changing technologies and stakeholder expectations can result in requirements that are outdated or conflicting.

Non-functional requirements pose an equally formidable challenge because they are often subjective and difficult to quantify. For instance, measuring usability involves qualitative factors such as user satisfaction, which can vary significantly among users (Maguire, 2001). Additionally, non-functional requirements might conflict with one another; for example, improving system security could impact usability negatively. Prioritizing and balancing these requirements requires careful stakeholder involvement and iterative validation (Leffingwell & Widrig, 2000). Furthermore, documenting and validating non-functional requirements demand extensive testing and feedback cycles, adding layers of complexity.

Rationale for these challenges lies in the inherent difficulty of translating human, subjective experiences into clear, measurable specifications that developers can implement effectively. The ambiguity in both types of requirements underscores the importance of continual stakeholder communication and iterative refinement.

Prototyping Approaches: Low-Fidelity vs. High-Fidelity

Low-fidelity prototypes are simple, often hand-drawn or wireframe representations of the interface. They serve as research tools to explore ideas, gather user feedback, and identify usability issues early in the design process without significant resource investment (Snyder, 2003). These prototypes are not integrated into the final product. High-fidelity prototypes, however, closely resemble the final product with detailed visuals, interactivity, and sometimes functioning features. They are instrumental in refining design, testing usability, and guiding the development process, with potential evolution into the actual product.

The core difference between products emerging from high-fidelity prototypes and those built from scratch after low-fidelity research lies in development approach and level of refinement. Products based on high-fidelity prototypes are often iterative enhancements of initial detailed designs, making the transition smoother into the final product. Conversely, starting from a low-fidelity prototype involves a more fundamental development process, often requiring re-estimation, redesign, and reimplementation based on user feedback and testing insights.

Examples of Each Prototyping Approach

An example of a product evolving from a high-fidelity prototype is a mobile banking application. Initial high-fidelity prototypes of the app’s interface, with interactive features and visually rich designs, help stakeholders visualize the final experience, test specific functionalities, and make detailed adjustments before development begins. Through multiple iterations, the final app closely aligns with the high-fidelity prototypes, reducing rework and enhancing user satisfaction.

In contrast, a website redesign process may start with low-fidelity wireframes to explore layout options, user flows, and content placement. These wireframes are used to gather early stakeholder and user feedback, prompting significant modifications. Once the core structure is validated, a high-fidelity prototype is developed, which is then refined and directly evolves into the final website. Alternatively, a completely new product, such as an innovative health-tracking device, may be designed from scratch based on insights gained from low-fidelity sketches, followed by detailed prototyping and final development.

Conclusion

Capturing functional and non-functional requirements effectively is pivotal to developing successful software products, yet it remainschallenging due to ambiguity, subjectivity, and conflicting priorities. Prototyping methodologies serve as essential tools to mitigate these challenges; low-fidelity prototypes facilitate early exploration and stakeholder engagement, while high-fidelity prototypes enable detailed testing and refinement. Products that evolve from high-fidelity prototypes benefit from a streamlined transition to development, ensuring fidelity to initial design, whereas products built from scratch after low-fidelity research allow for more fundamental innovation and flexibility. Understanding these processes enables developers to better manage requirements and prototype development, ultimately leading to more usable and effective software solutions.

References

  • Bodart, F., Rolland, C., & Demol, J. (2011). Requirements management in agile development: a systematic literature review. Requirements Engineering, 16(4), 297–319.
  • Leffingwell, D., & Widrig, D. (2000). Managing Software Requirements: A Unified Approach. Addison-Wesley.
  • Maguire, M. (2001). Methods to support human-centred interface design. International Journal of Human-Computer Studies, 55(4), 587–608.
  • Snyder, C. (2003). Paper Prototyping: The Fast and Easy Way to Design and Refine User Interfaces. Morgan Kaufmann.
  • Beyer, H., & Holtzblatt, K. (1998). Contextual Design: Defining Customer-Centered Systems. Morgan Kaufmann.
  • Rudd, J., Stern, K., & Isensee, S. (1996). Low vs. high-fidelity prototyping debate. Interactions, 3(1), 76-85.
  • Schweers, R. (1998). Low fidelity prototype evaluation. Proceedings of the SIGCHI Conference on Human Factors in Computing Systems, 134-139.
  • Brown, T. (2009). Change by Design: How Design Thinking Creates New Alternatives for Business and Society. Harper Business.
  • Harries, J. (2006). Designing interfaces with cognitive science. User Interface Design, 229-256.
  • Greenberg, S., & Buxton, B. (2008). Usability evaluation with rapid prototyping. Communications of the ACM, 51(4), 60-67.

Related Assignments