1

SOFTWARE REQUIREMENTS ENGINEERING

LECTURE # 11

TEAM SKILL 2: UNDERSTANDING USER AND

STAKEHOLDER NEEDS
REQUIREMENT ELICITATION TECHNIQUES-IV
 Instructor Information
2

 Course Instructor: Engr. Ali Javed

Assistant Professor
Department of Software Engineering
U.E.T Taxila
 Email: ali.javed@uettaxila.edu.pk
 Website: http://web.uettaxila.edu.pk/uet/UETsub/perSites/mySite.asp?frmEmail=ali.javed@uettaxila.edu.pk
 Contact No: +92-51-9047747
 Office hours:
 Monday, 09:00 - 11:00, Office # 7 S.E.D

 Lab Instructor: Engr. Asra, Engr. Sobia

 Presentation Outline
3

 Prototyping
 Why Prototyping in General
 Uses of Prototyping
 The Prototyping Process

 Types of Prototyping
 Throwaway
 Evolutionary
 Horizontal
 Vertical
 User Interface
 Objectives of Throwaway & Evolutionary Prototyping
 Low Fidelity Prototype
 High Fidelity Prototype
 Wizard of OZ Prototyping
 Requirements Prototype

 What to Prototype

 Building the Prototype


Results Evaluation of Prototype

 Requirements Re-use
4 Requirements Elicitation Techniques
 Interviews
 Questionnaires
 Background Reading
 Introspection
 Social Analysis
 Requirements Workshops
 Brainstorming and Idea Reduction
 Story Boarding
 Role Playing
 Prototyping
 Requirements Reuse
 Prototyping
5

 Prototyping is the rapid development of a

system demonstrating a portion of the
functionality of the new system

 A prototype is an initial version of a system

used to demonstrate concepts, elicits
requirements and try out design options.

 A prototype can be::

 a storyboard, i.e. a cartoon-like series of
scenes
 a video simulating the use of a system
 a piece of software with limited functionality
written in the target language or in another
language
 Why Prototype in General?
6

 Evaluation and feedback process can be achieved successfully

 Developers can test feasibility of ideas with team, users
 Stakeholders can see and interact with a prototype more easily than a document
 Team members and users can communicate effectively
 To validate existing / other requirements
 Prototypes answer questions, and support designers in choosing between alternatives
 Uses of Prototyping
7

 The principal use is to help customers and developers understand the requirements
for the system
 Requirements elicitation. Users can experiment with a prototype to see how the system
supports their work
 Requirements validation. The prototype can reveal errors and omissions in the requirements

 Prototyping can be used in situations where the users are unable to express their
requirements

 The prototype may be used for user training before a final system is delivered

 The prototype may be used for back-to-back testing

 The Prototyping Process
8
 Types of Prototypes
9

 Prototypes can be categorized in many ways::

 Throwaway VS Evolutionary
 Vertical VS Horizontal
 User Interface VS Algorithmic

 The type of Prototype chosen depends on the problem to be solved

 For example, if your project risk is based primarily on the feasibility of the
technology approach- its simply never have been done this way before and you
are uncertain whether the applicable technology can achieve the performance
or throughput goals- you may wish to develop an architectural prototype that
primarily demonstrates the feasibility of the technology to be used
 Throwaway Prototyping
10

 Throwaway implies that the purpose of the effort is only to establish feasibility and
you will use whatever shortcuts, alternative technologies, or whatever to achieve
your goals
 When you built prototype then simply throwaway the result, keeping only the
knowledge learned in the exercise
 The system is then developed using some other development process
 The throw-away prototype should NOT be considered as a final system
 Throwaway Prototyping
11
 Evolutionary Prototyping
12

 An approach to system development where an initial prototype is produced and refined

through a number of stages to the final system
 Evolutionary implies that you have implemented the prototype on the same architecture as you
intend to use in the final system and will be able to build the final system by evolving the
prototype
 Techniques for rapid system development are used such as CASE tools
 User interfaces are usually developed using a GUI development toolkit
 Objectives of Throwaway & Evolutionary
Prototyping
13

 The objective of throw-away

prototyping is to validate or derive
the system requirements.
The prototyping process starts
with those requirements
are poorly understood
which

 The objective of evolutionary

prototyping is to deliver a working
system to end-users. The development
starts with those requirements which
are best understood.
 Horizontal Prototyping
14

 Horizontal implies that we will attempt to construct the wide range of the system’s
requirements

 Horizontal Prototyping keeps the features but eliminates the depth of functionality

 For example we are developing a prototype of a system which includes 40

different features with each feature consists of several functionalities if we built
prototype with covering all these features but not the detailed functionalities of
these features then it means we built horizontal prototype
 Vertical Prototyping
15

 Vertical prototype constructs just a few requirements but does so in a quality

manner

 Vertical Prototyping gives full functionality for a few features

 For example we are developing a prototype of a system which includes 40

different features with each feature consists of several functionalities if we built
prototype with covering some of these features but with the detailed functionalities
of these features then it means we built vertical prototype
 Horizontal VS Vertical Prototyping
16
 User Interface Prototyping
17

 User Interface implies that we will be constructing mostly the system’s

interface to its users rather than implementing the logic and algorithms that
reside within the software

 It is impossible to pre-specify the look and feel of a user interface in

an effective way. prototyping is essential

 UI development consumes an increasing part of overall system development costs

 Prototyping may use very high level languages such as Smalltalk or Java or may
include prolog and lisp mostly used in artificial intelligence

 User interface generators may be used to “draw” the interface and mimic its
functionality
 User Interface Prototyping
18

 The aim is to highlight strengths and weaknesses of the interface usability and
aesthetics.
 In a GUI application, it would be expected that this form of prototyping
would include detailed icons, fonts, color scheme, interaction styles (e.g. single click,
double click, rollover, short-cuts), use of audio (e.g. click sounds, warning sounds, etc).
 The outcome of interface prototyping may highlight potential weaknesses, such as:
 lack of short-cuts for expert users
 awkward/confusing features (e.g. icon doesn't relate well to the function)

 features that are poorly designed

 inconsistencies in design across screens
 Low-fidelity Prototyping
19

 Uses a medium which is unlike the final medium, e.g. paper,

cardboard
 Is quick, cheap and easily changed
 Examples:
 sketches of screens, task sequences, etc
 “Post-it” notes
 storyboards
 High-fidelity Prototyping
20

 Uses materials that you would expect to be in the final product.

 Prototype looks more like the final system than a low-fidelity version.
 For a high-fidelity software prototype common environments include Macromedia Director,
Visual Basic, and Smalltalk.
 Danger that users think they have a full system but all prototypes involve compromises
 Two common types of compromise are::
 “horizontal‟: provide a wide range of functions, but with little detail
 “vertical‟: provide a lot of detail for only a few functions
 Wizard of Oz Prototyping
21

 The user thinks they are interacting with a computer, but a developer is
responding to output rather than the system.

 Usually done early in design to understand users’ expectations

 What is ‘wrong’ with this approach?

 Requirements Prototypes
22

 Requirements Prototype can be defined as, “A partial

implementation of a software system, built to help developers, users and
customers better understand the requirements of the system”

 We can chose a combination of any of the prototypes discussed so far

 For the purposes of requirements elicitation, we may often chose to build a

“throwaway, horizontal, user interface” prototype

 As an elicitation tool such a prototype can serves its role in number of ways:
 Built by the developer, it can be used to obtain customer confirmation that the developer
understands the requirements
 Built by the developer, it can be used as a facilitator to encourage the customer
of yet more requirements
 What to Prototype?
23

 How do we know what portion of the system we need to

prototype?
 In a typical situation, our understanding of the user’s needs will range from well
understood and easy to verbalize to totally unknown

 Well understood requirements are those requirements which might be obvious from the context
of the application domain and the user’s and team’s experience with systems of that type
 For example if we are simply extending an existing system, it’s clear what most of the new functionality
needs to be

 The well understood and well known requirements need not to be prototyped unless they are
necessary to help visualize the context of other user needs; building them will consume scarce
resources, but since they are already well understood, little will be learned from seeing them
 What to Prototype?
24

 The unknown requirements, however are the “undiscovered ruins” that we are going to
wish we knew later

 Unfortunately we cannot really prototype those either, for if we could, they would not be
unknown

 That leaves us as the target for prototyping the “fuzzy” part in the middle

 These Fuzzy requirements are those that may be known, but they are poorly defined
and poorly understood
 Building the Prototype
25

 The choice of language/technology in building the prototype depends on the following:

 What is the application domain of the problem?
 What user interaction is required?
 Are you following throwaway or evolutionary approach?
 Different parts of the system may be programmed in different languages.

 For example, the choice for a throwaway GUI prototype is driven simply by whatever
technology provides the fastest, cheapest way to implement the sample GUI‟s
 If an evolutionary prototype is selected, you must choose the implementation language and
development environment that you will use in the production device
 Result Evaluation
26

 After the prototype is built, it should be exercised by

its users in an environment that mimics as closely as
possible the production environment in which the final
system will be used

 Also it will be important to have various types of user

exercise the device or the results may be biased
 Result Evaluation
27

 The results of prototype may be two fold:

 Fuzzy needs become better understood
 Exercising the prototype elicits a “Yes-But” response from the user; therefore previously
unknown needs become known
 In any case the prototyping always produces results
 The trick is making sure that the return in requirements knowledge gained is worth
the investment made
 Requirements Reuse
28

 In the field of software engineering reusing the requirements of the existing system
is the common method of requirement elicitation

 Using the existing knowledge to develop the new product has many advantages
including low cost and less time
 Requirements Reuse
29

 Through each product has their own types of stakeholders and users, there is still number of
situations that the reuse of requirements takes place e.g.
 User interface design of the application domain information

 Now a days in software industries the more than half of the requirements for the new project
requirements are acquired from the existing projects

 Although there is need to check the requirements before they are used in the proposed
product, the reuse requirements are already validated and analyzed thus reducing the time
for testing
 Requirements Reuse
30

 The various questions that helps us to find the reusable requirements are::
 What are the problems in the existing product?
 What the proposed product should provide to overcome the difficulties in the existing
product?
 Who are the users and stakeholders of the existing and proposed products?

 It is difficult to say the proposed product is completely different from the existing
product because it is easy to find reused requirements in any project requirement
specification

 Finding and using the reusable requirements for the projects is the best way for
Requirements Elicitation
 For any query Feel Free to ask
31