You are on page 1of 33

Software Engineering

GUI and Prototype

Graphical User Interface (GUI) Specification

Controversial Issue
– Those in favor say
• GUIs should be part of the SRS document

– Those against it say
• GUI is part of the solution domain, not the problem domain

Why should GUI be part of SRS?

Clients / users
• Verify if requirements are properly captured in SRS

Design / Implementation team
• Design and implement system based on requirements written in the SRS

Testing team
• Design test plan and test cases to validate end product

Documentation team
• Document user manuals

SRS is a baseline for all software development activities

. Experience says that client appreciates it if GUIS are made part of the SRS document. requirements can be solidified with respect to scenario contents.   Such an SRS will be used as baseline for: – Project planning and cost estimation – Other software development activities  Presence of UI details imply that these activities can start right after SRS has been accepted and signed off by the client.Why should GUI be part of SRS?.  By adding the GUIs in the FS.. .

Why should GUI not be part of SRS?  Focus shift: from WHAT to HOW  Increase in effort: requirements change and for each change GUIs also have to be changed  GUIs are considered as substitute of requirements in the SRS: user requirements are ignored .

So what to do?  We should ensure that: – Requirement specifications are not substituted by GUIs – GUIs are added in the SRS only when the requirements are relatively stable – The focus of SRS remains WHAT instead of HOW .

Importance of User Interfaces…  Exploring potential user interfaces can be of help in refining the requirements and making the user-system interaction more tangible to both the user and the developer. .  A user interface might highlight weaknesses in addressing some of the non-functional requirements (such as usability). which are otherwise very hard to fix later on.

The use case ends. 3. The user selects the set of information to delete and directs the system to delete the information. The system responds by asking the user to confirm deleting the information. 6. 5. 4.GUI specification for a “Delete” Use Case example  Normal course of events 1. The use case starts when the user wants to delete an entire set of information from the system 2. A system responds by deleting the information and notifying the user that the information was deleted from the system. . The user confirms deletion.

e.GUI specification for a “Delete” Use Case example…  Alternate path – The user does not confirm deletion  Exceptions /alerts – The system will not allow a user to delete information that is being used in the system – The system will not allow a user to delete information that is not accessible to him or is not in his hierarchy (i.. a team lead can only delete documents of his/her team members. and not of the project manager) .

GUI Specs: Normal Course of Events .




Can you think of a better. easier way to handle the normal scenarios? .

GUI Specs: Alternate Paths .


easier way to handle the alternate scenarios? .Can you think of a better.

operability and understandability In the previous example. the two exception conditions could be handled in a different way to increase usability – Only those components or objects should be displayed to the user which come under his/her hierarchy and are not being used elsewhere Usability issues are highlighted and addressed at an early stage by using GUI specifications in the SRS .Usability   Degree to which software is easy to use. learnability.g. E.

We must remember that these are supplementary information and cannot replace other components of the SRS document. requirement development takes a longer time.Be Careful !!      We need to be very careful when we use GUIs in the SRS document. this can mean a lot of rework! . Any change in the requirements entails a change in the user interface. If you cannot freeze the SRS until UI is complete. It is a very common mistake to use UI layouts as substitutes for defining the functional requirements. if the requirements are not stable.

Prototyping .

unclear and ambiguous Requirements usually change during development process Current requirements remain only partially understood until users actually use the system – they may change the requirements if they don’t get what they wanted – Results in wasted effort on your part . uncertain.The problem    Requirements are often poorly understood.

uncertain ideas. we use prototyping .Why does this problem occur?  Because many a times users or customers only have a vague idea or a vision of what they want  The ideas are not concrete and are difficult to capture  To capture the requirements for such vague.

of a system so that customers. users or developers can LEARN more about a problem or a solution to that problem . MOCK-UP. What is Prototyping? A technique of constructing a partial implementation.So.

More about Prototypes   Prototypes are mockups of the real application. They are NOT real systems They show: – The type of application we will develop – The services it will perform   Users provide feedback after using the prototypes This helps in clear understanding of user requirements and will help in making the actual application .

When do we prototype?  When we want to implement an application using a new technology When we want to clarify requirements for the system we want to develop for our users or customers  .

Primary Schools of Thought  Throw-away Prototyping – The concept is to construct a prototype in order to learn more about the requirements and discard it after the desired knowledge is gained  Evolutionary Prototyping – The concept is to evolve the initial prototype until it becomes the real system. .

Throw-away Prototyping  A quick and dirty throw-away prototype can be constructed and given to the customer or user in order to: – Determine the feasibility of a requirement – Validate if a particular function is really necessary – Uncover missing requirements – Clarify ambiguities and conflicts .

Why should it be quick?  Because we want to understand or learn requirements  There is no use spending time developing a partially understood system  If you want to understand unclear requirements. the more value you will gain and the resulting final system would be agreeable to the user developed on a set of clear and unambiguous requirements . you must make the prototype quickly  The quicker you do it.

Why should it be dirty?  Because there is not justification of bringing in quality into a product that will be discarded .

you will end up making an unstable system. If you try to build the real system on your quick-and-dirty prototype.Why should it be thrown away?  Because its advantages exist only if results from its use are available in a timely fashion. Therefore.  . it must be thrown away.

What are the quick-and-dirty characteristics?  No design  No comments  No test plans  No proper documentation  Use of unmaintainable implementation language that facilitate fast synthesis of programs. .

How to make quick-and-dirty throwaway prototypes?  Write a preliminary SRS  Implement the prototype based on those early requirements using dirty characteristics  Achieve user experience and feedback  Extract the required knowledge  Throw away the prototype  Write the real SRS  Develop the real product .

Prototyping Risks  High client/user expectations – System is almost complete – Prototype has excellent performance (GUI and dummy data) Educate the client/user about the throw-away nature of the mock-up system .