Application Designing-Requirements to Prototypes
Application design is one of the most critical part of software design..it it’s right the road ahead is a cakewalk…if not…Nightmare begins.
Here I am starting a series of posts that will explore the application design processes and tools in detail.
Prior to application design, Requirement gathering constitutes the basic framework on which design is built. The requirements need to be analyzed from 4 perspectives to make valid requirements docs. The figure below sums up these perspectives
Here QoS is Quality of Service that also needs to be considered.
Use cases also are a means of defining the requirements and sometimes serve as the main basis for application design; however there are some basic differences.
Use Cases versus Requirements
A use case is a Unified Modeling Language (UML) model meant to describe a set of user steps that accomplish a task.
Requirements define what must be created to satisfy the needs of the user. Together, they provide a good view of how the user sees the system.
One the requirements are finalized, the Prototype validates the requirements that can be a POC or Mockups.
Mockups and Proof-of-Concept Prototypes
A mockup is meant to verify the requirements and use cases through the creation of a number of key screens in the system. Mockups are also called horizontal prototypes because they take a single, horizontal picture of the application. They do not go deeply (or vertically) into the other layers of the application such as the business objects and the database layers. Mockups are a great way to determine whether the requirements are complete and understood. They also help validate the use cases, the navigational structure, and some of the logical interactions of the application.
Mockups shortcomings
They do not help to prove any of the architecture concepts for the system. They also do not validate the technology decisions.
Mockups Advantages:
Mockups are useful for defining how the application will look and behave. This removes ambiguity from the implementation and builds early consensus on what will be delivered.
A proof-of-concept prototype is meant to validate the requirements and confirm the technology recommendations and high-level design. A proof-of-concept prototype is also called a vertical prototypebecause it looks at the application across the entire stack (UI, services, business objects, and database). Proof-of-concept prototypes have also been called reference architectures because they provide a reference for the development team on just how the system should work from top to bottom. This removes ambiguity, creates a standard, and eliminates a lot of risk.
Proof-of-concept prototype is generally, created by choosing a key requirement of the application and then building it out through each layer of the design. It makes more sense to prove out a riskier requirement than to work with a well-known requirement.
After going through the above exercises, the main work of design begins, as summarized below.
As the above figure depicts the first design phase is to develop Logical Model. All these designing phases make use of certain diagramming techniques ranging from ORM diagrams to Sequence and collaboration Diagrams.
These Diagrams will be covered in next post, which will explain all the used diagrams in detail.
Hope this was helpful..
Till Next we Connect….
Happy Learning.
