Project Name: Requirements Document (version 1.

0)
To use this template: 1. Replace any red italicized text with your own text. You may remove or add sections as needed for your particular projects. 2. Enter the project name in the title and footer and chan!e the document version num"er# if necessary$. %. &f your document is very lon!# "rea' each num"ered chapter into its own document section# "e!innin! it on a new pa!e. This will ma'e it easier to replace(upda!te ). *elete these instructions and any other italicized instructions. Project: Date(s): Prepared by: Document status: __ Draft __ Proposed __ Va idated __ !pproved

1. Introduction
"#is document contains t#e system requirements for project name. "#ese requirements #ave been derived from severa sources$ inc udin% brief listing of most important sources.

1.1 Purpose of This Document

"#is document is intended to %uide deve opment of project name. &t 'i %o t#rou%# severa sta%es durin% t#e course of t#e project: 1. Draft: "#e first version$ or draft version$ is compi ed after requirements #ave been discovered$ recorded$ c assified$ and prioriti(ed. ). Proposed: "#e draft document is t#en proposed as a potentia requirements specification for t#e project. "#e proposed document s#ou d be revie'ed by severa parties$ '#o may comment on any requirements and any priorities$ eit#er to a%ree$ to disa%ree$ or to identify missin% requirements. Readers inc ude end*users$ deve opers$ project mana%ers$ and any ot#er sta+e#o ders. "#e document may be amended and reproposed severa times before movin% to t#e ne,t sta%e. -. Validated: .nce t#e various sta+e#o ders #ave a%reed to t#e requirements in t#e document$ it is considered va idated. /. Approved: "#e va idated document is accepted by representatives of eac# party of sta+e#o ders as an appropriate statement of requirements for t#e project. "#e deve opers t#en use t#e requirements document as a %uide to imp ementation and to c#ec+ t#e pro%ress of t#e project as it deve ops.

1.2 How to Use This Document

0e e,pect t#at t#is document 'i be used by peop e 'it# different s+i sets. "#is section e,p ains '#ic# parts of t#is document s#ou d be revie'ed by various types of readers. T pes of !eader &n this section# list the different types of reader this document is aimed at. +or example# +lash pro!rammers# !raphic desi!ners# end,users# project mana!ers# etc. +or each type of reader# clearly state which sections are most pertinent to them# and which may "e safely s'ipped. Technical "ac#$round !e%uired *escri"e here the technical "ac'!round needed to understand the document in !eneral# and any particular expertise or understandin! that is needed for specific sections. &verview 'ections -ist here the sections that should "e read "y someone who only wishes to !ain an overall understandin! of the project# or which should "e read first "efore technical re.uirements are reviewed.

Project 1ame: Requirements Document (version 1.0)

!eader('pecific 'ections &n this section# name any parts of the document which are intended only for one or another of the reader types identified a"ove# and which may therefore "e s'ipped "y other readers. 'ection &rder Dependencies &f readers will need to read certain sections in a specific order# note those sections here. /lso point out any sections that may "e read independently with no loss of understandin!.

1.) 'cope of the Product

&nclude a "rief narrative here which descri"es the product as you intend it to "e realized. 0se this section to define "oundaries and set expectations.

1.* "usiness +ase for the Product

1hy is this product re.uired2 3ow will it contri"ute to the !oals of your institution2 This section can "e used when re.uirements are "ein! ne!otiated# to assess whether a particular chan!e is a !ood idea. This section also helps readers understand why certain re.uirements have "een included.

1., &verview of the !e%uirements Document

&f your project is small to medium in size# include a summary of the re.uirements here. This may "e a num"ered list of the most important re.uirements. The purpose of this section is to !ive the reader a !eneral understandin! of the re.uirements and focus attention on the most critical ones. This section may also help point readers to the specific re.uirements that are of particular interest to them.

2. -eneral Description
"#is section 'i %ive t#e reader an overvie' of t#e project$ inc udin% '#y it 'as conceived$ '#at it 'i do '#en comp ete$ and t#e types of peop e 'e e,pect 'i use it. 0e a so ist constraints t#at 'ere faced durin% deve opment and assumptions 'e made about #o' 'e 'ou d proceed. This section contains a nontechnical description of the project# usually in narrative form# which may serve to ac.uaint new readers with the purpose of the project. &t also sets the sta!e for the specific re.uirement listin! which follows.

2.1 Product Perspective

1hy have you chosen to develop this product2 1hat need does it serve2 1ho are the primary sta'eholders# who is developin! the project# and who will "enefit from the finished product2

2.2 Product .unctions

1hat does your product do2 1hat activities can users perform while usin! it2 -ist the main functions that you will "uild into your product here.

2.) User +haracteristics

1ho do you expect to use your finished product# and why2 1hat is their technical "ac'!round# their trainin! or education# their motivation to use it2 1hat o"stacles mi!ht they encounter# and what specialized s'ills will they need2

2.* -eneral +onstraints

*id you wor' under any constraints such as platform or development environment2 *id you have to ma'e your product compati"le with any existin! software or other products currently in use2

2., Assumptions and Dependencies

Project 1ame: Requirements Document (version 1.0)

&n this section# list any assumptions you made a"out your project for example# did you assume that the finished product would need to "e delivered over the internet2$. &f your project depends on any particular technical infrastructure# or re.uires administrators or others with specific s'ills# note that here.

). 'pecific !e%uirements
"#is section of t#e document ists specific requirements for name of project. Requirements are divided into t#e fo o'in% sections: 1. 2ser requirements. "#ese are requirements 'ritten from t#e point of vie' of end users$ usua y e,pressed in narrative form. ). 3ystem requirements. "#ese are detai ed specifications describin% t#e functions t#e system must be capab e of doin%. -. &nterface requirements. "#ese are requirements about t#e user interface$ '#ic# may be e,pressed as a ist$ as a narrative$ or as ima%es of screen moc+*ups.

).1 User !e%uirements

-ist user re.uirements here.

).2 ' stem !e%uirements

-ist detailed system re.uirements here. &f your system is lar!e# you may wish to "rea' this into several su"sections.

).) Interface !e%uirements

-ist interface re.uirements here4 or include screen moc'ups. &f you use moc'ups# "e sure to explain major features or functions with narrative to avoid confusion or omission of desired features.

*. Appendices
&f you wish to append any documents# do so here. You may wish to include some or all of the followin!: 5ersonas and scenarios developed for this project Transcripts of user interviews# o"servations# or focus !roups 6opies of communications which contain user re.uirements 7ri!inal project proposals or other historical documents -ists of similar projects or products# with notes a"out how they differ from yours / list of re.uirements which were 8wish,listed8 or mar'ed unfeasi"le at present 7ri!inal screen moc'ups# if they are relevant

,. -lossar
&nclude a !lossary of definitions# acronyms# and a""reviations that mi!ht "e unfamiliar to some readers# especially technical terms that may not "e understood "y end,users or domain,specific terms that mi!ht not "e familiar to developers.

/. !eferences
-ist references and source documents# if any# in this section.

0. Inde1
&f your document is very lar!e# consider compilin! an index to help readers find specific items.

Project 1ame: Requirements Document (version 1.0)