Software Requirements Document WinMobile Camera Driver for Rugged Industrial PDA using Omni Vision OV5640 color

CMOS image sensor <Project ID> Date

GRACE System Technology Labs (India ) Private Limited SRD Structured approach

<LOGO>

2Version: 1.0 Issue Date:

GRACE System Technology Labs (India ) Private Limited SRD Structured approach

<LOGO>

Document History

S . N 0 1 1.0 Vers ion Issue Date Change Comments Description / Issued By Approved By

3Version: 1.0 Issue Date:

GRACE System Technology Labs (India ) Private Limited SRD Structured approach

<LOGO>

Table of Content 1 Introduction 1.1 1.2 1.3 1.4 2.1 2.1.1 2.2 2.3 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10 3.11 3.12 6 6 6 6 6 8 8

Purpose Purpose References

Definitions, Acronyms and Abbreviations Functional Requirements Functionality 2 11 Functionality 3 12 14 14 Localization / Globalization Usability Reliability Performance Integration Scalability Security 15 15 16 16 16 16 16 17 17 17 4-

2 Overall Description

Functionality 1 Error! Bookmark not defined.

3 Non-Functional Requirements

Exception Handling

Infrastructure Requirements Installation Requirements Backup and Recovery 17 Documentation Requirement

Version: 1.0 Issue Date:

GRACE System Technology Labs (India ) Private Limited SRD Structured approach

<LOGO>

3.13 3.14 3.15 3.16 3.17 3.18 3.19 3.20 3.21 3.22 3.23

Licensing Requirements 17 Design Constraints Interfaces 18 19 20 17 Purchased Components 18 User Interfaces 18 Applicable Standards Acceptance Criteria Assumptions Dependencies Constraints 20 20 20

Requirements to be prototyped 20

5Version: 1.0 Issue Date:

GRACE System Technology Labs (India ) Private Limited SRD Structured approach

<LOGO>

1
1.1

INTRODUCTION
Purpose
The purpose of this document is to clearly and unambiguously specify the software services and support needed for the design and development of camera driver for a device using Omni Vision OV5640 image sensor in WinMobile.

1.2

Purpose
The objective of this project is to develop a fully functional Camera Driver for Rugged Industrial PDA using Omni Vision OV5640 color CMOS 5 megapixel image sensor. The primary consumer of the camera device driver interface is the DirectShow video capture filter.

1.3

References
OmniVision Serial Camera Control Bus Functional Specification OV5640 Preliminary Specification Microsoft windows mobile 6.5 DTK TIs Technical Reference Manual SPRUGN4MMay 2010Revised July 2011

1.4

Definitions, Acronyms and Abbreviations

Term Definition

6Version: 1.0 Issue Date:

GRACE System Technology Labs (India ) Private Limited SRD Structured approach

<LOGO>

7Version: 1.0 Issue Date:

GRACE System Technology Labs (India ) Private Limited SRD Structured approach

<LOGO>

OVERALL DESCRIPTION
The OV5640 (color) image sensor is a low voltage, high-performance, 1/4-inch 5 megapixel CMOS image sensor that provides the full functionality of a single chip 5 megapixel (2592x1944) camera using OmniBSI technology in a small footprint package. It provides full-frame, sub-sampled, windowed or arbitrarily scaled 8-bit/10-bit images in various formats via the control of the Serial Camera Control Bus (SCCB) interface

2.1

Functional Requirements

2.1.1

Camera Device Detection & Initialization

Device should be statically declared for the platform since it is an I2C device. SCCB mode initializations to be done. Camera applications should use the middleware layer provided by the DirectShow video capture infrastructure to communicate with and control the camera.

Complexity
Business Complexity Medium Business Values High Technical Complexity Medium

8Version: 1.0 Issue Date:

GRACE System Technology Labs (India ) Private Limited SRD Structured approach

<LOGO>

2.1.2

Driver Detection and Initialization

Camera Driver should be detected and initialized for every start up, as long as the camera device is present in the board At initialization time, the camera driver detects and initializes the hardware, allocates and initializes its data structures, and returns a device instance identifier that will be passed to the other entry points.

Business Complexity Medium

Business Values High

Technical Complexity Medium

2.1.3

Video and Image Capturing Capability

The camera driver architecture uses the concept of a pin as defined by the DirectShow middleware. Pins are used to transmit data in and out of a device A camera and are always in one of three states: stopped, paused, and playing.

driver can support up to three types of pins: preview, capture, still. Each pin can support a number of media formats. The DirectShow middleware manages the process matching media formats from camera output pins with pins on downstream filters. Driver should be able to handle various video controlling ioctls from camera application

9Version: 1.0 Issue Date:

GRACE System Technology Labs (India ) Private Limited SRD Structured approach

<LOGO>

Business Complexity Medium

Business Values High

Technical Complexity Medium

2.1.4

Support for Image Sensor Processor digital settings

Driver would be able to support following image settings, Picture brightness or black level Picture contrast or luma gain Satuaration Sharpness White Balance Gamma adjust

Business Complexity Medium

Business Values High

Technical Complexity Medium

Inputs <Detail the inputs for this specific functionality> Business Rule

10Version: 1.0 Issue Date:

GRACE System Technology Labs (India ) Private Limited SRD Structured approach

<LOGO>

<Describe the business events, which account for this functionality> Events Flow <The details of the events, which triggers the start and end of this functionality> Output <The desired output at the end of such an event>

2.2

Functionality 2
<Describe the functionality> Complexity <Fill this as Business Values High Critical functionality, must be in the beta release of the application Current moderate functionality Medium - Important but not immediately necessary Low - Nice to have functionality, but not extremely critical in mentioned below>

Business Complexity High - Business systems are not in place or are in place, but require significant changes Medium requires new requirements. -

Technical Complexity High many requirements, performance other applications Medium - Solution exists, yet requires customization, simple or Heavy effort, functional complex issues, development

business rules, significant business system in place changes to support the complex integration with

11Version: 1.0 Issue Date:

GRACE System Technology Labs (India ) Private Limited SRD Structured approach

<LOGO>

Business Complexity Low Supporting the particular functionality

Business Values the short-term

Technical Complexity no integration with other applications Low Easily

requirement requires no or minimal changes to the business system Inputs <Detail the inputs for this specific functionality> Business Rule <Describe the business events, which account for this functionality> Events Flow <The details of the events, which triggers the start and end of this functionality> Output <The desired output at the end of such an event> implemented, out-of-thebox functionality

2.3

Functionality 3
<Describe the functionality> Complexity <Fill this as Business Values High Critical mentioned below>

Business Complexity High - Business systems

Technical Complexity High Heavy

12Version: 1.0 Issue Date:

GRACE System Technology Labs (India ) Private Limited SRD Structured approach

<LOGO>

Business Complexity are not in place or are in place, but require significant changes Medium requires new requirements. Low Supporting the Current moderate functionality

Business Values functionality, must be in the beta release of the application Medium - Important but not immediately necessary Low - Nice to have functionality, but not extremely critical in the short-term

Technical Complexity development many requirements, performance other applications Medium - Solution exists, yet requires customization, simple or no integration with other applications Low Easily effort, functional complex issues,

business rules, significant business system in place changes to support the complex integration with

particular

functionality

requirement requires no or minimal changes to the business system implemented, out-of-thebox functionality Inputs <Detail the inputs for this specific functionality> Business Rule <Describe the business events, which account for this functionality> Events Flow <The details of the events, which triggers the start and end of this functionality> 13Version: 1.0 Issue Date:

GRACE System Technology Labs (India ) Private Limited SRD Structured approach

<LOGO>

Output <The desired output at the end of such an event>

NON-FUNCTIONAL REQUIREMENTS
<Including but not limited to following>

3.1

Localization / Globalization
< Localization / globalization requirements for the set of functionality be mentioned here>

14Version: 1.0 Issue Date:

GRACE System Technology Labs (India ) Private Limited SRD Structured approach

<LOGO>

3.2

Usability
<This section should include all of those requirements that affect usability. They may include: Required training time for users Measurable task times for typical talks; alternatively, base usability requirements of the new system on other systems that the users know and like Requirements that conform to common usability standards, such as GUI standards etc>

3.3

Reliability
<Requirements for system reliability should be specified here. They may include Availability: specify percent of time available, hours of use, maintenance access, degraded-mode operations, and so on Mean time between failures (MTBF): this is usually specified in hours but could also be specified in terms of days, months or years Mean time to repair (MTTR): How long is the system allowed to be out of operation after it has failed? Accuracy: Specify precision (resolution) and accuracy (by some known standard) that is required in the systems output Maximum bugs or defect rate: Usually expressed in terms of bugs/KLOC or bugs per function-point Bugs or defect rate: categorized in terms of minor, significant and critical bugs. The requirements(s) must define what is meant by a critical bug>

15Version: 1.0 Issue Date:

GRACE System Technology Labs (India ) Private Limited SRD Structured approach

<LOGO>

3.4

Performance
<The performance characteristics of the system should be outlined in this section, Include specific response times, where applicable, reference related features by name Response time for a transaction (average, maximum) Throughput (transactions per second) Capacity (the number of customers or transactions the system can accommodate) Degradation modes (the acceptable mode of operation when the system has been degraded) Resource utilization (memory, disk, communications)>

3.5

Integration
<Detail the integration requirements>

3.6

Scalability
< Detail any specific scalability requirements for the overall system (if desired)>

3.7

Security
<Specify any requirements regarding security or privacy issues surrounding use of the product>

3.8

Exception Handling
< Detail the exceptions handling requirements, the messages during these exceptions etc> 16Version: 1.0 Issue Date:

GRACE System Technology Labs (India ) Private Limited SRD Structured approach

<LOGO>

3.9

Infrastructure Requirements
< Infrastructure requirements to roll out this entire set of functionalities or the whole product>

3.10 Installation Requirements

< Installation requirements are specified>

3.11 Backup and Recovery

<Back up and recovery requirements are specified>

3.12 Documentation Requirement

<Documentation mandated by the customer are specified here>

3.13 Licensing Requirements

<Any licensing enforcement requirements that are to be exhibited by the software> <Any other Requirements> <Any additional requirements desired for such a product or set of functionality, set by the customer>

3.14 Design Constraints

<This section should indicate any design constraints on the system being built, design constraints represent design decisions that have been mandated and must be adhered to, 17Version: 1.0 Issue Date:

GRACE System Technology Labs (India ) Private Limited SRD Structured approach

<LOGO>

Examples include software languages, software process requirements, prescribed use of developmental tools, architectural and design constraints, purchased components, and class libraries.>

3.15 Purchased Components

<This section is optional and describes any purchased components to be used with the system, any applicable licensing or usage restriction, and any associated compatibility/interoperability or interface standards. >

3.16 Interfaces
<This section defines the interfaces that must be supported by the application, this section should contain adequate specificity, protocols, ports, and logical addresses, and so on, so that the software can be developed and verified against the interface requirements. >

3.17 User Interfaces

<Describe the user interfaces that are to be implemented by the software>

18Version: 1.0 Issue Date:

GRACE System Technology Labs (India ) Private Limited SRD Structured approach

<LOGO>

3.17.1.1 Hardware Interfaces

<Define any hardware interfaces that are to be supported by the software, including logical structure, physical addresses, and expected behaviour> System Interfaces

3.17.1.2 Software Interfaces

<Describe software interfaces to other components of the software system. These may be purchased components, components reused from another application, or components being developed for subsystems outside of the scope of this RD but with which this software application must interact. >

3.17.1.3 Communications Interfaces

<Describe any communications interfaces to other systems or devices, such as LAN or remote serial devices>

3.18 Applicable Standards

<Describe by reference any standards (and the specific sections of any such standards) that apply to the system being described. For example, this could include legal, quality, and regulatory standards, as well as industry standards for usability, interoperability, internationalization, operating system compliance, and so on. >

19Version: 1.0 Issue Date:

GRACE System Technology Labs (India ) Private Limited SRD Structured approach

<LOGO>

3.19 Acceptance Criteria

<The acceptance criteria for the requirements is mentioned here> Assumptions, Dependencies and Constraints

3.20 Assumptions
<List the assumptions here>

3.21 Dependencies
<List the dependencies here>

3.22 Constraints
<List the identified constraints here>

3.23 Requirements to be prototyped

<Optional, this section may be omitted if prototype is not being developed>

20Version: 1.0 Issue Date: