際際滷

際際滷Share a Scribd company logo

Lecture 10

Download as PPTX, PDF
Rana Ali
Rana Ali

The document discusses user interface specifications in software requirement documents. It notes debates around whether interface details belong in requirements or design. Poor interface design can cause user errors and dissatisfaction. Interfaces can distract from business needs by focusing on solution details rather than requirements. Frequent interface changes also require reworking requirements. Examples then demonstrate interface prototypes for a component deletion use case to help clarify requirements. Prototyping is suggested to help capture user vision and feedback to better define requirements when needs are uncertain.

1 of 22
Download to read offline
Lecture 10
User Interface Specification Adding user interface details in the Software Requirement Specification (SRS) is controversial. The opponents of this argue that by adding GUI details to the SRS document, focus shifts from Requirement to Design GUI is definitely part of the solution. On the other hand many people think that, it is still what not how and hence it should be made part of the SRS document. By adding the GUIs in the FS, requirements can be solidified with respect to scenario contents.
System users often judge a system by its interface rather than its functionality A poorly designed interface can cause a user to make catastrophic errors Poor user interface design is the reason why so many software systems are never used Motivation for GUI
UIs distract from business process understanding (what) to interfacing details (how) Unstable requirements cause frequent modifications in UIs An extra work to be done at the requirement level each time a GUI change has to be incorporated Difficulties of using GUIs
The following GUI implements the delete component use case that we discussed in use case section. The GUI displays a drop down list box that contains a list of component types. The top of the list entry is None where the user can click on the arrow and select the component type whose component he wants to delete. Example
Example
The next GUI implements the scenario when user has clicked over the arrow and a few component types are populated in the list. User then selects a component type Plan Type. Corresponding plans are populated and displayed in the list box at the right side of the GUI. Example
Example
The user then selects Plan 2 and deletes it. System confirms the user and upon confirmation, deletes Plan 2. Example
Example
After deleting Plan 2, it displays the message that Plan 2 has been permanently deleted. Whereas, Plan 2 is still visible in the list. Example
Example
Example
Following GUI depicts the scenario when user selects a particular plan Plan 3 and clicks on the Delete button. Now assume that Plan 3 is currently being used. So, the application displays a dialog box to the user informing him that he cannot deletes this plan as it is in use. Example
Example
The next GUI, another dialog box is shown in which user is getting another message from the system. It says that Plan 3 is not in his hierarchy. Example
Example
Example
However, it should be noted that, all the above GUIs presented two major mistakes about the GUIs. First, if a plan is currently in use, it should not have been displayed in the list at the right. Secondly, instead of displaying two messages separately in two dialog boxes, it would have been appropriate to combine them in one message. The following GUI displays what this GUI should have displayed ideally. As, user can only delete plans 1 and 2, therefore, only these plans should have displayed to him. Example
Example
In the above example, it is evident that if requirements are partially generated a number of changes have to be made and sometimes the frequency of these changes rise so much that it takes all of the requirements and design time just in finalizing GUIs. Example
Prototyping is yet another technique that can be used to reduce customer dissatisfaction at the requirement stage. The idea is to capture users vision of the product and get early feedback from user to ensure that the development team understands requirements. This is used when there is uncertainty regarding requirements. Sometimes, even the customer does not know what he/she actually needs. This happens when there is no manual solution. A prototype is not the real product. It is rather just a real looking mock-up of what would be eventually delivered and might not do anything useful. However, the presence of a prototype makes a new product tangible. It brings use cases to life and closes gaps in your understanding of the requirements. From a users perspective, it is easier to play with a prototype and try it out than to read SRS. Prototyping

More Related Content

Lecture 10

  • 2. User Interface Specification Adding user interface details in the Software Requirement Specification (SRS) is controversial. The opponents of this argue that by adding GUI details to the SRS document, focus shifts from Requirement to Design GUI is definitely part of the solution. On the other hand many people think that, it is still what not how and hence it should be made part of the SRS document. By adding the GUIs in the FS, requirements can be solidified with respect to scenario contents.
  • 3. System users often judge a system by its interface rather than its functionality A poorly designed interface can cause a user to make catastrophic errors Poor user interface design is the reason why so many software systems are never used Motivation for GUI
  • 4. UIs distract from business process understanding (what) to interfacing details (how) Unstable requirements cause frequent modifications in UIs An extra work to be done at the requirement level each time a GUI change has to be incorporated Difficulties of using GUIs
  • 5. The following GUI implements the delete component use case that we discussed in use case section. The GUI displays a drop down list box that contains a list of component types. The top of the list entry is None where the user can click on the arrow and select the component type whose component he wants to delete. Example
  • 7. The next GUI implements the scenario when user has clicked over the arrow and a few component types are populated in the list. User then selects a component type Plan Type. Corresponding plans are populated and displayed in the list box at the right side of the GUI. Example
  • 9. The user then selects Plan 2 and deletes it. System confirms the user and upon confirmation, deletes Plan 2. Example
  • 11. After deleting Plan 2, it displays the message that Plan 2 has been permanently deleted. Whereas, Plan 2 is still visible in the list. Example
  • 14. Following GUI depicts the scenario when user selects a particular plan Plan 3 and clicks on the Delete button. Now assume that Plan 3 is currently being used. So, the application displays a dialog box to the user informing him that he cannot deletes this plan as it is in use. Example
  • 16. The next GUI, another dialog box is shown in which user is getting another message from the system. It says that Plan 3 is not in his hierarchy. Example
  • 19. However, it should be noted that, all the above GUIs presented two major mistakes about the GUIs. First, if a plan is currently in use, it should not have been displayed in the list at the right. Secondly, instead of displaying two messages separately in two dialog boxes, it would have been appropriate to combine them in one message. The following GUI displays what this GUI should have displayed ideally. As, user can only delete plans 1 and 2, therefore, only these plans should have displayed to him. Example
  • 21. In the above example, it is evident that if requirements are partially generated a number of changes have to be made and sometimes the frequency of these changes rise so much that it takes all of the requirements and design time just in finalizing GUIs. Example
  • 22. Prototyping is yet another technique that can be used to reduce customer dissatisfaction at the requirement stage. The idea is to capture users vision of the product and get early feedback from user to ensure that the development team understands requirements. This is used when there is uncertainty regarding requirements. Sometimes, even the customer does not know what he/she actually needs. This happens when there is no manual solution. A prototype is not the real product. It is rather just a real looking mock-up of what would be eventually delivered and might not do anything useful. However, the presence of a prototype makes a new product tangible. It brings use cases to life and closes gaps in your understanding of the requirements. From a users perspective, it is easier to play with a prototype and try it out than to read SRS. Prototyping