Test - Word Draft - Assignment #4

Boston University CS 633 Summer 01

BU CS 633 Summer 01

Distributed Software Development

Group 1 - Team 1

Assignment 4

Members: Mike Fallon, Kerry Aglugub, Pam Sherman

Date: June 2, 2012

Version 1.4

Assignment 4, Team SubmissionGroup 1, Team 1


DOCUMENT HISTORY AND DISTRIBUTION1. REVISION HISTORY

Revision # Revision Date Description of Change Author

1.0 05/30/2012 Initial Draft Document K Aglugub

1.1 05/30/12 Updated Part 1Added in Part 2Formatting changes throughout

M Fallon

1.2 05/31/12 Added Detailed Functional Requirements K Aglugub

1.3 06/1/12 Added Detailed Non Functional Requirements sectionAdded text introductions in Requirements Section

K Aglugub

1.4 06/2/12 Updated Part 2 (titles) M Fallon

2. DISTRIBUTION

Recipient Name Recipient Organization Distribution MethodPam Sherman Group 1, Team 1 Google Docs repositoryKerry Aglugub Group 1, Team 1 Google Docs repositoryRon Czik Facilitator, Group 1 Team 1 Vista Blackboard “Assignment” uploadEric Braude Instructor, BU CS 633 Vista Blackboard “Assignment” uploadMike Fallon Group 1, Team 1 Google Docs repository

3. PLAN APPROVERS

Approver Name Approval Date

Pam Sherman 6/4/2012, 8:04 pm EST

Kerry Aglugub 6/4/2012, 8:04 pm EST

Mike Fallon 6/4/2012, 8:04 pm EST



TABLE OF CONTENTS

TABLE OF CONTENTS 3

PART 1. SOFTWARE REQUIREMENTS SPECIFICATION 4

1.1 HIGH-LEVEL REQUIREMENTS...........................................................................................................................41.2 DETAILED FUNCTIONAL REQUIREMENTS....................................................................................................71.3 DETAILED NON-FUNCTIONAL REQUIREMENTS.................................................................................................91.4 “NEITHER” REQUIREMENTS...........................................................................................................................101.5 CHANGE CONTROLS......................................................................................................................................10

PART 2. DESIGN SPECIFICATIONS 13

2.1 STRUCTURAL DIAGRAMS............................................................................................................................132.2 BEHAVIOR FLOW DIAGRAMS......................................................................................................................13

APPENDIX A: REQUIREMENTS DEFINITIONS 14

REFERENCES 16



PART 1. SOFTWARE REQUIREMENTS SPECIFICATION

Complete the writing of all your requirements at a high level. Complete all of the detailed requirements for your must-do requirements. (It is usually a waste of time to write in detail about requirements that are unlikely to me implemented.)

This section fulfills the tasking for Part 1 of Assignment 4.

1.1 HIGH-LEVEL REQUIREMENTS

This section covers all of the project requirements, as of the date of this report, at a very high-level. Must Have requirements and Optional requirements are listed below. The team is using the Waterfall with Feedback process model. After last week’s assignment, where requirements were reevaluated and some requirements changes were made, the team instituted a requirements freeze until all Must Have requirements are implemented. Since the team itself is also the intended end users of the website, they decided that the requirements accurately reflected the needs of the team and had been sufficiently changed to reflect the unforeseen circumstances encountered during the project to date. The freeze was deemed important to prevent feature creep and for the project to stay on schedule given the already under-resourced team of three members.

Reference the following key:1) Requirements marked in yellow have been changed.2) Requirements with strike-through font have been removed or edited.3) Items with red font have been added/updated since the previous submission.

Requirements at a high-level are as follows:

Id

Category Description of Work Priority Requestor

Assigned

Tester

Date Begun

Date Complet

ed

Status

1 Accessibility

The Web site edit capabilities shall be restricted to authorized team members; team members are identified through login credentials (e-mail address and password). (Google, 2012) The site will be viewable to the public via

Must Have

Pam Kerry All 5/20/2012

5/23/2012

Complete



Id


Assigned

Tester

Date Begun

Date Complet

ed

Status

URL.2 Functiona

lThe Web site shall provide the ability to add, delete, and display photos of individual team members and/or team photo(s).

Must Have


In-Progress

3 Functional

The Web site shall provide the ability to add, update, delete, and display textual biographies of individual team members.

Must Have


In-Progress

4 Functional

The Web site shall provide a team calendar. The team calendar may be used for scheduling on-line meetings, reminders, project milestones.

Must Have


5/20/2012

Complete

5 Functional

All members of the team shall have the ability to add, update or delete calendar items, e.g., meetings, reminders, and appointments.

Must Have


5/20/2012

Complete

6 Operational

The calendar shall support multiple time zones, simultaneously. (For example, when scheduling a meeting, the time zones for each meeting invitee should be visible.) GMT-5:00 Eastern Time.

Optional Pam Kerry All 5/20/2012

5/20/2012

Complete

7 Functional

The calendar shall only permit the “owner”, or an authorized user, of a calendar item to update or delete the item.

Optional Pam All

8 Functional

The system shall provide file storage for team member documents. (Google, 2012) Each

Must Have

Pam Kerry All



Id


Assigned

Tester

Date Begun

Date Complet

ed

Status

member will be allocated 5 GB of file storage space.

9 Functional

Documents in the Web site’s file storage shall be visible to all team members.

Must Have

Pam Kerry All

10

Functional

The Web site shall provide an area for displaying announcements.

Must Have


5/23/2012

Complete

11

Functional

The Web site shall provide the ability for team members to vote on-line. (For example, an on-line poll allows team members to cast their vote regarding a team decision or preference.) (Google, 2012)

Optional Pam All

12

Functional

The Web site shall provide a blog for team members to post, ideas, status updates, and/or comments. (This may include review comments on a document, recent work-related books or articles read, etc.)

Optional Pam All 5/23/2012

5/23/2012

5/23/2012

13

Functional

The Web site shall provide the ability to add, update, and/or delete entries for which team member is currently working on the update of a document in file storage. (In other words, this provides team members to see who is working on specific documents.)

Optional Pam All

14

Functional

The Web site shall provide the ability to add, update, delete, and display an on-line risk list,

Optional Pam Kerry All



Id


Assigned

Tester

Date Begun

Date Complet

ed

Status

which includes risk description, triggering condition for the risk, and mitigation options .(Braude, MET CS 633 Summer 01 Distributed Software Development, 2012, Module 3, Section 14 Risk Management and GDD)

15

Functional

The Web site shall provide the ability to add, update, delete, and display project and/or task assignments for team members.

Optional Pam All

16

Functional

The Web site shall provide the ability to display helpful “tips” for a geographically distributed team. (Braude, (1) LC Reminder (2) More e-mail tips [E-mail], 2012)

Optional Pam All

17

Usability The Web site must be easy enough to navigate for a new end-user who has not been provided training or Help.

Must have

Pam Kerry All

18

Accessibility

The Web site shall be available 24 hours a day, 365 days a year, except for scheduled maintenance.

Must have

Pam Kerry All

19

Data For the initial release, all text displayed on the Web site shall be in English.

Must have

Pam Kerry All

20

Usability The response time for navigating to a new page on the Web site shall be no more than ten (10) seconds.

Must have

Pam Kerry All

21

Accessibility

The Web site is expected to support a team of no

Optional Pam Kerry All



Id


Assigned

Tester

Date Begun

Date Complet

ed

Status

more than 5 (five) end-users.

Please review Section 1.4 “Change Controls” to review methods and controls.

1.2 DETAILED FUNCTIONAL REQUIREMENTS

As instructed by the homework assignment, this section provides detailed requirements for each high-level functional requirement marked “Must Have” on our list of requirements. “A requirement specifies what the customer wants.” (Braude & Wiley, 2007, Module 4) High-level requirements are “an overview that is especially suited to customers.” (Braude & Wiley, 2007, Module 4) Detailed requirements “are especially useful for developers who need to know precisely what the application must do.” (Braude & Wiley, 2007, Module 4) In order for an application to meet it’s end users needs, the project team must precisely specify these detailed requirements since distributed developers are often far-removed from the requirements analysis process and the customer. Developers must not make their own decisions about functionality due to unclear detailed requirements. As discussed earlier our team, decomposed only the Must Have requirements into detailed requirements for both the functional and non-functional requirements. After the last round of requirement changes, the team agreed to freeze the requirements in keeping with the Waterfall process model until implementation of all Must Have requirements are completed.

1. The Web site edit capabilities shall be restricted to authorized team members; team members are identified through login credentials (e-mail address and password). The site will be viewable to the public via URL.1.1. The web site administrative screen shall display authorized users by first name, last name, and

email address in a HTML table in sans-serif font.1.2. The web site administrative screen shall display an “Add users” textarea input field of 60

characters for granting access to the website; commas shall separate user email addresses for multiple user entry.

1.3. Login Email and Password shall be input fields of 50 characters long.1.4. Email field shall use PHP validation function regEx.

2. The Web site shall provide the ability to add, delete, and display photos of individual team members and/or team photo(s). 2.1. The image upload feature shall provide a text field of 60 characters for an image URL.2.2. The image upload feature shall provide an insert image button that allows a user to browse to

an image on their desktop and select the image for upload.



2.3. Image upload size is limited to 2GB.3. The Web site shall provide the ability to add, update, delete, and display textual biographies of

individual team members.3.1. The site shall provide a wiki-style editing page for adding and deleting biography text.

4. The Web site shall provide a team calendar. The team calendar may be used for scheduling on-line meetings, reminders, project milestones.4.1. The calendar page shall display custom CS633 team Google Calendar using Google Site’s

calendar integration gadget.4.2. The calendar shall include the following views: print, week, month and agenda. 4.3. The calendar shall display in 12 pt san-serif font with alternating table row colors.

5. All members of the team shall have the ability to add, update or delete calendar items, e.g., meetings, reminders, and appointments. 5.1. The calendar shall use Google Calendar’s standard calendaring functionality.

6. The system shall provide file storage for team member documents. Each member will be allocated 5 GB of file storage space.6.1. File upload page shall contain the following buttons: Add file, Add link, and Delete.6.2. File upload shall be restricted to 5 GB per user.

6.2.1. “Add file” shall prompt the user to browse to a file on their computer for upload.6.2.2. “Add link” shall display the following:

6.2.2.1. Text field of 60 characters for URLs6.2.2.2. Text field of 60 characters for Text to display on the frontend screen6.2.2.3. Textarea field of 100 characters for file description.6.2.2.4. Add button6.2.2.5. Cancel button

6.2.3. A checkbox next to each file shall allow users to select a file and then click the “Delete” button for file removal.

7. Documents in the Web site’s file storage shall be visible to all team members. 7.1. Files stored on the site’s Document’s page shall be shown in a HTML table in 12pt san-serif font

with the following fields displayed on the frontend: checkbox, file name, file size, version number, timestamp of upload, file owner.

8. The Web site shall provide an area for displaying announcements.8.1. Announcements shall be display on the site’s homepage with the following fields: Title,

Description, Posted at [time stamp] by [owner].



8.1.1. “Title” field shall be a hyperlink to view the announcement in its entirety on a separate web page.

1.3 DETAILED NON-FUNCTIONAL REQUIREMENTS

As instructed by the homework assignment, this section provides detailed requirements for each high-level non-functional requirement marked “Must Have” on our list of requirements. Non-functional requirements consist of many types. Detailed interface, availability, constraints, and performance requirements are listed below for the Must Have non-functional requirements. Interface requirements detail “how the application interacts with the user, and with other applications.“ (Braude & Wiley, 2007, Module 4) These requirements for the Terrier Team website are shown in Requirement 1.1. Availability measures how available the application is to the end user and is detailed in Requirement 2.1. “A constraint on an application is a requirement that limits it.” (Braude & Wiley, 2007, Module 4) An example of this is shown in Requirement 3.1. “Performance requirements specify timing constraints that the application must observe.” (Braude & Wiley, 2007, Module 4) This last set of non-functional detailed requirements is specified in Requirement 4.1.

1. The Web site must be easy enough to navigate for a new end-user who has not been provided training or Help.1.1. Interface Requirements:

1.1.1. The Web site shall comply with World Wide Web Consortium (W3C) web standards specifically the Web Content Accessibility Guidelines (WCAG) 2.0.

1.1.2. The Web site shall validate with zero errors using the W3C online validation service.2. The Web site shall be available 24 hours a day, 365 days a year, except for scheduled maintenance.

2.1. Availability:2.1.1. The Web site shall have 98% uptime.2.1.2. The Web site shall have 24x7 site monitoring provided by Google.

3. For the initial release, all text displayed on the Web site shall be in English.3.1. Constraint:

3.1.1. The Web site’s MIME character set attribute shall be UTF-8 to support English language html characters.

4. The response time for navigating to a new page on the Web site shall be no more than ten (10) seconds.4.1. Performance:

4.1.1. Page load time shall not exceed 10 seconds.4.1.2. Response time shall be measured by YSlow’s Firefox add-on.



1.4 “NEITHER” REQUIREMENTS

Our team decided that this category of requirements did not benefit the end product. We believe that a set of requirements should only consist of the necessary requirements (“Must Have”) and the “Optional” requirements, which are the requirements that can be completed if time allows, if it improves the scope quality, shortens the delivery schedule, etc. We believe that any unnecessary requirements should not be completed, anyways, and that listing these requirements with the product has a detrimental effect of adding confusion to the scope of the project.

1.5 CHANGE CONTROLS

We believe that this is a necessary function of requirements (get a reference for this??) gathering and the development process. The following guidance is agreed upon by our project team:

1) It’s important to retain the requirements from their initial state in order to view the changes and the current state of the documented requirement. This is necessary to understand the decision surrounding the addition or removal of any requirement. For this reason, we have the developed a reference key (see Section 1.1) which is to be used throughout the project life cycle.

2) Whenever a requirement is to be added or changed, we will state the requirement ID, change to be made and reason for change. The change request is to be distributed to the team via the Google Groups distribution list: [email protected] which is distributed to all team members who will respond in kind to either approve or disapprove the addition or change.

3) The team will review changes to the requirements list during each weekly team meeting. We’ll provide any clarifications, if necessary, during the team meeting, as well.

If our project team was larger or the scope and development was more involved for the project, we would use a ‘Criticality Matrix’ which is a tool to help quickly assess the impact of a change on a project code stream, schedule, resource, testing, environment or other project risk factor. The Criticality Matrix involves an assessment by each of the project teams (end-user or stakeholder, business, technology, testing, etc.) and then ranked for quantitative measurement. This type of tool is helpful to normalize the decision making on a change control among the project team by expressing the decision uniformly in a quantitative model.

An example is provided on the next page.

Ite Description Requestor Business Impact Development Complexity Testing Complexity Scor


mailto:[email protected]


m e

1 Add new page for featuring … T. Brady 3 - High Value 3 - Easy to code 3 - Easy to test 9

2 Integrate XML feed for use … L. Hubbard 1 - Low Value 1 - Difficult 1 – Difficult 3

3 Adjust the color on the … N. Armstrong 2 - Normal 2 - Normal effort 2 – Normal 6

Criticality Matrix

In the example provided above, each project team area is asked to rank the requirement. A score is then determined based on the ranking. In the example above, the project team may decide that a score of 5 or higher should be considered more favorably for altering the requirements list.

As mentioned previously, this idea is only offered for suggested application in the real world, and it is not going to be used by our team due to the short nature of our course.

However, the items which were specifically adjusted for our class and justification are provided below:

ID Change Justification1 Website edit capabilities were

restricted, but the website itself will be publicly accessible.

We wanted to make the site available for inspection by the facilitator, instructor and any other team which cares to review it or provide feedback to us on it.

6 The calendar should be in sync with the EST zone.

We no longer have any project team members outside of our region, so there was no need to involve or test any members outside of the EST zone.

11

Removed the requirement for online polling.

We considered that polling via email would be suffficient and that any online polling would require time and effort beyond our schedule constraint.



PART 2. DESIGN SPECIFICATIONS

Express your design at a high level, using the notes as guidelines. Not every design fits a preconceived pattern: use common sense.

This section fulfills the tasking for Part 2 of Assignment 4.

2.1 STRUCTURAL DIAGRAMS

This section covers all of the project requirements, as of the date of this report, at a very high-level of Assignment 4.

2.2 BEHAVIOR FLOW DIAGRAMS

This section covers all of the project requirements



APPENDIX A: REQUIREMENTS DEFINITIONS

The following table provides the requirements category definitions.

Requirement Category

Definition

Business Requirements from the business that indicate what business improvement (action or capability) that the business would like to be able to do or results they would like to achieve.

Performance Describes the expectations around: Response time for a transaction (e.g., average, maximum); Throughput (e.g., transactions per second); Capacity (e.g., the number of customers or transactions the system can accommodate); Degradation modes (what is the acceptable mode of operation when the system has been degraded in some manner); Resource use (e.g., memory, disk, communications, hardware, operating system, connection, and MHz:); and Reliability/Availability.

Security Describes the security mechanism needs (e.g., Authentication, Authorization, Session Management, Data Validation, Error Handling, Logging Confidentiality, Data Handling, Encryption).

Functional Describes the capability the system will make available to the end user (includes monitoring, logging, maintainability, error handling – sometimes called “system”). Should account for the majority of requirements found in a requirements list.

Data Describes the data elements and their use including information on valid values, field sizes, minimum & maximum values and default values.

Reporting Describes the specific output needed for reporting needsRisk Describes the need for review of documentation and/or communication by

legal/risk/compliance, specific wording, form or format for communications, frequency of communications, acceptable/unacceptable forms of signoff etc

Interface Specifying the specific user, hardware, software, or communications interfaces.Normally requires a much richer medium than single text statements within the requirements so consider supplementing with a separate document(s) to adequately describe them. (includes system integration)

Operational Detailed descriptors of the SLA of an application. Examples include Business Availability, Recovery Time, Maintenance Window, Projected Business Growth, Seasonal Variation, and Transactional Volumes and Rates.



Requirement Category

Definition

Usability Specifies the required training time for normal users and power users to become productive at particular operations; the measurable task times for typical tasks; the requirements to conform to common usability standards, (e.g., GUI standards); and ease of use characteristics.

Accessibility Specifies the requirements to ensure successful access to User Interface content by people who have disabilities or varying levels of physical activity. Refer to the FeB Accessibility site (http://accessibility.fmr.com) for detailed accessibility standards and requirements.

Training Specifies the requirements to ensure appropriate training for the business requirement is addressed.

Records Management

Describes the records management needs (e.g., Categorize, Retain, Retrieve, Dispose) May also include Legal requirement for Holding records.



REFERENCES

Braude & Wiley MET CS 633 Summer 01 Distributed Software Development. Module 4. 2007.

Operations Management & Decision Making -http://highered.mcgraw-hill.com/sites/0073041912/student_view0/ebook/chapter1/chbody1/operations_management_and_decision_making.html

W3C Mark-up Validation Service -http://validator.w3.org/check?uri=berklee.edu&charset=%28detect+automatically%29&doctype=Inline&group=0

YSlow Firefox Add-on -https://addons.mozilla.org/en-US/firefox/addon/yslow/


http://highered.mcgraw-hill.com/sites/0073041912/student_view0/ebook/chapter1/chbody1/operations_management_and_decision_making.html

http://highered.mcgraw-hill.com/sites/0073041912/student_view0/ebook/chapter1/chbody1/operations_management_and_decision_making.html

Test - Word Draft - Assignment #4

Business

Transcript of Test - Word Draft - Assignment #4