Multimedia Product Specification

1
Multimedia ProductSpecification

• Dr. H Batatia

2
Introduction

• Multimedia software is created into phases
• Planning
• Specification
• Design
• Development
• Testing
• Maintenance

3
Rather WHAT then HOW

• WHAT are the user's needs
• WHAT is the current system
• WHAT are the constraints on the current and
  future systems

4
What are the steps for specification

• Requirements Analysis
• Requirements Specification

5
What to analyse?

• Domain (context)
• Work/Task/Operation to automate/support
• Users

6
Why analysis?

• understand the problem to be solved
• gather information
• Understand the users need
• Requirements analysis should provide a statement
  of the requirements of the problem, analyze the
  current situation, and state the goals of the
  system being developed.

7
What questions are asked during analysis?

• who is involved and what are their background?
• what is the current system (if there is one),
  what equipment constraints exist, and what
  functions are to be incorporated?
• when must the system be completed, and what are
  the various timelines for implementing the new
  system, pilots, and training?
• what is the anticipated impact in terms of
  personnel, training, etc.?
• why is the new system being developed?
• what are the constraints in terms of cost, etc.?

8
How do you understand the problem?

• Learn the system and its vocabulary
• observation, interviewing, reading
• Summarise data, function and decisions
• types of data, various operations

9
User analysis?

• How literate are the users?
• Vocabulary, use of text, audio, video
• What type of computer applications do they use?
• GUI
• What is their environment?
• Metaphors
• How long can they carry out the task?
• Timing...

10
What do you do with it?

• Create a requirements specification document
• Sets the scope and the functionality of the
  product
• Used during the design
• Used for testing

11
What is in the spec document?

• Title page
• Table of contents
• 1. Introduction
• 2. General description
• 3. Specific requirements
• 4. Product evolution

12
Title page

• Project-Name Requirements Specification''
• Revision number and date of revision
• Company name (course name and group name)
• Authors

13
1. Introduction

• General goals
• Definitions
• terms used unfamiliar for the designer
• term unfamiliar to computer illiterate
• acronyms
• Data dictionary
• files
• operations
• objects...

14
2. General description

• Product perspective
• Data Flow Diagram linking all entities that your
  application interacts with
• Product Functions
• functions accomplished by the application
• User Characteristics
• General Constraints
• time, space ...
• Assumptions

15
3. Specific Requirements

• A) Functional Requirements
• B) External Interface Requirements
• C) Performance Requirements
• D) Design Constraints
• E) Attributes

16
A) Functional Requirements

• List all data
• texts, images, animations, audio, video, buttons
• List all services
• presentations, search, exercise, simulations
• Use a diagram to describe the functionality of
  your application
• Use one diagram for every service
• Describe any processing required

17
B) External Interface Requirements

• User Interfaces
• Overview of the screens, metaphors
• Hardware Interface
• colour? resolution? width? Printer?
• Software Interface
• interaction with other software (if any)
• Communication Interfaces
• network requirement, protocols

18
C) Performance Requirements

• response times
• throughput (e.g. customers per day, books per
  hour, report pages per hour, ...)
• storage capacity (for files, application)

19
D) Design constraints

• List constraints (if any)
• Navigation constraints (linear, non-linear)
• Interface constraint (no colours, size and font
  ...)
• These might be dictated by the context

20
E) Attributes

• Availability
• Security
• Hardware
• Operating System
• Development tools
• Maintenance Environment

21
4. System Evolution

• What features will not be in your application?
• What are the features that might be added much
  later?
• Where should they be incorporated?

22
A Requirements Specification Document should be

• Unambiguous
• Complete
• Verifiable
• Consistent
• Modifiable
• Traceable
• Useable