Week 8 | Prototyping

Prototype

A model or first model of the intended future product. It functions as a visual example for the creators to find out how it will fare out once it is confirmed to become an actual product to be sold in the market. Bugs, problems would be easily seen by the creation of the product prototype. Stakeholders can also envision the product in its intended form and for users to be able to interact with it as realistically as possible.

Prototypes comes in different forms. Ones that do not look that similar with the intended product are low-fidelity prototypes. Mostly used during the conceptual design, it is a simple and quick way to show the general form of the product without needing to spend all the costs to use actual materials that would be used for the final thing.

High-fidelity prototypes are realistic models of the final product. It uses the actual materials that would be then later be used for the final thing and is as close to to the final product as it can be. It gives a much more accurate model that can be used to test out ideas or approaches with the future users to see how it would fare out when it is used by the intended audience.Though more costly than the low-fidelity prototype, it is helpful in finding out major problems that can be fixed before the production of the final product and in turn would help to save the company a lot of money and time from building a faulty product.

Design and Prototyping

Prototype is the smaller scale, still of bugs and haven’t properly functioned yet. It is meant for the user to interact with the envisioned product, gain experience in realistic setting and explore imagined functions. It is a helpful aid to communicate with team members. There are two types of prototyping, low-fidelity and high-fidelity.

Low fidelity prototype is the one that does not look much like the final product. It uses material that are very different from the intended final version such as paper and cardboard. It tends to be simple, cheap and quick to produce. It is important during conceptual design but not actually will be included in the final design.

High fidelity prototype on the other hand uses material that you would expect to see in the final product. It takes longer time to be build and a lot of difficulties would ensue as a software prototype can set higher expectations. However, it is useful for selling ideas and for testing out technical issues.

As a conclusion, prototype is definitely important in designing as it helps the designer to improve the product before it was officially released.

Requirements

Requirements are very important in meeting demands or expectation of user especially in designing the products. According to Wikipedia, it is a statement that identifies a necessary attribute, capability, characteristic, or quality of a system for it to have value and utility to a user. Requirements must be specific, unambiguous and clear. There are four types of product requirements; architectural, functional, non-functional and constraint.

In layman terms, requirements are what the user expected the product to be, what the product supposed to provide, what the characteristics of the product and the goal the product is supposed to enable the users to do.

Functional requirements are defining the functions and high level logic of what the product/software/website able to do. Whileas, non-functional requirements specify the criterias and attributes of the product/software/website. In general, functional describe what the product supposed to do by defining the functions while non-functional describe how the product supposed to be.

Week 7 | Requirements

Every product has requirements. It's no different in this field. 

A search on the definition of requirement on the internet will turn up as

- a nessecitate

- To call for as obligatory or appropriate

In this case, it is a statement about an intended product that specifies what it should or how it should perform. It should be specific, ambiguous and as clean as possible.

To gather a set of reliable and stable requirements, one should first set themselves to do data gathering.

Data which is sufficient, relevant and appropriate has to be collected to proceed. There are many ways such as to do this. Interviews, focus groups, creating questionnaires and various kinds of observations are just a few of the methods that can be used to collect date from potential users. They all are useful in different ways and the best ones can be custom selected to best fit the needed aim.

• Interviews -->  These are effective in getting people to explore the issues, they can be customized to be structured, semi structured or completely unstructured. 
• Focus groups --> Important in the meeting of future or current stakeholders.
• Questionnaires --> Best at gaining an agreement ad highlighting problematic areas and disagreements during the requirements activity. 

These are just some of the methods and many more can be used to their full advantage to get the most data out of the activities. These are all of course influences by other factors such as the nature of the task, participants and the available resources.

  

Requirements : ?

What is requirement? According to Wikipedia, a requirement is a singular documented physical and functional need that a particular product or service must be or perform. In other words, requirement is a statement about an intended product that specifies what it should do or how it should perform. It should be as specific, unambiguous and as clear as possible and we must know how to tell when they have been fulfilled. It is most commonly used in a formal sense in systems engineering, software engineering, or enterprise engineering. There are types of requirements; Functional Requirements and Non-Functional Requirements. Functional requirement captures the intended behavior of the system. This behavior may be expressed as services, tasks or function the system is required to perform or in a simpler way, it is what the system should do. Non-Functional requirement includes constraints and qualities. Qualities are properties or characteristics of the system that its stakeholders care about and hence will affect their degree of satisfaction with the system while a constraint is a restriction on the degree of freedom we have in providing a solution.