Business Analyst Community & Resources | Modern Analyst

Interview Questions for Business Analysts and Systems Analysts

Recent Interview Questions | Search | Subscribe (RSS)

INTERVIEW QUESTION:

What is the difference between horizontal and vertical prototyping?

Posted by Chris Adams

// 67166 Views // 1 Additional Answers & Comments

Categories: Business Analysis, Systems Analysis, Agile Methods, Requirements Analysis (BABOK KA), Elicitation (BABOK KA)

ANSWER

Horizontal and vertical prototypes are sometimes used during the analysis and design phases of application development. They are useful for requirements elaboration and visualization, but can present some pitfalls. As long as analysts and teams are aware of the pitfalls to avoid, the pros of using prototypes generally far outweigh the cons. The type of prototype that should be used (horizontal prototype versus vertical prototype) depends on the specific goals of the team and the stage within the analysis and design process.

Horizontal Prototypes

Horizontal prototypes are most often used during the early stages of analysis. They give a broad view of the application including sample screens, menus, buttons, pop-ups and sample reports that reflect the current requirements. While the screens are superficially interactive, buttons and features will have little or no processing behind them. The may navigate a user to another screen, give and alert, or show a sample report with dummy data, but the internal functions are not fully implemented.

Horizontal prototypes reflect the breadth of the system without drilling down into too much detail. They are helpful for understanding the range of abilities across a system and how feature sets will be brought together. They are useful for presenting ideas to stakeholders, facilitating requirements discussions, and gaining buy-in on requirements and design decisions.

Vertical prototype

Vertical prototypes are used in the later stages of analysis and design to drill down and elaborate on specific features or functions. Vertical prototypes are more technical in nature, connect to databases with real data, interface with existing sub-systems, and reflect the nearly-exact functioning of key features. They are most appropriate when complex features of a system are poorly-understood and are useful in demonstrating that a requirement or set of requirements is technically feasible. Vertical prototypes do not attempt to detail out the entire breath of the application, but focus on implementing a specific feature or feature set in a more complete manner. They demonstrate to the stakeholders that the application works although it might not be fully tuned.

While vertical prototypes provide a greater level of detail and functionality, there are some key items that are usually omitted such as the ability to fully edit data, security features, audit trails, and exception handling.

Prototype Evolution

Horizontal and Vertical prototypes do not have to be mutually exclusive. As analysis continues into its latter stages key features of a horizontal prototype are often fleshed out in more detail to reflect the feasibility of more complex functionality transforming it into a vertical prototype.

Prototype Considerations

If a team decides to use prototyping to support the analysis and design process there are a few key things to keep in mind. First, it's needs to be clearly communicated to all stakeholders that the prototype facilitates and compliments requirements elicitation, requirements elaboration, and application design. It should never replace the documentation of requirements. Emphasize to the team that the final application may not look exactly like the prototype. Still, a good prototype can save a lot time and money during analysis and design if created rapidly through an iterative and evolving process. Additionally, the team should be mindful that most design decisions that are incorporated early on in a prototype are made quickly and without much effort given to whether it is being implemented in the best way. This means that prototypes (especially early versions) often show design decisions that are arbitrary and not supported by any specific requirement. Any design decisions reflected in a prototype that are reviewed and ratified by the team should be documented separately in a requirements specification document.

The team should also decide from the start whether the prototype is purely for requirements visualization and elaboration (and therefore should be "throw away") or whether the prototype will be evolved into the final product. Additional risk arises if evolving the prototype into the final product, as early prototype design decisions may filter through to the final application without being properly analyzed and vetted by the analysis and design teams.

Chris Adams
LinkedIn Profile

RATE THIS TOPIC

12345

ADDITIONAL ANSWERS / COMMENTS

hauser posted on Wednesday, June 29, 2022 12:57 PM

well said. we had a major breakdown in the middle of the project because we only relied on some early prototype to come up with an app. the requirements were not clear and the process halted at some point, when the developers were lost at what had to be done next.

Only registered users may post comments.

Do your homework prior to the business analysis interview!

Having an idea of the type of questions you might be asked during a business analyst interview will not only give you confidence but it will also help you to formulate your thoughts and to be better prepared to answer the interview questions you might get during the interview for a business analyst position. Of course, just memorizing a list of business analyst interview questions will not make you a great business analyst but it might just help you get that next job.