Unit Notes

ICAICT420A Develop client user interface

Topic 1 – Prepare design for interface

Page 2 of 20

ICAICT420A Develop client user interface

© Copyright, 2014 by TAFE NSW - North Coast Institute

Date last saved: 11 April 2014 by Amanda Walker Version: 1.2 # of Pages = 20

Copyright of this material is reserved to the Crown in the right of the State of New South Wales. Reproduction or transmittal in whole, or in part, other than in accordance with the provisions of the Copyright Act, is prohibited without written authority of TAFE NSW - North Coast Institute.

Disclaimer: In compiling the information contained within, and accessed through, this document ("Information") DET has used its best endeavours to ensure that the Information is correct and current at the time of publication but takes no responsibility for any error, omission or defect therein. To the extent permitted by law, DET and its employees, agents and consultants exclude all liability for any loss or damage (including indirect, special or consequential loss or damage) arising from the use of, or reliance on, the Information whether or not caused by any negligent act or omission. If any law prohibits the exclusion of such liability, DET limits its liability to the extent permitted by law, to the re-supply of the Information.

Third party sites/links disclaimer: This document may contain website contains links to third party sites. DET is not responsible for the condition or the content of those sites as they are not under DET's control. The link(s) are provided solely for your convenience and do not indicate, expressly or impliedly, any endorsement of the site(s) or the products or services provided there. You access those sites and use their products and services solely at your own risk.

Page 3 of 20

ICAICT420A Develop client user interface

Table of Contents

Getting Started with ICAICT420A Develop client user interface .................................4

1.1 Review requirements and other documentation to determine user needs ..........5

Activity 1.1 ....................................................................................................................6

Usability Engineering ....................................................................................................6

Information Gathering ...................................................................................................7

User Needs Identification ..............................................................................................8

Check Your Understanding ...........................................................................................8

1.2 Investigate system environment to determine the impact of user interface design .............................................................................................................................9

Interactive Systems Design...........................................................................................9

Activity 1.2 ....................................................................................................................9

Other Requirements for Interactive Systems Design ...................................................10

User Interface Design (UID) ........................................................................................11

Special Design Considerations for E-Commerce ........................................................11

Check Your Understanding .........................................................................................11

1.3 Review organisational goals to ensure consistency with organisational style .12

Towards Designing Interfaces Specifications in-line with Organizational Guidelines to Create Application Security .........................................................................................12

Activity 1.3 ..................................................................................................................13

1.4 Define data query and report formats for the user interface design where appropriate ...................................................................................................................14

User interface specification .........................................................................................14

Dialogue Styles ...........................................................................................................15

Activity 1.4 ..................................................................................................................15

Check Your Understanding .........................................................................................15

1.5 Document needs and findings and obtain approval for the proposed interface from the appropriate person........................................................................................16

Requirements Document ............................................................................................16

Activity 1.5 ..................................................................................................................16

Review and Sign Off ...................................................................................................17

Check Your Understanding .........................................................................................19

Answers to Activities: ..................................................................................................20

Page 4 of 20

ICAICT420A Develop client user interface

Getting Started with ICAICT420A Develop client user interface Welcome to ICAICT420A Develop client user interface. This unit describes the performance outcomes, skills and knowledge required to design and documents a client user interface that integrates with front end applications.

Reading notes

The notes for this unit (Topic 1) are in 5 parts:

Part 1: Review requirements and other documentation to determine user needs

Part 2: Investigate system environment to determine the impact of user interface design

Part 3: Review organisational goals to ensure consistency with organisational styles

Part 4: Define data query and report formats for the user interface design where appropriate

Part 5: Document needs and findings and obtain approval for the proposed interface from the appropriate person

This unit assumes that you have broad knowledge of general features and capabilities. You should be familiar with PC-based application software which uses graphical user-interfaces with pop-up menus, drop-down menus, buttons, icons and point-and-click of a mouse functionality.

Using the Unit Notes

Icons and symbols are used throughout the guide to provide quick visual references. They indicate the following:

Icon Meaning Icon Meaning

ACTIVITY: An activity is listed to be completed

ACTIVITY: A Learning activity requiring some physical action

WWW: A web link is listed REFLECTION: A point is to be considered and thought about more deeply

IMPORTANT: A pivotal point is detailed

SEARCH: A particular item / book etc needs to be found and applied

Page 5 of 20

ICAICT420A Develop client user interface

1.1 Review requirements and other documentation to determine user needs Isn’t it true that the path to quality software development starts with clearly defined requirements? With this in mind, the process of getting a software project on the go can be frustrating if the requirements are not clearly defined and documented. This can lead to potential failures if processes related to the requirements development and management aren’t ironed out and taken seriously from the beginning.

Conducting requirements analysis for requirements engineering is to determine user expectations for a new or modified product. The features (requirements) must be quantifiable, relevant and detailed as clearly as possible. In software engineering they are generally termed ‘functional specifications’. What are the key/essential functions the software is required to do? There are three levels of software requirements as per diagram below:

Figure 1

It is important to recognise that there are several types of requirements and all participants of the project (customer/client, designer-developer and other relevant stakeholders) will have different expectations of the amount of detail to be examined. You will be well advised to address then document and sign off on the following:

1. Business requirements – an organisation’s high-level objective(s) for a new product or service and how it can map itself to the world with this product.

2. User requirements – this will include the tasks that users must be able to perform with the new product. A good way to determine this is by creating use cases which depict the interaction between the user and the system. This is however not sufficient for the designer-developer. We will discuss usability and user requirements analysis shortly.

Page 6 of 20

ICAICT420A Develop client user interface

3. Functional requirements – to further assist the designer-developer to derive

specific software requirements, the functional requirements are further derived from the use case whereby it itemises the specific behaviours the software must show. Screen mock-ups can follow these (in the design phase) of course but use case modelling can be ideal to get the basics documented for review and consideration by developer and client(s).

From figure 1 above, we also see that the Software Requirements Specification (SRS) will also contain both the functional and non-functional requirements. We look at SRS again in section 1.5.

Remember, it is important to educate all particpants in the project of key requirements engineering concepts, terminology and practices. Activity 1.1 is a good exercise for learning the differences between functional and non-functional requirements.

Activity 1.1

What are some examples of non-functional requirements? Start your research by referring to the following link:

http://www.new2html.com/website-creation/17/developing-website-requirements-functional-vs-non-functional and try other resources with search terms like website requirements: functional or non-functional.

What do you remember about phases in Software Design? What does a simple interaction design model look like?

Usability Engineering

Usability generally refers to "ease of use". Aspects which can govern ease of use include:

Clarity Intuitiveness Seamlessness Elegance of an application or website interface design

This can be expressed by how easily one can use a product's controls or displays such as a tool, computer display, automobile, aircraft, etc. In computing, this term is generally associated with Human-Computer-Interaction (HCI). Usability also includes the study of methods, measurement, principles of a product's efficiency, elegance and overall usefulness.

Therefore usability is used to design with the user in mind. User comes first in the design process resulting in greater efficiency, learning time and satisfaction.

This process is known as an optimized ‘user experience’ and to achieve this, a systematic approach is used towards analyzing and implementing usability in the design process. The main objective is to make a product easy to understand, use and learn. Therefore, the outcome is a greater likelihood of user acceptance. This can be accomplished by conducting usability testing and changing the design parameters to accommodate results of this test to enable for and optimize user interface design. Reference: http://www.usernomics.com/usability.html

Page 7 of 20

ICAICT420A Develop client user interface

User Requirements Analysis

Now that you know user requirement is paramount, it is also critical to the success of interactive systems. Think about some of the benefits when a product’s requirement is well analysed and then developed responsively:

a. Increased productivity for the whole project b. Enhanced quality of work c. Reductions in support and training costs d. Improved user satisfaction

The general process of user requirements analysis is shown in figure 2, but for now we will discuss the first two - Information Gathering and User Needs as without these two key investigative stages being correct the following phases of any project can be flawed:

Figure 2

Information Gathering

This stage of developing an SRS has 3 main components; stakeholder analysis, use analysis (how it is currently and is to be used) and a task analysis.

a) Conducting a stakeholder analysis and the processes that currently take place

usually involves relevant user groups, recipients of output from the product, marketing staff, purchasers and support staff etc.

b) Conducting a use analysis identifies the key usability, accessibility, quality of the product and social acceptability factors. An example could be how an ATM will be much more usable if it is designed for use during daylight hours as well as at night time, in normal light as well as in bright sunlight and can also be used by people who may have to stand in queues as well as those using wheelchairs. Below is a sample Context of use factors table, which can serve as a questionnaire to capture the characteristics of the users, their tasks and operating environment.

Context of use factors table

Information

Gathering User Needs Identification

Envisioning and evaluation

Requirements

Specification

Page 8 of 20

ICAICT420A Develop client user interface

c) Conducting a task analysis is necessary to understand what a user is required to

do as a cognitive process or to action to achieve a task. It is advisable to conduct a detailed task analysis to comprehend the current product or new product to be designed and developed as well as the information that flows within; the issues for people and the opportunities which indicate user needs.

Reference: The above is taken from an academic paper: User requirements

analysis, a review of supporting methods by Martin Maguire and Nigel Bevan http://nigelbevan.com/papers/WCC_UserRequirements.pdf .

User Needs Identification

This can include describing the general characteristics of the users thus affecting the

specific requirements:

a) Types of users - users, operators and maintenance personnel

b) Some characteristics such as educational level, language, experience and technical expertise impose important constraints on the software

c) Frequency of user – it is important to classify the users and estimate the likely numbers in each category

d) Environmental characteristics – it is not advisable to assume that users are always in quiet private offices. Some systems, for example, may include terminals on service counters, kiosks in public places, call centres and other forms of user interface/ interactivity which can have significant impact on requirements

Check Your Understanding

I can now

❒Review requirements and other documentation to determine user needs

Page 9 of 20

ICAICT420A Develop client user interface

1.2 Investigate system environment to determine the impact of user interface design

Interactive Systems Design

A user interface is the system by which the user interacts with a machine. This interface includes hardware (physical) and software (logical) components. When preparing a user-centred design, its engineering concepts must be mapped into user abstractions, files and folders. Designers-developer’s model of an interface may be very different from that of the user. Therefore, in appreciation of the different groups of users, the distinctions between a novice and an expert clearly guide the design of the user interface.

In saying this, designers-developers need to explore the differences in a user population when developing and installing computer systems. They need to identify the effects that perception, cognition and physiology have on human performance. Sometimes, the designers-developers work has no relevance to some issues such as having no control or little over the workstation layout of their users. These will be categorised as under ‘personal control’.

1. Perception – usage of sense to detect information. Ensuring that the user can see or hear displays is important. Some principles govern this – it’s no use displaying it is people can’t see it or hear it in their normal working environment. E.g. most aircraft produce over 5 audible warnings. It is relatively easy to confuse them under stress test. The background noise can be over 100db. Ensuring that signals are redundant is good practice.

2. Cognition – this involves user’s short (STM) and long term memory (LTM). The easy way to identify is: STM has a short retention timeframe (low capacity) and LTM is vice versa. In this context, the design interface should make use of STM. As a rule of thumb, don’t expect the user to hold more than seven items of information at any one time. The aim is to reduce the load on STM.

3. Physiology – as a minimum, user must be able to view the display and reach the

input devices. Some users are capable of making fine grained selections with their mouse or a tracker-ball but this not the case for all, let alone an average user. With this aspect being looked after - workplace pressures and concentration times can be reduced thus allowing users to cope well with tasks at hand and to even work on increasing their physiological abilities for more complicated interfaces when required.

How will the access of the LTM be; slower or faster?

Activity 1.2

A common trick in user interface design is to support STM by representing additional information on the display or on index cards.

a) Give an example of this support In contrast:

b) What serves more towards searching for information and is LTM?

Page 10 of 20

ICAICT420A Develop client user interface

Other Requirements for Interactive Systems Design

It is advisable that a designer-developer understands there are many other requirements which must be elicited, analysed and validated for software products to be considered successful. It is looking beyond the presentation layer and gathering additional details that helps attain a good understanding and balanced representation of the product and satisfying stakeholders’ requirements. There are a few techniques which can assist in the ‘eliciting of, anticipating and ultimately meeting the user interface requirements’.

1. Identify data values – customers can give you scenarios for the interface to help you identify data values for each scenario. Data values can be fields which can be optional or mandatory, fields which are editable and some may have default values to save users’ time and minimising input errors. You may even need to provide selection criteria such as populating fields such as using list boxes depending on a previous field value entries or choices. Also by calculating some totals and considering some error conditions. From your previous studies or work you may already know this is data entry or field validation and is considered a standard practice for user interfaces with data input fields. Asking the correct questions and auto completing data fields will always help to make the user experience much more logical and useful to the user. (FreeMind for walking a client through the task)

2. Take a user role – identify all the different types of user roles with your

customers which the interface must support. Prepare a matrix of the varying usage across roles and what is common practice. Also, familiarise yourself if there are restrictions for each role and document these requirements with data and rules e.g. security permissions, role-specific default values on what is and what is not actionable depending on the level of authority the use has. You can test the roles with scenarios and defined data values and test drive them through the navigation and screens. Testing with a formal procedure document is essential to keep track of what it working and what needs refining.

3. Discover temporal events if any – these events are triggered with time and an

example will be ‘time it takes to generate an invoice’ or ‘time it takes to produce a student summary report’. Sometimes this can impact the design of the prototype and therefore it is wise to closely work with your customer to identify these events and to work out which are within scope for the product requirements. There will be the need to find out many detailed requirements and this can include but not limited to: data, business rules, process steps and some quality attributes such as interoperability, reliability, security, throughput and others. Ensure that you write scenarios to test these events.

4. System-to-system interfaces – sometimes, users are unaware of how system

work and do not see the processes which take place behind the scenes. Business experts can help identify which business or temporal (time based) events require data from another system or provide data to another system. Revisit the scenarios and get the big picture to understand how the events are initiated and how they end. You will probably need to incorporate the details which extend your scenario.

It is best to leverage a variety of requirements representations to model events, data and business rules.

Resource: http://sourceforge.net/projects/freemind/

Free Mind is a free and handy tool for documenting details from clients, users and stakeholders and useful for initial interviews or detailed walk throughs.

Page 11 of 20

ICAICT420A Develop client user interface

User Interface Design (UID)

This is also known as Human-Computer Interaction (HCI) and it reflects what we discussed earlier as Interactive Systems Design. Some examples of wide and extensive usage of HCI are for military aircraft, vehicles, airports, audio equipment, computer peripherals and so on.

How the user experiences the end product says it all. There is much more emphasis on User Experience (UX) today than ever before. But for now we will consider user acceptance as of paramount importance. While much focus may be toward technology, the usability specialist will focus on user interface. As a measure of efficiency and effectiveness; the product designers and user(s) need to maintain the working relationship throughout the project development to its rollout.

The optimised UID needs a systematic approach to the design process. However, to ensure optimum performance, Usability Testing is required. This form of testing allows for naïve users to provide data about what does work as anticipated and what does not work. Only after the resulting repairs are made can a product be deemed to have a user optimized interface.

If end-users feel it is not easy to learn, not easy to use, or too cumbersome, an otherwise excellent product could fail. Good User Interface Design can make a product easy to understand and use. Reference: http://www.usernomics.com/user-interface-design.html#ui

Additional Reading: http://www.nngroup.com/articles/definition-user-experience/ http://www.practicalecommerce.com/articles/3902-Understanding-User-Experience-vs-User-Interface

Special Design Considerations for E-Commerce

This is mainly concerning feedback and with some extra considerations to be discussed below; your web interface designs will have improved functionality. Some of these methods include incorporating methods for eliciting feedback on the website from e-commerce customers.

1. Launch the user’s email program with the email address of the company’s contact automatically entered into the To: field. This prevents typing errors and facilities the emailing processes.

2. Garnering feedback from customers when using e-commerce or any business websites by taking users to a page with an easy to use feedback form to enable their contribution to the site feedback. A discussion forum is very useful for this purpose also. Feedback and contact form can be used by the customers to send suggestions, comments and questions about the site to the Customer Service Team. Ensure to have ‘submit’ and ‘clear’ buttons available.

Check Your Understanding I can now

❒ Investigate system environment to determine the impact of user interface

design

Page 12 of 20

ICAICT420A Develop client user interface

1.3 Review organisational goals to ensure consistency with organisational style

Towards Designing Interfaces Specifications in-line with Organizational Guidelines to Create Application Security In designing interfaces to adhere to specifications, the awareness of allowing users to interact with systems in a secure manner is increasing.

Based on extensive research conducted, human operated computers are dependent on the information conveyed in the human interface. Therefore, in many circumstances, designers and developers know that “a system that is more secure is more controllable and thus more usable; a system that is more usable reduces confusion and is hence more likely to be (considered) secure.” Reference: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.156.9187&rep=rep1&type=pdf

Here’s an example of how this applies. Studies indicate that existing user interfaces are not suitable for the majority of users. A situation occurs were there has been a violation of an actual security policy, generally an application will provide a warning window which has text that provides information about the security problem at hand and asks the user if the critical action should be executed? What happens next?

More often than not, the text is not suited to all users as they don’t comprehend the security problem which is explained and they just click ‘ok’ as this is the way to perform the desired action. Consequently, an insecure action is allowed with the user not knowing exactly what has happened.

So how can this issue be looked after to ensure users understand what they are doing and their choice is consistent with organisational goals? The way to move forward is to have a process of guidelines generated which involves the IT and Web Development departments. These departments (along with other relevant stakeholders working on the project) will in turn produce co-ordinated prototypes and documentation manuals for the focus organisation. These guidelines will/must also cater for various user types and essentially address the various security concerns.

Achieving and Balancing Consistency in User Interface Design

Designers must achieve the principle of ‘least astonishment’ to ensure consistency in their designs. This is a simple fact that can be easily overlooked. Perception and expectation of users does need to be met, as the surprise element usually implies something bad rather than something good. In user interactions the unexpected is pretty much the same as the unwanted. From a designers perspective it can be tricky to determine which design alternative will surprise users less.

The communication between the computer and a person is termed ‘Dialogue’. A well-designed dialogue makes computer usage less frustrating and easy to use. There are three main factors which govern a good dialogue design.

1. Meaningful communication – information is presented clearly to the user. E.g.

have appropriate title for each display, providing clear user feedback. It works both ways: the computer understands what the user is entering and the user understands what the computer is presenting or requesting.

Page 13 of 20

ICAICT420A Develop client user interface

2. Minimal user interaction - a good dialogue will minimize the number of

keystrokes required. E.g. using default values for fields on entry screens. Users then can just press the enter key and proceed.

3. Standard operation and consistency – this is part of ensuring consistency with the organisational style. The system ought to be consistent throughout its set of various displays and

in mechanisms for controlling the operation of the displays throughout various

applications.

With consistency, users find it easier to learn how to use new portions of the

system once they are familiar with one component.

Examples of how to achieve consistency:

o Exiting each program by the same key or menu option.

o Locating titles, date, time, operator and feedback messages in the

same places on all displays. Computer operating systems are prime

example of this.

o Using consistent font alignment, size and colour on a web Page to

depict the organisational goals and be in line with organisational style.

Reference:

http://www.prenhall.com/behindthebook/0132240858/pdf/Kendall_Feature2_Human_Co

mputer_Interface.pdf

There is a fine line to draw when it comes to the user interface design. The design is a

compromise and tradeoff. Users want simple, clear interface, yet need powerful

functionality. As for consistency across all aspects of the interface, we have to remember

that users want their individual operations optimized as the same time. These conflicting

goals can be worked out by reviewing organisational goals which are in line with

organisational styles and adapt them as the favourite design alternative.

Reference:

http://www.uxmatters.com/mt/archives/2010/07/achieving-and-balancing-consistency-in-

user-interface-design.php

Activity 1.3 Let’s consider looking at some organisations which understand usability focus and work

on user-centered design.

Research this website:

http://www.system-concepts.com/usability/user-centred-design.html

Then in bullet form, highlight their approach to balance organisational goals while

achieving the needed consistency in user-centered design.

Check Your Understanding

I can now

❒ Review organisational goals to ensure consistency with organisational styles

Page 14 of 20

ICAICT420A Develop client user interface

1.4 Define data query and report formats for the user interface design where appropriate

User interface specification

A User interface specification (UI specification) is a document which holds the details

of the software user interface. It covers all possible actions which end users may perform in a visual way, via auditory or using any other interaction elements. It also is the main source of implementation information that specifies how the software should work. With this the UI specification(s) should also consider aspects of usability, avoid disambiguation and forward compatibility constraints.

We had a brief look at requirement specification and/or use case diagrams earlier. User interface specification details how the requirements in the requirement specification (what a product is capable of) are implemented in practice and can therefore process the product requirements into a more detailed and concise format. Of course before the user interface specification is completed or even begun in earnest, a lot of work has been carried out already for defining the application and desired functionality.

Generally the UI specification document may contain the following:

1. An overview of the overall UI metaphor (e.g. “page and folder”, “business card”) 2. Proposed UI elements such as help buttons including the icons, the styling to be

used on pull-down lists, etc. These must support the metaphor. 3. Specifications for style guides such as spacing and justification standards for

dialogues and many other interface components can be worked out here. This can include but not be limited to e.g. having 10 pixels for border, buttons below list boxes need to be 5 pixels away etc.

4. Font specifications. Here’s where the creativity and usability comes together too. 5. Screen mockups which incorporate the UI elements and that are demonstrated in

the metaphor.

The objective of the UI documentation is to ensure that sufficient information is there so that anyone reviewing the specifications would get a very clear idea of the look and feel of the application. However, it is not meant to capture every screen and every dialogue. One manner to approach this would be spell out key dialogs or those where the metaphor was particularly important.

What need to happen is that there should be several versions of the initial, candidate screen mock-ups done by the designer and be voted by team members and the customer/user and flesh the winning design out in much more detail to enable going on and build initial and subsequent prototypes.

An example of UI specification can be found at: http://www.uxmatters.com/mt/archives/2013/09/tools-for-mobile-ux-design-adobe-indesign.php and http://www.bridging-the-gap.com/how-to-create-a-user-interface-specification/

Reference: http://en.wikipedia.org/wiki/User_interface_specification

Page 15 of 20

ICAICT420A Develop client user interface

Dialogue Styles

This refers to the way in which users provide input and systems present output – over a given amount of time (very short). Designers must determine which interaction style is most appropriate in any particular context. Keep in mind that at times designers can be confined in their dialogue style choices whereby when there is the requirement for a Graphical User Interface (GUI), at times the hardware and presentation facilities provided by a user may only be capable of supporting simpler or even text-based interactions.

Say for example that the user will need to use a database to store their information and will need to retrieve this data for later use and even for report creation. How can the designer determine the suitable locations and formats to display such information?

There are generally six different types of queries:

Obtain specified data for a particular entity

Find a group of entities that have certain characteristics

Find attributes for an entity for certain characteristics

Display all the attributes for a certain entity

Find all entities with a certain characteristic

List attributes for all entities for certain characteristics

Reference: Systems Analysis and Design, Kendall and Kendall, Fifth Edition www.mgt.ncu.edu.tw/~ylchen/sasd-slide/chap18.ppt

Activity 1.4

Review this website to have an understanding of how user interface requirements can be derived from consultation process regarding online support for Sale of Goods.

http://www.w3.org/ECommerce/interface.html

Check Your Understanding

I can now

❒ Define data query and report formats for the user interface design where

appropriate

Page 16 of 20

ICAICT420A Develop client user interface

1.5 Document needs and findings and obtain approval for the proposed interface from the appropriate person

Requirements Document

This document (may also be referred to as part of or as a Software Requirements Specification (SRS)) will explain why a particular product is needed. It also places the product in context and describes what the finished product will be like. Basically, the larger part of this document is a formal list of requirements.

Requirements come from end users/ customers and at times developers and include statements of what a product should do rather than how it should do it. The ‘how’ falls under the section of ‘design’, e.g. a customer says ‘I would like a welcome screen with links to things I use regularly and I want to be able to select from a couple of different colour schemes for the welcome screen’. This will be broken into several individual requirement statements. Normally, customers have costs and scheduling issues to address.

Requirements can sometimes come from the developers and theirs might be related to product performance and other technical topics. Combining all groups’ requirements provides for a fuller description of the product.

Therefore, requirements documents usually include user, system/ product, and interface requirements (such as defined in the UI specification).

User requirements – written from the point of view of the end user; somewhat narrative as example above. System requirements – detailed specification describing the functions the system needs to do. E.g. the product will include four preset colour schemes for the welcome screen. Colours must be specified for the page background, the text, visited link etc.

Interface requirements – often expressed as screen mock-ups (there are many tools available).

The requirements document should also include the following;

Explain why the product is needed An overview of the finished product in narrative and/ or graphical mock-up form

for those who want to get a grasp of the project without reading all the requirements

Place the product in context for development e.g. describe the development tools to be used, the product budget and staffing situations and the approximate development schedule

Describe what the finished product will look like Describe details about how the finished product will be distributed or accessed All of these can be incorporated into a Software Requirement Specification or

whatever term the particular organisation prefers to use

Activity 1.5

Have a look at the sample of requirements document writing workshop http://www.cdl.edu/cdl_resources/writing-requirements

Page 17 of 20

ICAICT420A Develop client user interface

Review and Sign Off

Audience review

Assume you have completed the first draft of your requirements documentation and feel a great sense of achievement. Now it is time to put your work out there for the users to evaluate.

Who reviews the requirements documentation?

The process for the review of this documentation is generally outlined in the organisation’s user documentation policy. If you are working on a specific project, the project manager may have an approach that they prefer you to use.

Generally, documentation is reviewed by:

1. The designated project team members who have knowledge of the system, program, network and/or application

2. A subject matter expert

What is the review process?

The review process varies from organisation to organisation and project to project. The review process is generally outlined in the organisation’s policy or the project documents. It may be called something like ‘change control’. A basic process is shown in the following table:

Person Role

Technical Writer/ Designer-developer

The Technical Writer/Designer/Developers create and co-ordinate the documentation. They then manage the process of obtaining feedback from the project team and key stakeholders and changing the documentation to meet their needs. The documentation is then handed to the Project Manager once final sign off is obtained.

Project Team members

Generally, a small group of members from the project team will be designated to perform an initial review of the documentation. If changes are required, the document will be returned to the Technical Writer/Designer-developer and the review process will start again.

Business unit stakeholders

The business unit stakeholders are generally senior management who have a stake in the system, program, network and/or application you are writing the documentation for. These people are generally listed on the Project Brief, depending on the organisational policy and as senior and or operational managers - are often the decision makers on proceeding with the development or not.

Page 18 of 20

ICAICT420A Develop client user interface

What do the reviewers review?

Reviewers tend to concentrate on the content. They evaluate whether it is correct and complete. Some reviewers will also give feedback on the spelling, grammar and presentation and how they think a document could be improved.

Analysing the feedback

When the feedback is received the Technical writer/ Designer-developer will need to determine if the feedback is valid. If there are doubts, he or she will get clarification from the person requesting the change until the reason for the change is clear. Generally, changes that are requested by the reviewers are made.

Version control

When writing documentation of any kind, it is a good idea to have a version control process in place to ensure that changes are not lost and versions are not confused. This will often be outlined in the user documentation policy.

You may have a personal system that you prefer or may like to use a standard system.

Either way, it is critical to establish how you are going to name and number the various versions of your documents and to communicate that process to other writers and reviewers so that everyone is on the same page.

For example, the first draft of a user guide is called ug_draft0.1. After 2 reviews and changes it becomes ug_draft0.3. When the document has completed its final review and has been signed off, it becomes ug_version1.

Documentation sign off

Once the documentation has been reviewed and all of the reviewers are happy with it, you can send it to the relevant people for sign off.

Who signs off?

The project brief or other document that initiates the system, program, network and/or application development or upgrade will generally list the project and business unit stakeholders who are responsible for sign off on all of the deliverables, including documentation.

These people will include the:

Project owner

Business unit managers where the system, program, network or application is

being implemented

Project manager

Other key stakeholders in support roles such as trainers, human resource officers

and change managers

Page 19 of 20

ICAICT420A Develop client user interface

The sign off process

This process involves passing the reviewed documentation to each of the key stakeholders who have the responsibility for signing-off on the documentation.

Generally, there will not be any further changes requested as the key stakeholders will rely on the reviewers to identify any necessary changes. However, if further changes are requested by the key stakeholders, the changes are made and the review and sign off process starts again.

Check Your Understanding

I can now

❒ Document needs and findings and obtain approval for the proposed interface

from the appropriate person

Page 20 of 20

ICAICT420A Develop client user interface

Answers to Activities:

Activity Suggested Guidance

1.1 1. “Non-functional requirements can include things like response time and reliability. It can also be closely tied to user satisfaction.”

2. The web application shall be easy to use by all employees including sales representatives and managers

3. The web application shall be available in several languages 4. The web application shall allow several sales to be made at the

same time without downgrading performance 5. Quality attributes – usability, efficiency, portability and

maintainability 6. Performance objectives, business rules, design and

implementation constraint, and external interface requirements.

1.2 This is what a menu does. It provides fast access to a list of items or commands that do not have to be memorized by STM. Help facilities are LTM as you need to load them and search to find what you’re looking for.

1.3

Each organisation’s business goals, current marketing as well as matching current priorities are mapped to user design processes to ensure:

- Users experience organisation’s service vision such as being the most secure, the fastest and perhaps with clear, achievable goals

- Analyse skills and/ or product changes which are to meet user experience goals

- Developing a gap analysis and so on.

1.4 Research and learning - example UI requirements

1.5 Research and learning - requirements document writing workshop