1
Preliminaries Title Page Abstract Table of Contents List of Figures List of Tables Introduction Overview of the Current State of Technology Statement of the Problem Problem Proect Obectives !eneral Obective S"ecific Obectives Significance of the Proect #eview of #elated Literature #e$uirements Analysis and %ocumentation Sco"e of the Proect Overview of the #e$uirements %ocumentation !eneral %escri"tion Product Pers"ective Product Functions &ser Characteristics !eneral Constraints Assum"tions and %e"endencies S"ecific #e$uirements &ser #e$uirements System #e$uirements Interface #e$uirements %esign of Software' Systems' Product' and(or Processes %evelo"ment )ethod %escri"tion of the Prototy"e Testing Im"lementation Plan *Infrastructure(%e"loyment+ *Infrastructure(%e"l oyment+ Conclusion and #ecommendations #ecommendations ,ibliogra"hy A""endices Proect !antt Chart Su""orting %ocumentations *&ser !uide()anual' etc-+ Sam"le In"ut(out"ut(re"orts .valuation Tool or Test %ocuments #elevant Source Code Communication Letters Proect Status #e"orts
One/Page Curriculum 0itae "er team member
Format for the Capstone Project Preliminari es Title Page Abstract An abstract is a summary of your com"leted "roect with 123 to 33 words of short' direct and com"lete sentences- If done well' it ma4es the reader want to learn more about your "roect These are the basic com"onents of an abstract in any disci"line5 1- Motivation/problem statement 5 6hy do we care about the "roblem7 6hat "ractical' scienti8c' theoretical or artistic ga" is your research filling7 - Methods/procedure/approach 5 6hat did you actually do to get your results7 *e-g- analy9ed legacy systems' com"leted three web/ based information systems' interviewed 1: technical e;"erts+ <- Results/findings/product 5 As a result of com"leting the above "rocedure' what did you learned(develo"ed(created7 =- Conclusion/implications 5 6hat are the larger im"lications of your 8ndings' es"ecially for the "roblem(ga" identi8ed in ste" 1(o""ortunities seen7
Table of Contents List of Figures List of Tables Introduction >ote5 Provide an introductory "aragra"h of what the reader should e;"ect in this section-
Overview of the Current State of Technology This section gives the reader an overview of the s"ecific technology or 8eld in the international or local setting- The information regarding the technology or field should be contem"orary and not based on outdated sources- %iscussion must not be too technical or too detailed This section ends with a discussion on the "roblems faced by or that still e;ist in the s"ecific technology or 8eld *e-g-' limitations of e;is ting software or algorithms+- The "roblem statement would lead to the "roect obectives?owever' in some instances there will be no e;isting "roblem that can be identified but "ossible o""ortunities that can be loo4ed into-
Proect Obectives !eneral Obective This section states the over/all goal that must be achieved to answer the "roblem-
S"ecific Obectives This subsection is an elaboration of the general obective- It states the s"eci8c ste"s that must be underta4en to accom"lish the general obective- These obectives must be S)A#T *s"eci8c' measurable' attainable' realistic' and time/bounded+- .ach s"ecific obective may start with @to design(survey(review(analy9eB Studying a "articular "rogramming language or develo"ment tool *e-g-' to study 6indows(Obect/Oriented(!ra"hics(C "rogramming+ to accom"lish the general obective is inherent in all "roect "a"er and' therefore' must not be included here-
Significance of the Proect This section e;"lains why the "roect must be done in this area- It rationali9es the obectives of the
"roect with that of the stated "roblem(o""ortunity- Avoid including here sentences such as @This "roect will be bene8cial to the "ro"onents(de"artment(collegeB as this is already an inherent re$uirement of all "roects- Focus on the "roectDs contribution to the 8eld of Information and Communications TechnologySome things you may want to consider when writing this section is the answer to the $uestion E Why is this product required? This section can "rovide usti8cation when re$uirements are being negotiated' to assess whether a "articular change is a good idea- This section will also "rovide
<
readers an initial understanding why certain re$uirements have been included in the #e$uirements Analysis and %ocumentation section-
#eview of #elated Literature >ote5 Provide an introductory "aragra"h of what the reader should e;"ect in this section This section discusses the features' ca"abilities' and limitations of e;isting wor4' algorithms' or software that are related(similar to the "roect- The reviewed wor4s and software must be arranged either in chronological order' or by area *from general to s"ecific+- Observe a consistent format when "resenting each of the reviewed wor4sProvide literature-
2/13
#e$uirements Analysis and %ocumentation >ote5 Provide an introductory "aragra"h of what the reader should e;"ect in this section#e$uirements are the basic functions that a system needs to be able to carry out in order to "erform the tas4*s+ for which it was designed- The meat of a re$uirements document is' of course' the list of re$uirements- &ser re$uirements are functions that someone using the system will see or do- System re$uirements *also called technical re$uirements+ are behind/the/scenes' technical functions that the system must be ca"able of doing in order to su""ort the user re$uirements- ou donGt need to se"arate re$uirements by ty"e in a re$uirements document' although you can if you wish To get re$uirements out of scenarios' as4 yourself the following $uestions as you e;amine each scenario5 6hat is the user trying to do7 6hat "art of that tas4 is facilitated by the system or "roduct7 6hat "art of that tas4 is inde"endent of the system or "roduct7 6hat has to ha""en Hbehind the scenesH while the user does this tas47 6hat does the user see on the screen while s(he is wor4ing on the tas47
A re$uirements document e;"lains why a "roduct is needed' "uts the "roduct in conte;t' and describes what the 8nished "roduct will be li4e- A large "art of the re$uirements documentation is the formal list of re$uirements#e$uirements include descri"tions of system "ro"erties' s"ecifications for how the system should wor4' and constraints "laced u"on the develo"ment "rocess- !enerally' re$uirements are statements of what a system should do rather than how it should do it- The answers to how $uestions fall into the realm of design- #e$uirements s"eci8cations should not include design solutions *e;ce"t for interface re$uirements' which often include embedded design+#e$uirements come from end users' from customers' and sometimes fr om develo"ers.nd users tend to state re$uirements in descri"tive or narrative terms *HIGd li4e a welcome screen with lin4s to the things I use regularly' and I want to be able to select from a cou"le of different color schemes for the welcome screenH+ which might need to be bro4en down into individual re$uirement statements- Customers' who may well be dierent from end users' are the "eo"le who are "aying for the develo"ment of the system- Their re$uirements will often be stated in terms of costs or scheduling issues- %evelo"ers might have re$uirements related to system "erformance and other technical to"icsItGs im"ortant to have all these grou"s contribute to the re$uirements documentation to create a fuller descri"tion of the system- The "ractice of including these grou"s also hel"s to ensure that everyone is in agreement about what is to be done before develo"ment begins#e$uirements documentation usually include user' system' and interface re$uirementsJ other classes of re$uirements are included as needed- User requirements are written from the "oint of view of end users' and are ge nerally e;"ressed in narrative form5 The user must be able to change the color scheme of the welcome screen- ystem requirements are detailed s"eci8cations describing the functions the system needs to do- These are usually more technical in nature5 The system will include four preset color schemes for the welcome screen! Colors must be speci"ed for the page bac#ground$ the te%t$ visited lin#s$ unvisited lin#s$ active lin#s$ and buttons &base$ highlight$ and shadow'- (nterface requirements s"ecify how the interface *the "art of the system that users see and interact with+ will loo4 and behave- Interface re$uirements are often e;"ressed as screen moc4/u"sJ narratives or
lists are also used,esides listing re$uirements' the document should e;"lain why the "roduct is needed' "ut the "roduct in conte;t for develo"ment' and describe what the finished "roduct will be li4e-
=
Obviously' the scale of the "roect will inKuence the contents and length of a re$uirements document- Large' com"le; "roects are li4ely to have more re$uirementsSmaller' $uic4er "roects will have fewer re$uirements and will need shorter re$uirements documents' which can double as "roect "ro"osals-
Sco"e of Proect
the
Include a brief narrative here which describes the "roduct as you intend it to be reali9ed- &se this section to define boundaries and set e;"ectations-
Overview of %ocumentation
the
#e$uirements
If your "roect is small to medium in si9e' include a summary of the re$uirements here- This may be a numbered list of the most im"ortant re$uirements- The "ur"ose of this section is to give the reader a general understanding of the re$uirements and focus attention on the most critical ones- This section may also hel" "oint readers to the s"eci8c re$uirements that are of "articular interest to them-
!eneral %escri"tion This section will give the reader an overview of the "roect' including why it was conceived' what it will do when com"lete' and the ty"es of "eo"le we e;"ect will use it- 6e also list constraints that were faced during develo"ment and assum"tions we made about how we would "roceed This section contains a nontechnical descri"tion of the "roect' usually in narrative form' which may serve to ac$uaint new readers with the "ur"ose of the "roect- It also sets the stage for the s"ecific re$uirement listing which follows-
Product Pers"ective 6hy have you chosen to develo" this "roduct7 6hat need does it serve7 6ho are the "rimary sta4eholders' who is develo"ing the "roect' and who will directly bene8t from the 8nished "roduct7
Product Functions 6hat does your "roduct do7 6hat activities can users "erform while using it7 List the main functions that you will build into your "roduct here-
&ser Characteristics 6ho do you e;"ect to use your 8nished "roduct' and why7 6hat is their technical bac4ground' their training or education' their motivation to use it7 6hat obstacles might they encounter' and what s"eciali9ed s4ills will they need7
!eneral Constraints %id you wor4 under any constraints such as "latform or develo"ment environment7 %id you have to ma4e your "roduct com"atible with any e;isting software or other "roducts currently in use7
Assum"tions and %e"endencies In this section' list any assum"tions you made about your "roect *for e;am"le' did you assume that the finished "roduct would need to be delivered over the internet7+- If your "roect de"ends on any "articular technical infrastructure' or re$uires administrators or others with s"eci8c s4ills' note that here ou may also "rovide additional descri"tion to any assum"tions or de"endencies regarding the software and its use- These may concern such issues as5 #elated software or hardware O"erating systems .nd/user characteristics
Possible and(or "robable changes in functionality
S"ecific #e$uirements 1-
This section of the document lists s"eci8c re$uirements for name of "roect#e$uirements are divided into the following sections5 User requirements! These are re$uirements written from the "oint of view of end users' usually e;"ressed in narrative form- ystem requirements! These are detailed s"eci8cations describing the functions the system must be ca"able of doing-
2
<-
(nterface requirements! These are re$uirements about the user interface' which may be e;"ressed as a list' as a narrative' or as images of screen moc4/u"s-
&ser #e$uirements List user re$uirements here-
System #e$uirements List detailed system re$uirements here- If your system is large' you may wish to brea4 this into several subsections?ere are some sam"les of system re$uirements- >ote that not all "ossible re$uirements are listed here1- Logging In Out' #egistering' and Pro8les 1-1 &sers must be able to log in and log out1- The site must be usable over a modem- #eviewing Course )aterials -1 Students must be able to see at a glance which materials are associated with certain dates and(or units- The system must allow for inclusion of materials including' but not limited to5 te;t files' digiti9ed audio' digiti9ed video' and web forms-< Students must be able to wor4 through material at their own "ace' re"eating audio(video cli"s or re/reading te;t as desired<- Com"leting Student Assignments 1-1 The system must allow students to com"lete various ty"es of assignments' $ui99es' etc- and to submit t hem to the instructor*s+1- The system should su""ort the user by "roviding information' when a""ro"riate' so the user does not have to ty"e it in *i-e-' including a studentGs name on a $ui9 when the student is logged in+=- .valuating Student Assignments =-1 Instructors must be able to design assignments' $ui99es' etc=- Instructors must be able to see easily which students have com"leted an assignment=-< Instructors must be able to easily review a studentGs assignment and comment on it=-= Instructors must be able to save the comments they ma4e on a studentGs wor4' and send those comments to the student at a later time-
Interface #e$uirements List interface re$uirements here-
%esign of Software' Systems' Product' and(or Processes This section "resents the internal design of the system' by discussing its maor com"onents and their interactions- These com"onents include the software com"onents *e-g-' modules' database systems' etc-+' as well as the hardware com"onents *e-g-' "rocessors' devices' etc-+- The com"onents and their interactions are gra"hically re"resented using data Kow diagrams' system and "rogram Kowcharts' entity/relationshi" diagrams' hierarchical or structure charts' networ4 diagrams' and bloc4 diagrams- In addition' discussion on why certain alternative and trade/offs was chosen must be included *e-g-' issues on software decom"osition' cost of hardware+-
%evelo"ment )ethod ,riefly describe the method or a""roach used for this software design- If one or more formal("ublished methods were ado"ted or ada"ted' then include a reference to a more detailed descri"tion of these methods- If several methods were seriously
considered' then each such method should be mentioned' along with a brief e;"lanation of why all or "art of it was used or not used-
%escri"tion of the Prototy"e This section "rovides a listing of all the functions that must be "erformed or delivered by the system' and a descri"tion of each- Screen designs must be included' to hel" visuali9e the function being discussed- 6hen using screenshots' be sure to e;"lain maor features or functions with narrative to avoid confusion or omission of desired features- &sually' the functions are based on the menu and toolbar o"tions- If a function generates re"orts' the re"ort formats must be included in this section-
Testing
M
This section "resents the analysis' inter"retation and im"lications of the summari9ed test results' as well as the observations on the limits of the systemDs ca"abilities- It also discusses the ty"e*s+ of testing "erformed on the system' the test data used' and the results of the tests The ty"e*s+ of tests "erformed varies de"ending on the system develo"ed- For instance' commissioned software would re$uire a detailed acce"tance test and system res"onse time analysis' while software im"lementing an algorithm would re$uire an analysis of the "erformance of the algorithm on dierent machines or on different test data6e cannot test $uality directly' but we can test related factors to ma4e $uality visibleNuality has three sets of factors // functionalit y' engineering' and ada"tability- These three sets of factors can be thought of as dimensions in the software $uality s"ace.ach dimension may be bro4en down into its com"onent factors and considerations at successively lower levels of detail- The table below illustrates some of the most fre$uently cited $uality considerationsFunctionali ty Correctness
.ngineeri ng .ciency
Ada"tability &future quality' Fle;ibility
#eliability
Testability
#eusability
&sability
%ocumentation
)aintainability
Integrity
Structure
To initially determine if the "roduct will meet the factors as stated above which we can consider as success factor criteria' you will need to identify how we can determine we meet each criteria- Some e;am"les are5 1- Correctness5 Assurance that the data entered' "rocessed' and out"utted by a""lication system is accurate and com"lete- Accuracy and com"leteness are achieved through control over transactions and data element' which should commence when a transaction is originated and conclude when the transaction data has been used for its intended "ur"ose- File Integrity5 Assurance that the data entered into a""lication system will be returned unaltered The 8le integrity "rocedure ensures that the right file is used and that the data on the file and the se$uence in which the data is stored and retrieved is correct<- Access control5 Assurance that the "rogram "revents unauthori9ed access and "revents unauthori9ed users to destabili9e wor4 environment=- Scalability5 Assurance that the a""lication can handle the scaling criteria within constrains of "erformance criteria-
Im"lementation Plan *Infrastructure(%e"loyment+ System de"loyment is a com"le; endeavor which is a critical as"ect of the software develo"ment lifecycle *S%LC+' an endeavor that is all but ignored by most who write documentations- If you canGt get software into the hands of your users then what is its value7 Absolutely nothing- The im"lementation "lan should be documented and "resented- The following ti"s and techni$ues should hel" to ma4e your system de"loyment eorts successful5 1- (dentify and understand your deployment audience! There are at least three distinct grou"s that you need to consider5 your end users' the operations staff res"onsible for running the software once it is in " roducti on' and the support staff who is res"onsible for aiding your users with the software once it is in "roduction ou need to identify the level of control that each grou" has over your actual de"loyment- Can one grou" sto" your de"loyment if you donGt meet their s"eci8c re$uirements7 For e;am"le' it is $uite common to discover that if an organi9ation has an o"erations de"artment then they may have a de8ned criteria for the release of new software' criteria that your de"loyment a""roach must meet- (dentify your deployment strategy early! 6ill you run the new system in "arallel with the e;isting system or will you "erform a cutover7 #unning the system in "arallel offers the advantage that you can easily bac4 out to the original system if the new one runs into "roblems- ?owever' "arallel o"erations re$uires signi8cant effort on the "art of everyone involved5 our users need to do double entry' o"erations staff need to run both systems' su""ort staff need to su""ort both systems' and develo"ment staff may need to create integration code that tem"orarily wor4s behind the scenes to synchroni9e data- For many systems' "articularly ones su""orting online
customers via the Internet' a cutover is your only o"tion E few customers would be willing to "lace their boo4 order with both ,uy)eOnLine version > and with ,uy)eOnLine version >1- 6ith a straight cutover you will need to "lan for a downtime "eriod in which the cutover occurs' anywhere f rom a few seconds to a few hours' or even a few days de"ending on the nature of the system being de"loyed<- (nstallation testing! ust li4e you test your a""lication' you should also test your installation scri"ts- A good way to do this is to develo" your installation scri"ts as you develo" your system=- )ou may need to upgrade your user*s e%isting environments! These u"grades could include changes to e;isting hardware' o"erating systems' databases' or middleware- If you donDt 4now the current status of
:
your technical environment you will also need to "lan for activities to "erform the re$uired legacy analysis- If you are u"grading your database' you may be u"grading the database software itself or the schema of your databaseJ you will need to include data conversion activities in your de"loyment "lan- Physical considerations should also be considered when "erforming environment u"gradesIs sucient "ower available7 Are wor4ing areas such as des4s and cubicles in "lace7 %oes suicient room e;ist in the building*s+ that you are de"loying to7 %o sufficient networ4 dro"s e;ist for new wor4stations7 2- Training is an important part of deployment! #emember that your sta4eholders may need training beyond that of learning how to wor4 with your a""lication- For e;am"le' this may be the 8rst time that some users are wor4ing with a PC' a browser' or even a mouse- Similarly' this may be the 8rst time that your o"erations staff is wor4ing with a new technology that your system users' such as on a client/server environment' and therefore will need to be trained and educated in that technology to $ualify them to wor4 with your systemM- +evelop supporting documentation! Another im"ortant effort is the develo"ment of o"erations' su""ort' and user documentationThis should include installation manual' a com"rehensive user manual' resource re$uirements' and bac4/u" "rocedures-
Conclusion and #ecommendations This cha"ter gives an assessment of what ha""ened in this "roect- It "resents e;"lanations and ustifications on how the obectives of the "roect were met' t o what e;tent and why some obectives were not met This cha"ter also includes a discussion of "ossible im"rovements that can be made on the software' as well as future directions of the "roect in general- This serves as a s"ringboard for "roects that may be done by future "roect "ro"onents-
,ibliogra"hy >ote5 &se the APA htt"5((www-calstatela- edu(li brary(guides(
Style
A""endices Proect !antt Chart Su""orting %ocumentations *&ser !uide()anual' etc-+ Sam"le In"ut(out"ut(re"orts .valuation Tool or Test %ocuments #elevant Source Code Communication Letters Proect Status #e"orts One/Page Curriculum 0itae "er team member
