Department of Software Engineering | Golisano College of ...



Document Control

Primary Owner: Elaine SimoneSteven Coad

src9472ens6412@rit.edu

Secondary Owner: Elaine SimoneTracy Rericha

ens6412tmk1698@rit.edu

Inquiries to: Steven CoadElaine Simone

src9472ens6412@rit.edu

Change History

|Published / Revised Date |Version # |Author |Section / |

| | | |Nature of Change |

|1.001/09/06Integrated each section of |1.0 |Steven CoadJen |Initial High level RequirementsCoding |

|the requirements done by the team, | |FarmerTracy Rericha |StandardIntegrated each section of the |

|fixed grammar mistakes, and added | | |requirements done by the team, fixed grammar |

|peripherary information. | | |mistakes, and added peripherary |

| | | |information.Initial compilation and revision. |

|2.001/09/06Updated requirements IDs |1.1 |Jen FarmerTracy |Second round after meeting with FARA |

|based on corresponding high level | |Rericha |boardUpdated requirements IDs based on |

|requirements. | | |corresponding high level |

| | | |requirements.Requirements ID numbers. |

|3.0 |1.2 |Elaine |Incorporated input from December 10, 2005 |

| | |SimoneJennifer |MeetingUser impact and acceptance criteria. |

| | |Farmer | |

|3.1 |1.3 |Elaine SimoneElaine |Fixed Source of High Level Requirement |

| | |SImone |columnMinor changes based on Jen’s first |

| | | |review. |

|4.001/15/06 |1.4 |Steve CoadSteven |Incorporated input from December 19, 2005 |

| | |Coad |ReviewPut together individual changes |

|4.101/17/06 |2.0 |Tracy RerichaElaine |Incorporated input from December 19, 2005 |

| | |Simone |Review; fixed grammar inconsistencies; |

| | | |re-reviewedAfter reviews combine individual |

| | | |changes, reordered. |

|4.21/18/06 |2.1 |Elaine |Added requirements F17 and d8 to capture need |

| | |SimoneJennifer |to streamline with |

| | |Farmer |Review changes and add |

| | | |acceptance criteria and user impact scale |

| | | |(urgent, high, medium and low). |

|1/19/06 |2.1 |Michelle Whalen |Review Changes. |

|1/21/06 |2.2 |Steven Coad |Re-ordered as per meeting notes. |

|1/23/06 |2.3 |Sandy Morris |Re-numbered requirements, edited for |

| | | |consistency, added new prioritization scale of|

| | | |High, Medium, Low instead of Urgent, High, |

| | | |Medium. |

|1/24/06 |2.4 |Elaine Simone |Rereviewed Changes. |

|1/25/06 |2.4jf5 |Jennifer Farmer |Reviewed v2.4 – added changes and comments. |

|1/25/06 |2.6 |Elaine Simone |Accepted and made changes per Jen’s questions.|

|1/25/06 |2.7 |Tracy Rericha |Reviewed changes; very minor grammar fixes. |

Review and Approval History

Required reviewers for the document in question should be indicated by placing an "X" next to their name in the following table. In the column entitled "vote" record each reviewers vote using the following letters (shown below) to indicate their approval, disapproval or submission of changes needed to garner their approval:

A - Approved

C - Changes were submitted and shall constitute approval of the reviewer if incorporated

D - Declined (This vote requires an explanation indicating why approval was denied.)

Required reviewers who have not responded by the deadline set shall be considered to be in agreement with the contents of the document under review.

|Organization\Role |Reviewer/Approver |Required |Vote |

|FARA |Jennifer Farmer | | |

|EDS |Michelle Whalen | | |

|EDS |John Manos | | |

Table of Contents

Document Control 2

Change History 2

Review and Approval History 2

1.1 Headings 5

1.1.1 Source File 5

1.1.2 Class 5

1.1.3 Method 6

1.2 Declarations 6

1.2.1 Placement 6

1.2.2 Class and Interface Declarations 7

1.2 Indentation and Line Length 7

1.2.3 Indentation 7

1.2.4 Line Length 7

1.3 Comments 9

1.3.1 Block Comments 9

1.3.2 Single-Line Comments 9

1.3.3 Trailing Comments 9

1.3.4 End-Of-Line Comments 9

1.4 Statements 10

1.4.1 Compound Statements 10

1.4.2 Return Statements 10

1.4.3 If Statements 10

1.4.4 For Statements 11

1.4.5 While Statements 11

1.4.6 Do-While Statements 11

1.4.7 Switch Statements 11

1.4.8 Try-Catch Statements 12

1.5 White Space 12

1.5.1 Blank Lines 12

1.5.2 Blank Spaces 12

1.6 Naming Conventions 13

Document Control ii

Change History ii

Review and Approval History ii

Functional Business Requirements 5

Performance Requirements 6

Interface Requirements 6

Design Requirements 6

Physical and Implementation Requirements 6

Document Control ii

Change History ii

Review and Approval History ii

Detailed Functional Business Requirements 5

Detailed Performance Requirements 34

Detailed Interface Requirements 34

Detailed Design Requirements 35

Detailed Physical and Implementation Requirements 39

Detailed Functional Business Requirements

|These standards were adapted from the |F1.001.000 |

|RIT CS Department guidelines for Java | |

|and C#: | |

| | |

| |

|standard.html | |

| | |

| |

|g-standard.html | |

| | |

|As well as Microsoft’s XML | |

|Documentation found at: | |

| | |

| |

|lt.asp?url=/library/en-us/csref/html/vc| |

|oriXMLDocumentation.asp | |

| | |

|Headings | |

| | |

|Source File | |

| | |

|All source files should begin with a | |

|c-style comment that lists the class | |

|name, version information, date, and | |

|copyright notice: | |

| | |

|/* | |

|* Classname | |

|* | |

|* Version information | |

|* | |

|* Date | |

|* | |

|* Copyright notice | |

|*/ | |

| | |

|Class | |

| | |

|The following comments will appear | |

|before the definition of every class: | |

| | |

|/// | |

|/// A description of this class goes | |

|here | |

|/// | |

|/// | |

|/// | |

|/// Author | |

|/// Sean Neubert | |

|(spn9006@cs.rit.edu) | |

|/// | |

|/// | |

|/// | |

|/// | |

| | |

|The elements of a class or interface | |

|declaration should appear in the | |

|following order: | |

|Class (static) variables  | |

|Instance variables  | |

|Constructors  | |

|Methods  | |

|Public variables should be listed | |

|first, followed by protected, then | |

|internal protected, internal, and | |

|finally the private variables.  | |

|Methods should be grouped by | |

|functionality. | |

| | |

|Method | |

| | |

|The following comments will appear | |

|before every method (including main):  | |

| | |

|/// | |

|/// Summary of this method. | |

|/// | |

|/// | |

|/// description | |

|/// | |

|/// description of why it is | |

|/// thrown | |

| | |

|The param tag contains an attribute | |

|called name (not type) of the | |

|parameter, followed by a description of| |

|the parameter inside of the tag. The | |

|name and data type always start with a | |

|lowercase letter. The description is | |

|most usually a phrase, starting with a | |

|lowercase letter and ending without a | |

|period, unless it contains a complete | |

|sentence.  | |

| | |

|The return tag is followed by a | |

|description of the return value. | |

|Whenever possible, detailed information| |

|(such as returns -1 when an | |

|out-of-bounds argument is supplied) | |

|should be provided. | |

| | |

|An exception tag should be included for| |

|any exceptions you throw. The exception| |

|tag has an attribute named "cref". This| |

|should contain the name of the type of | |

|exception thrown. The content of the | |

|tag should describe what conditions are| |

|present when the exception is thrown. | |

|Declarations | |

| | |

|Declarations per Line | |

| | |

|One declaration per line is recommended| |

|since it encourages commenting. | |

| | |

|int level; // indentation level | |

|int size; // size of table | |

|is preferred over | |

|int level, size; | |

| | |

|Placement | |

| | |

|Put declarations only at the beginning | |

|of blocks. (A block is any code | |

|surrounded by curly braces "{" and | |

|"}".) Don't wait to declare variables | |

|until their first use; it can confuse | |

|the unwary programmer and hamper code | |

|portability within the scope. The one | |

|exception to the rule is indexes of for| |

|loops. | |

| | |

|void myMethod() { | |

|int int1 = 0; // beginning of | |

|method block | |

| | |

|if (condition) { | |

|int int2 = 0; // beginning of "if" | |

|block | |

|... | |

|} | |

|} | |

| | |

|Class and Interface Declarations | |

| | |

|There will be no space between a method| |

|name and the parenthesis "(" starting | |

|its parameter list. An open brace "{" | |

|appears at the end of the same line as | |

|the declaration statement, and the | |

|closing brace "}" starts a line by | |

|itself indented to match its | |

|corresponding opening statement, except| |

|when it is a null statement the "}" | |

|should appear immediately after the | |

|"{". Methods are separated by a blank | |

|line. | |

| | |

|class Sample extends Object { | |

|int ivar1; | |

|int ivar2; | |

| | |

|Sample(int i, int j) { | |

|ivar1 = i; | |

|ivar2 = j; | |

|} | |

| | |

|int emptyMethod() {} | |

| | |

|... | |

|} | |

|Indentation and Line Length | |

| | |

|Indentation | |

| | |

|Four spaces should be used as the unit | |

|of indentation. The exact construction | |

|of the indentation (spaces vs. tabs) is| |

|unspecified. Tabs must be set exactly | |

|every 8 spaces. | |

| | |

|Line Length | |

| | |

|Avoid lines longer than 80 characters, | |

|since they're not handled well by many | |

|terminals and tools. When an expression| |

|will not fit on a single line, break it| |

|according to these general principles: | |

|Break after a comma. | |

|Break before an operator. | |

|Prefer higher-level breaks to | |

|lower-level breaks. | |

|Align the new line with the beginning | |

|of the expression at the same level on | |

|the previous line. | |

|If the above rules lead to confusing | |

|code or to code that's squished up | |

|against the right margin, just indent 8| |

|spaces instead. | |

| | |

|Here are some examples of breaking | |

|method calls: | |

| | |

|someMethod(longExpression1, | |

|longExpression2, longExpression3, | |

|longExpression4, longExpression5); | |

| | |

|var = someMethod1(longExpression1, | |

|someMethod2(longExpression2, | |

|longExpression3)); | |

| | |

|Following are two examples of breaking | |

|an arithmetic expression. The first is | |

|preferred, since the break occurs | |

|outside the parenthesized expression, | |

|which is at a higher level. | |

| | |

|longName1 = longName2 * (longName3 + | |

|longName4 - longName5) | |

|+ 4 * longname6; // PREFER | |

| | |

|longName1 = longName2 * (longName3 + | |

|longName4 | |

|- longName5) + 4 * longname6; // AVOID | |

| | |

|Following are two examples of indenting| |

|method declarations. The first is the | |

|conventional case. The second would | |

|shift the second and third lines to the| |

|far right if it used conventional | |

|indentation, so instead it indents only| |

|8 spaces. | |

| | |

|//CONVENTIONAL INDENTATION | |

|someMethod(int anArg, Object | |

|anotherArg, String yetAnotherArg, | |

|Object andStillAnother) { | |

|... | |

|} | |

| | |

|//INDENT 8 SPACES TO AVOID VERY DEEP | |

|INDENTS | |

|private static synchronized | |

|horkingLongMethodName(int anArg, | |

|Object anotherArg, String | |

|yetAnotherArg, | |

|Object andStillAnother) { | |

|... | |

|} | |

| | |

|Line wrapping for if statements should | |

|generally use the 8-space rule, since | |

|conventional (4 space) indentation | |

|makes seeing the body difficult. For | |

|example: | |

| | |

|//DON'T USE THIS INDENTATION | |

|if ((condition1 && condition2) | |

||| (condition3 && condition4) | |

|||!(condition5 && condition6)) { //BAD | |

|WRAPS | |

|doSomethingAboutIt(); //MAKE| |

|THIS LINE EASY TO MISS | |

|} | |

| | |

|//USE THIS INDENTATION INSTEAD | |

|if ((condition1 && condition2) | |

||| (condition3 && condition4) | |

|||!(condition5 && condition6)) { | |

|doSomethingAboutIt(); | |

|} | |

| | |

|//OR USE THIS | |

|if ((condition1 && condition2) || | |

|(condition3 && condition4) | |

|||!(condition5 && condition6)) { | |

|doSomethingAboutIt(); | |

|} | |

|Here are three acceptable ways to | |

|format ternary expressions: | |

|alpha = (aLongBooleanExpression) ? beta| |

|: gamma; | |

| | |

|alpha = (aLongBooleanExpression) ? beta| |

|: gamma; | |

| | |

|alpha = (aLongBooleanExpression) | |

|? beta | |

|: gamma; | |

| | |

|Comments | |

| | |

|Block Comments | |

| | |

|Block comments are used to provide | |

|descriptions of files, methods, data | |

|structures and algorithms. Block | |

|comments may be used at the beginning | |

|of each file and before each method. | |

|They can also be used in other places, | |

|such as within methods. Block comments | |

|inside a function or method should be | |

|indented to the same level as the code | |

|they describe. A block comment should | |

|be preceded by a blank line to set it | |

|apart from the rest of the code. | |

| | |

|/* | |

|* Here is a block comment. | |

|*/ | |

| | |

|Single-Line Comments | |

| | |

|Short comments can appear on a single | |

|line indented to the level of the code | |

|that follows. If a comment can't be | |

|written in a single line, it should | |

|follow the block comment format. A | |

|single-line comment should be preceded | |

|by a blank line. Here's an example: | |

| | |

|if (condition) { | |

| | |

|/* Handle the condition. */ | |

|... | |

|} | |

| | |

|Trailing Comments | |

| | |

|Very short comments can appear on the | |

|same line as the code they describe, | |

|but should be shifted far enough to | |

|separate them from the statements. If | |

|more than one short comment appears in | |

|a chunk of code, they should all be | |

|indented to the same tab setting. | |

|Here's an example of a trailing | |

|comment: | |

| | |

|if (a == 2) { | |

|return TRUE; /* special case| |

|*/ | |

|} else { | |

|return isPrime(a); /* works only | |

|for odd a */ | |

|} | |

| | |

|End-Of-Line Comments | |

| | |

|The // comment delimiter can comment | |

|out a complete line or only a partial | |

|line. It shouldn't be used on | |

|consecutive multiple lines for text | |

|comments; however, it can be used in | |

|consecutive multiple lines for | |

|commenting out sections of code. | |

|Examples of all three styles follow: | |

| | |

|if (foo > 1) { | |

| | |

|// Do a double-flip. | |

|... | |

|} | |

|else { | |

|return false; // Explain why | |

|here. | |

|} | |

|//if (bar > 1) { | |

|// | |

|// // Do a triple-flip. | |

|// ... | |

|//} | |

|//else { | |

|// return false; | |

|//} | |

|Statements | |

| | |

|Compound Statements | |

| | |

|Compound statements are statements that| |

|contain lists of statements enclosed in| |

|braces "{}". The enclosed statements | |

|should be indented one more level than | |

|the compound statement. The opening | |

|brace should be at the end of the line | |

|that begins the compound statement; the| |

|closing brace should begin a line and | |

|be indented to the beginning of the | |

|compound statement. Braces are used | |

|around all statements, even single | |

|statements, when they are part of a | |

|control structure, such as a if-else or| |

|for statement. This makes it easier to | |

|add statements without accidentally | |

|introducing bugs due to forgetting to | |

|add braces. | |

| | |

|Return Statements | |

| | |

|A return statement with a value should | |

|not use parentheses unless they make | |

|the return value more obvious in some | |

|way. Example: | |

| | |

|return; | |

| | |

|return myDisk.size(); | |

| | |

|return (size ? size : defaultSize); | |

| | |

|If Statements | |

| | |

|The if-else class of statements should | |

|have the following form: | |

| | |

|if (condition) { | |

|statements; | |

|} | |

| | |

|if (condition) { | |

|statements; | |

|} else { | |

|statements; | |

|} | |

| | |

|if (condition) { | |

|statements; | |

|} else if (condition) { | |

|statements; | |

|} else { | |

|statements; | |

|} | |

| | |

|For Statements | |

| | |

|A for statement should have the | |

|following form: | |

| | |

|for (initialization; condition; update)| |

|{ | |

|statements; | |

|} | |

| | |

|While Statements | |

| | |

|A while statement should have the | |

|following form: | |

| | |

|while (condition) { | |

|statements; | |

|} | |

| | |

|An empty while statement should have | |

|the following form: | |

| | |

|while (condition); | |

| | |

|Do-While Statements | |

| | |

|A do-while statement should have the | |

|following form: | |

| | |

|do { | |

|statements; | |

|} while (condition); | |

| | |

|Switch Statements | |

| | |

|A switch statement should have the | |

|following form: | |

| | |

|switch (condition) { | |

|case ABC: | |

|statements; | |

|/* falls through */ | |

| | |

|case DEF: | |

|statements; | |

|break; | |

| | |

|case XYZ: | |

|statements; | |

|break; | |

| | |

|default: | |

|statements; | |

|break; | |

|} | |

| | |

|Every time a case falls through | |

|(doesn't include a break statement), | |

|add a comment where the break statement| |

|would normally be. This is shown in the| |

|preceding code example with the /* | |

|falls through */ comment. Every switch | |

|statement should include a default | |

|case. The break in the default case is | |

|redundant, but it prevents a | |

|fall-through error if later another | |

|case is added. | |

| | |

|Try-Catch Statements | |

| | |

|A try-catch statement should have the | |

|following format: | |

| | |

|try { | |

|statements; | |

|} catch (ExceptionClass e) { | |

|statements; | |

|} | |

|A try-catch statement may also be | |

|followed by finally, which executes | |

|regardless of whether or not the try | |

|block has completed successfully. | |

|try { | |

|statements; | |

|} catch (ExceptionClass e) { | |

|statements; | |

|} finally { | |

|statements; | |

|} | |

| | |

| | |

| | |

|White Space | |

|Blank Lines | |

| | |

|Blank lines improve readability by | |

|setting off sections of code that are | |

|logically related. Two blank lines | |

|should always be used in the following | |

|circumstances: | |

|Between sections of a source file | |

|Between class and interface definitions| |

| | |

|One blank line should always be used in| |

|the following circumstances: | |

|Between methods | |

|Between the local variables in a method| |

|and its first statement | |

|Before a block or single-line comment | |

|Between logical sections inside a | |

|method to improve readability | |

| | |

|Blank Spaces | |

| | |

|Blank spaces should be used in the | |

|following circumstances: | |

|A keyword followed by a parenthesis | |

|should be separated by a space. | |

|Example: | |

|while (true) { | |

|... | |

|} | |

| | |

|Note that a blank space should not be | |

|used between a method name and its | |

|opening parenthesis. This helps to | |

|distinguish keywords from method calls.| |

| | |

|A blank space should appear after | |

|commas in argument lists. | |

|All binary operators except . should be| |

|separated from their operands by | |

|spaces. Blank spaces should never | |

|separate unary operators such as unary | |

|minus, increment ("++"), and decrement | |

|("--") from their operands. Example: | |

| | |

|a += c + d; | |

|a = (a + b) / (c * d); | |

| | |

|while (d++ = s++) { | |

|n++; | |

|} | |

|printSize("size is " + foo + "\n"); | |

| | |

|The expressions in a for statement | |

|should be separated by blank spaces. | |

|Example: | |

|for (expr1; expr2; expr3) | |

| | |

|Casts should be followed by a blank | |

|space. Examples: | |

|myMethod((byte) aNum, (Object) x); | |

|myMethod((int) (cp + 5), ((int) (i + | |

|3)) + 1); | |

|Naming Conventions | |

| | |

|The most important thing to remember is| |

|that variable names need to be | |

|descriptive of their role. Also, by | |

|looking at the variable name, you | |

|should be able to understand what data | |

|type the variable is. To accomplish | |

|this, an abbreviation of the data type | |

|will be at the beginning of the | |

|variable name. | |

| | |

|For example: | |

| | |

|String sFirstName; | |

|int iAge; | |

|Requirement ID: | |

|Requirement Title: |The process shall be web-based and indexed by major search engines. |

|Detailed Requirement Description: |Who – The website itself. |

| |What – The website shall be findable by online search engines. |

| |Where – Major search engines such as Google and Yahoo!. |

| |When – Whenever a user searches for the website online. |

| |Why – So that the user can effectively find the website if they do not have the link themselves. |

| |How – By registering particular key words that will identify our site with search engines. To be |

| |provided by Jen Farmer (captured in Action Item) Friedreich’s Ataxia, FA, registry, ataxia, FA clinical |

| |trials |

|Source of Requirement (Name): |Jen Farmer |

|Authorized Approvers: |Jen Farmer |

|User Impact of Requirement: |Medium: The user will be greatly impacted if they are not able to access the registry from anywhere and |

| |if they cannot find it by way of searching on the Internet. If the website were private and not indexed,|

| |people would have to be explicitly told about its existence. Therefore not making it searchable will |

| |decrease the usage because people will not be able to discover it. |

|Acceptance Criteria: |The user shall be able to type in particular keywords (Friedreich’s Ataxia, FA, registry, ataxia, FA |

| |clinical trials) and locate the FARA patient registry in the list of returned search items. |

|Requirement ID: |F2.002.000 |

|Requirement Title: |The website shall display information about who the registry is looking for and general information about|

| |it. |

|Detailed Requirement Description: |Who – Anyone who views the site |

| |What – General information about the purpose of the registry, who sponsors it (FARA), and who it reaches |

| |out to (FA patients). |

| |Where – The main page of the website. |

| |When – When the user accesses the main page of the website. |

| |Why – So that the user can understand how the website should be used, and by whom. |

| |How – By displaying text which clarify the purpose and inclusion of the website. Text to be provided by |

| |Jen Farmer. |

|Source of Requirement (Name): |Jen Farmer |

|Authorized Approvers: |Jen Farmer |

|User Impact of Requirement: |High: The user will be greatly impacted if they do not know how to use the system or that the system is |

| |sponsored by a reliable source. Some Patients without explanation may not think that he or she can |

| |register, or perhaps people may register that are not FA patients, but have a different forms of muscular|

| |problems that are similar. |

|Acceptance Criteria: |The user shall be able to view the primer upon accessing the main page of the FARA patient registry. |

|Requirement ID: |F3.003.000 |

|Requirement Title: |User must accept HIPAA to participate in the Registry |

|Detailed Requirement Description: |Who – Patient |

| |What – Patient accepts the HIPAA disclosure |

| |When – For New Patient, after providing initial information, for Returning Patient, must be completed |

| |first. |

| |Where – Before clinical information is entered for New Patients. Before any actions can be taken for |

| |Returning Patients. |

| |Why – Patient’s health information will shared and therefore he or she will have to consent to the |

| |revealing of private health information. New Patients need to provide some information before seeing the|

| |HIPAA, to determine if the Patient is a minor or not, and if the Guardian would have to agree to the |

| |HIPAA disclosure. |

| |How – The recording of the Patient’s acceptance (selecting Accept) will be recorded into the Registry and|

| |allow the Patient to begin providing information. The HIPAA information will display in the same window|

| |as the previous ‘Initial Screen’ without the use of a popup. |

|Source of Requirement (Name): |Jen Farmer |

|Authorized Approvers: |Jen Farmer |

|User Impact of Requirement: |High: Personal health information (PHI) must be kept private and when disclosed patients need to sign or |

| |acknowledge that they are aware of the disclosure and give permission. If patient information is |

| |collected without appropriate consent this is a violation of patient rights. If a Patient does not agree |

| |to the HIPAA disclosure he or she cannot enter the Registry. |

|Acceptance Criteria: |When the accept button is selected from the HIPAA screen the patient will proceed into the registry. |

| |Also, the database will capture the acceptance from the patient and record it for FARA. |

|Requirement ID: |F3.004.000 |

|Requirement Title: |User declining of HIPAA shall lead to explanation page. |

|Detailed Requirement Description: |Who – Patient |

| |What - Go to an additional explanation page and that will remove them from the process and that will not |

| |allow them to go further unless they accept. Offer the user some information & and the email link for |

| |help as listed in other requirement. Same template as any of the other pages. |

| |When – Patient declines HIPAA disclosure. |

| |Where – Before any information is entered; first step in the process for new registrants and/or those |

| |returning. |

| |Why – Helps user understand the significance of the HIPAA disclosure and that their personal information |

| |will be shared with third parties. |

| |How – After the user declines HIPAA the user will be taken to an explanation page, which will display in |

| |the same window without the use of a popup. |

|Source of Requirement (Name): |Jen Farmer |

|Authorized Approvers: |Jen Farmer |

|User Impact of Requirement: |High: Without the additional screen Patients may not participate in the Registry because he or she may be|

| |confused. Wary Patients may automatically choose no without reading the HIPAA disclosure and be confused|

| |about why he or she cannot register. |

|Acceptance Criteria: |When decline button is selected from the HIPAA screen another screen will appear acknowledging that they |

| |declined and offer information, contact individual and return to homepage and will not be permitted |

| |further into the application. |

|Requirement ID: |F4.005.000 |

|Requirement Title: |There shall be a check to make sure that the provided guardian is over 18 years of age. |

|Detailed Requirement Description: |Who –Patients |

| |What – There will be a check to make sure that the date of birth of the provided guardian is valid |

| |meaning that the guardian is over the age of 18. |

| |When – In the Guardian Screen. A patient/guardian must enter guardian information due to the fact that |

| |the patient is under the age of 18. |

| |Where – This check will be done just after the information is entered into the ‘Guardian Screen’ before |

| |the Patient is allowed to continue on to the next page. |

| |Why – If the guardian is not over the age of 18 they do not qualify as a valid guardian for the patient. |

| |How – The check will be done behind the scenes on the client side by the application analyzing the |

| |guardian’s date of birth to ensure that the age of the guardian is over 18. |

|Source of Requirement (Name): |Jen Farmer |

|Authorized Approvers: |Jen Farmer |

|User Impact of Requirement: |High: Minors could enter fraudulent information on the site and FARA needs to comply with the standard |

| |rights of parent/guardian when dealing with minors. Patients who are minors could enter information |

| |without his or her guardian’s consent. |

|Acceptance Criteria: |The system will validate that the individual entering information and providing HIPAA consent is a |

| |patient over 18 yrs or a guardian. If the patient enters a date of birth that is consistent with age |

| | 1) {

// Do a double-flip.

...

}

else {

return false; // Explain why here.

}

//if (bar > 1) {

//

// // Do a triple-flip.

// ...

//}

//else {

// return false;

//}

Statements

Compound Statements

Compound statements are statements that contain lists of statements enclosed in braces "{}". The enclosed statements should be indented one more level than the compound statement. The opening brace should be at the end of the line that begins the compound statement; the closing brace should begin a line and be indented to the beginning of the compound statement. Braces are used around all statements, even single statements, when they are part of a control structure, such as a if-else or for statement. This makes it easier to add statements without accidentally introducing bugs due to forgetting to add braces.

Return Statements

A return statement with a value should not use parentheses unless they make the return value more obvious in some way. Example:

return;

return myDisk.size();

return (size ? size : defaultSize);

If Statements

The if-else class of statements should have the following form:

if (condition) {

statements;

}

if (condition) {

statements;

} else {

statements;

}

if (condition) {

statements;

} else if (condition) {

statements;

} else {

statements;

}

For Statements

A for statement should have the following form:

for (initialization; condition; update) {

statements;

}

While Statements

A while statement should have the following form:

while (condition) {

statements;

}

An empty while statement should have the following form:

while (condition);

Do-While Statements

A do-while statement should have the following form:

do {

statements;

} while (condition);

Switch Statements

A switch statement should have the following form:

switch (condition) {

case ABC:

statements;

/* falls through */

case DEF:

statements;

break;

case XYZ:

statements;

break;

default:

statements;

break;

}

Every time a case falls through (doesn't include a break statement), add a comment where the break statement would normally be. This is shown in the preceding code example with the /* falls through */ comment. Every switch statement should include a default case. The break in the default case is redundant, but it prevents a fall-through error if later another case is added.

Try-Catch Statements

A try-catch statement should have the following format:

try {

statements;

} catch (ExceptionClass e) {

statements;

}

A try-catch statement may also be followed by finally, which executes regardless of whether or not the try block has completed successfully.

try {

statements;

} catch (ExceptionClass e) {

statements;

} finally {

statements;

}

White Space

Blank Lines

Blank lines improve readability by setting off sections of code that are logically related. Two blank lines should always be used in the following circumstances:

• Between sections of a source file

• Between class and interface definitions

• One blank line should always be used in the following circumstances:

• Between methods

• Between the local variables in a method and its first statement

• Before a block or single-line comment

• Between logical sections inside a method to improve readability

Blank Spaces

Blank spaces should be used in the following circumstances:

• A keyword followed by a parenthesis should be separated by a space. Example:

while (true) {

...

}

Note that a blank space should not be used between a method name and its opening parenthesis. This helps to distinguish keywords from method calls.

• A blank space should appear after commas in argument lists.

• All binary operators except . should be separated from their operands by spaces. Blank spaces should never separate unary operators such as unary minus, increment ("++"), and decrement ("--") from their operands. Example:

a += c + d;

a = (a + b) / (c * d);

while (d++ = s++) {

n++;

}

printSize("size is " + foo + "\n");

• The expressions in a for statement should be separated by blank spaces. Example:

for (expr1; expr2; expr3)

• Casts should be followed by a blank space. Examples:

myMethod((byte) aNum, (Object) x);

myMethod((int) (cp + 5), ((int) (i + 3)) + 1);

Naming Conventions

The most important thing to remember is that variable names need to be descriptive of their role. Also, by looking at the variable name, you should be able to understand what data type the variable is. To accomplish this, an abbreviation of the data type will be at the beginning of the variable name.

For example:

String sFirstName;

int iAge;

-----------------------

EDS \ RIT \ FARA

Detailed High Level RequirementsCoding Standard

FARA Registry Project

Version 41.02.734

(InputFile)

Saturday, February 04, 2006Thursday, January 26, 2006Wednesday, January 25, 2006

-----------------------

EDS INTERNAL DOCUMENT

[pic]

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download