wedding planning system

The Wedding Planning System

Software Requirements Specification

Version 1.0

3 May 2012

Dan CoulterSidney Haynes

Johnson HuRosy Upreti

Sepideh Deliri

Prepared forSWE 620—Software Requirements Analysis and Specification

Instructor: Dr. Frank ArmourSpring 2012

Wedding Planning System

Table of Contents1. PROJECT DRIVERS...................................................................................................................................... 1

1.1 THE PURPOSE OF THE PROJECT.............................................................................................................................11.1.1 The user problem or background of the project effort..........................................................................11.1.2 Goals of the Project..............................................................................................................................1

1.2 CLIENT, CUSTOMER, AND OTHER STAKEHOLDERS......................................................................................................21.2.1 Buyer and Owner of the System...........................................................................................................21.2.2 Customers of the System......................................................................................................................21.2.3 Other Stakeholders...............................................................................................................................2

1.3 USERS OF THE PRODUCT......................................................................................................................................31.3.1 The hands-on users of the product.......................................................................................................31.3.2 The Priorities Assigned to Users............................................................................................................41.3.3 User Participation.................................................................................................................................41.3.4 Maintenance users...............................................................................................................................51.3.5 User Hierarchy......................................................................................................................................6

2. PROJECT CONSTRAINTS.............................................................................................................................. 6

2.1 MANDATED CONSTRAINTS....................................................................................................................................62.1.1 Solution Design Constraints..................................................................................................................62.1.2 Implementation Environment of the Current System............................................................................72.1.3 Partner or Collaborative Applications...................................................................................................72.1.4 Anticipated Workplace Environment....................................................................................................82.1.5 How long do the developers have for the project?...............................................................................82.1.6 What is the financial budget for the project?.......................................................................................8

2.2 NAMING CONVENTIONS AND DEFINITIONS..............................................................................................................82.2.1 Definitions............................................................................................................................................8

3. FUNCTIONAL REQUIREMENTS.................................................................................................................... 9

3.1 THE SCOPE OF THE WORK....................................................................................................................................93.1.1 Context Diagram..................................................................................................................................9

3.2 THE SCOPE OF THE PRODUCT..............................................................................................................................103.2.1 Product Use Case Diagram.................................................................................................................103.2.2 Product Use Case List..........................................................................................................................10

3.3 FUNCTIONAL AND DATA REQUIREMENTS...............................................................................................................113.3.1 Functional Requirements Use Cases...................................................................................................113.3.2 Functional Requirements Use Case Mock-ups.....................................................................................23

4. NON-FUNCTIONAL REQUIREMENTS.......................................................................................................... 25

4.1 LOOK AND FEEL REQUIREMENTS..........................................................................................................................254.1.1 The Interface.......................................................................................................................................254.1.2 The Style of the Product......................................................................................................................26

4.2 USABILITY AND HUMANITY REQUIREMENTS...........................................................................................................264.2.1 Ease of Use.........................................................................................................................................264.2.2 Personalization and internationalization............................................................................................284.2.3 Ease of Learning.................................................................................................................................284.2.4 Understanding and Politeness Requirements.....................................................................................294.2.5 Accessibility Requirements.................................................................................................................29

4.3 PERFORMANCE REQUIREMENTS...........................................................................................................................294.3.1 Speed and Latency Requirements.......................................................................................................294.3.2 Reliability and Availability Requirements...........................................................................................304.3.3 Robustness or Fault Tolerance Requirements.....................................................................................30

Software Requirements Specification Page


4.3.4 Longevity Requirements.....................................................................................................................314.4 OPERATIONAL REQUIREMENTS............................................................................................................................31

4.4.1 Partner Applications...........................................................................................................................314.5 MAINTAINABILITY AND SUPPORT REQUIREMENTS...................................................................................................31

4.5.1 Maintenance Requirements...............................................................................................................314.5.2 Supportability Requirements..............................................................................................................32

4.6 SECURITY REQUIREMENTS..................................................................................................................................324.6.1 Access Requirements..........................................................................................................................32

4.7 CULTURAL AND POLITICAL REQUIREMENTS............................................................................................................324.7.1 Cultural Requirements........................................................................................................................32

5. PROJECT ISSUES....................................................................................................................................... 33

5.1 NEW PROBLEMS..............................................................................................................................................335.1.1 What problem could the new product cause in the current environment?.........................................335.1.2 Will the product create other problems?............................................................................................335.1.3 What limitations exist in the anticipated implementation environment that may inhibit the new product?...........................................................................................................................................................33

5.2 RISKS.............................................................................................................................................................335.3 WAITING ROOM..............................................................................................................................................34



1. Project Drivers

1.1 The Purpose of the Project

1.1.1 The user problem or background of the project effort

Fruition Wedding Planners (FWP) is a company which helps to organize successful wedding events for their clients. FWP provides guidance and helps clients in the decision making and planning processes associated with the many aspects of organizing a wedding. Currently, FWP has consultants which meet with their customer base, which represents both clients and vendors alike. These consultants are offering their services as advisers and communicators acting as a middle-man between both parties. Currently, the consultants leverage face to face meetings as well as phone calls and emails as a form of immediate communication with the customers. Custom software solutions are being used to support the consultants, in the form of a case management system which offers minimal support for tracking and managing each client's wedding event.

Over Time, the current and potential future customer base has become more technologically affluent, adapting to the internet age and breakthroughs in mobile technology. As a result there is now a high demand by the market to provide online services for customer use. FWP would like to penetrate the e-commerce market and utilize the economies of scale through the development of an online wedding planning tool. The wedding planning tool will become a system accessible online and used by consultants, vendors, and clients alike. Each user base will take a different perspective towards the tool, based on the needs of their roles within the wedding planning system. Clients will use the tool to plan out their weddings. Vendors will use the tool to market and sell their services. Consultants will use the tool to assist in interactions between both clients and vendors. Thus the wedding planning system will solve a large accessibility and communications problem for the FWP, and encourage more interactivity on behalf of all customers and expand the customer base. This solution will also modernize the FWP.

1.1.2 Goals of the Project

The System shall increase FWP's client base by 50%

The System shall increase FWP's vendor base by 20% The System shall reduce the time of planning and organizing the wedding related services

by 50% The System shall reduce the cost for clients and vendors to facilitate wedding related

services by 15% The System shall increase FWP's overall profit by 25% The System will be highly available with a 2% maximum down time for maintenance

purposes. The System shall be used for a period of at least 5 years



1.2 Client, Customer, and other Stakeholders

1.2.1 Buyer and Owner of the System

The buyer and owner for this system is the Fruition Wedding Planner Company. The FWP is responsible for 100% of the costs incurred for the development, deployment, and maintenance and operations of this project. Upon, completion, the wedding planning online system will be completely owned by the FWP.

1.2.2 Customers of the System

The customer can be broken down into two entities. The first customer group is the clients. Clients are individuals who are in the process of planning a wedding. They are paying for the services provided by the wedding planning tool in order to facilitate their planning and organization of a wedding. The second customer group is the vendors. Vendors are paying to access the online wedding system as a form of marketing and advertisement for their firm. They leverage the system to gain new business with the various clients who are looking for vendor services for the needs of their respective wedding.

1.2.3 Other Stakeholders

The roles and (if possible) names of other people and organizations who are affected by the product, or whose input is needed in order to build the product.

Users (clients) - Need to be familiar with the system in order to use it for their specific needs.

Wedding Consultants – Need to be familiar with the system from an end user perspective to perform consulting duties.

Testers – Need to understand the system flow in order to write and implement test cases during and after development.

Technology Experts – Need to understand the main needs of the customer in order to advise the best fit technological solutions for the online wedding system

System Designers – Need to understand the functional and non-functional requirements and use cases in order to break them down into software requirements and develop a software solution.

Software Developers – Need to understand the software requirements and be provided with proper tools in order to develop the software solution.

System Administrators – Need to be familiar with the administrative aspects of the system in order to maintain the system after created and assist with patches and other maintenance.

Usability Experts – Need to be familiar with the user base in order to design a UI which is compatible for the proper customers’ needs.



Representatives of external associations (vendors) – Need to be familiar with the system in order to use it for their specific needs.

1.3 Users of the Product

1.3.1 The hands-on users of the product

Fiancé and fiancée

This couple is recently engaged and is responsible for initiating their wedding planning from the engagement party to honeymoon—only if they desire to have a complete wedding planning process. They use the process-driven tool to assist them in design, planning and management of their wedding. They are responsible for specifying their desires and needs of every aspect of the wedding such as themes, fashion, vendor brands (if known to have preferences), locations, dates and etc. They can make any changes to their wedding planning on the fly. They also specify their budget and may opt out certain events to fit their budget. They can determine and choose vendors from aggregated customer reviews of the wedding vendors. They use the tool to keep track on the progress on each request they made for each vendor.

Ideally, their subject matter experience is at novice however it is possible that they will be experts of the wedding planning depending on their past experiences. At minimum, their technological experience will be at intermediate in which they use Internet and mobile devices on their daily basis as well as be familiar with social media networks.

Representative of wedding vendors

Representatives from several e-commerce supported companies, who are responsible for providing wedding services and products, will use the tool to market their services, products or both. They use this tool as their advertising space in which they can market their services and products. In addition, they use this tool as a medium to interact with their clients to learn about their background and their preferences or desires. In this system, they update the progress tracker for their services or products that were requested by their clients.

Ideally, they have intermediate to expert subject matter experience in the wedding design and planning. They are also intermediate to expert in the technological experience because they will be expected to be comfortable with using online tools as well as communication over the Internet.

FWP consulting agent

They are professionals who assist with the design, planning and management of a client’s wedding. They use their company’s content management system (CMS) to communicate with the clients and vendors. They negotiate with the vendors for the pricing and their advertisement exposure before making their name public in their aggregated databases of wedding vendors for the clients to choose from. Despite their process-driven tools for clients and vendors are flagship, they will still retain their responsibilities of tracking and managing each client’s wedding events through their CMS but at lesser degree due to the additional tools for their clients and vendors. For example, if the recently engaged couple is still inexperienced current Internet technologies



such as web applications of information sharing and user-centered designs, then the consultants of FWP will provide assistance to this couple by walking through their system’s wedding planning process. However, this is an additional responsibility to their defined main responsibilities spelled out earlier.

Clearly, their subject matter experience is advanced because they understand the overall wedding planning and what is happening under their hood. Also they are at intermediate to advanced level in terms of the web application usage so they are adept in using their content management system.

FWP System Administrator

They are responsible for managing the FWP CMS and web applications that provides tools for the clients, vendors, and consultants. They will provide technical support to the end users and maintain the security and reliability of the system. However it is required that their subject matter experience on wedding planning is none to novice, they may have more experience in wedding planning depending on their previous experience. Ideally, their technology expertise ranges from intermediate to advanced due to the technical support they provide and manage the overall FWP wedding planning system infrastructure.

1.3.2 The Priorities Assigned to Users

Key users (critical)

Client (FWP) – major influence Internal and external wedding Consultants – subject matter expert Customers (clients and vendors)

Secondary users (important) Technology experts Usability experts System administrators

Unimportant users (useful) Testers System Designers Software Developers

1.3.3 User Participation

Key users

Both Fruition Wedding Planners (main client) and wedding consultants will have large influence in how their system should be improved because they have first-hand experience with the preexisting content management system that they used to design, plan, and manage their client’s wedding. They provide business knowledge, subject matter expertise in wedding planning, and usability requirements. External wedding consultants can serve as subject matter experts also.



Users (clients and vendors) of this soon-to-be designed system will also have major impact on how tools are to be designed an integrated into the existing web application. They provide usability requirements and all high level features they would want to have in this web application. They can provide the accessibility requirements. Their depth of knowledge in the technology and wedding planning could be basis of the requirements to be developed. Their inputs are critical to the continued success of the product because customer satisfaction of using the wedding planning application can influence the profitability of this product. They are the FWP’s source of revenue.

Secondary users

Both technology experts and usability experts will use this product to determine and improve the usability experience. Technology experts will influence the design in terms of the future proof of this product. They could provide interface prototyping and usability requirements. Both however do not have much effect on their product’s long-term success as FWP, consultants and users do. Systems administrators are more concerned with the maintainability of the system to ensure the continuing success of this product but they do not have direct impact on how users will use the system.

Unimportant users

Software and systems developers, and testers will have a little to none participation in the requirement analysis due to their mutually exclusive responsibilities. They do not have the impact on what features their product is to have.

1.3.4 Maintenance users

Systems administrators are secondary users who will have somewhat indirect impact on how the product will be. Since they are sole responsible for maintaining the web applications of FWP, they will be responsible for continuing success of the product. Therefore, the maintainability, configuration management, recovery, scalability, security, supportability, and other nonfunctional requirements of the system are important for continuing success.



1.3.5 User Hierarchy

2. PROJECT CONSTRAINTS

2.1 Mandated Constraints

2.1.1 Solution Design Constraints

The product must provide a searching feature

The product must be available online.

The product must incorporate a secure payment system

The product must coordinate the wedding service on behalf of the client. The product must allow the service clients to create a profile. The product must provide budget management tool for the clients The product must provide the service client with a personalized organizer tool to manage

important events.



2.1.2 Implementation Environment of the Current System

The production web server system will be able to handle multiple connections from the clients, vendors, wedding consultants and even administrators. The hardware setup for production web server system includes multiple servers that promote availability of 98% of its production lifetime, reliability, and recoverability due to singularity hardware failure or other unforeseen circumstances. The production servers will involve database servers for data storage and mining. Clients, vendors, and wedding consultants will use their personal computers, desktop or laptop, that has a capability of running web browser with required plug-ins to interact with our product through the Internet. The administrators will have the high-end technology solutions and machines to support their administrative operations enabled by the product.

2.1.3 Partner or Collaborative Applications

PayPal Payment System

The online wedding system will require a means of providing payment both to and from FWP. In order to ensure the utmost security of these transactions the wedding system will leverage the established PayPal system to handle all monetary transactions. This is an easy service for all



users to perform transactions with and is very familiar and trusted within the online community. There is no extra charge on the users for making payments through this system however it does require them to register a credit card, or banking account with the system. For more information on PayPal, see https://www.paypal.com.

2.1.4 Anticipated Workplace Environment

They system will be available online only as a web application. This will be accessible from a variety of mediums. The most common will be the household desktop or laptop computer, however the site will have mobile accessibility as well as the ability to be accessed on tablets. Users will require some form of a mouse and keyboard in order to type searches, fill out forms, and move the cursor to navigate pages and browse links. The printer is a considerable distance from the user’s desk. This constraint suggests that printed output should be de-emphasized.

2.1.5 How long do the developers have for the project?

The contract with the FWP is approximately 1 year in total from initial design to final deployment, with follow on dates for future installments. The system will be developed under an agile development methodology with 28 day sprint cycles. This allows for delivery of milestones every month, however due the fact that there is a pre-existing system currently in production, I true transition to the next system will not be available until it is fully developed.

2.1.6 What is the financial budget for the project?

The planned financial budget for this project is 1 million dollars.

2.2 Naming Conventions and Definitions

2.2.1 Definitions

Fruition Wedding Planners (FWP) – Primary customer, who buys the system, make a majority impact on the overall design and their high level features.

Wedding Planning System (WPS) – The name of the web application product to be designed for FWP. It will provide tools for the wedding planning clients and vendors.

Wedding planning clients – The hands-on users of the WPS and their tools to design, plan, and manage their wedding. Interchangeable terms can be users or clients depending on the context.

Wedding vendors – The hands-on users of the WPS and their tools to advertise provide and manage their services and products to wedding planning clients. Interchangeable terms can be representative of vendor or consultant of vendor.

FWP consultants – The representative of FWP firm who will provide optional assistance in wedding planning to the users of the WPS. Interchangeable terms can be FWP representatives, wedding planners, and wedding planning consultants.


https://www.paypal.com/


Systems administrators – The hands-on users who have complete control over the user accounts with the account holders’ permission. They are responsible for the management of the accounts and maintenance of the WPS. Also they are responsible for providing technical support to the users.

3. FUNCTIONAL REQUIREMENTS

3.1 The Scope of the Work

3.1.1 Context Diagram



3.2 The Scope of the Product

3.2.1 Product Use Case Diagram

3.2.2 Product Use Case List

User Feedback System- Used for feedback entering whenever users has an opinion on the Wedding Planning Service (WPS)



Pay For Services- the operation thru which the users select to pay by PayPal or credit card

Utilize Budget Management Tool- Used to track vendor and purchases counting toward the wedding.

Utilize Personal Organizer Tool- Used to organize wedding date events and modify events created automatically and by users and features calendar features

Perform Smart Search- Perform a site wide search for something related to the wedding planning site offering advanced (contextual search) and title of page based searches

Register for account- The interface used to create an account that is used to access wedding services

Modify User Interface- Provides a method for the client to update the user interface for their wedding settings which are viewable for the world

Send Notification- The system will notify the user whenever an important event occurs for data related to their account being created or modified.

Remove User Account- The administrator is allowed to cleanup account information when a user request to have account deleted.

Add User Account- Used to from the back end create user accounts that are not normal users (administrators, consultants, and vendors)

Modify User Account- Used to change user settings across their account

Modify Web Interfaces- Used for administrators to change the look and feel of the overall site through a CMS

Apply Patches/Releases- Used for patching bugs in existing system and deploying new releases to the server.

Send Paycheck to Employees- Used to pay WPS employees their paycheck

Create Personal Profile- The personal profile used to determine features capable of being used inside of site

Login- If the user would like to access services they must use user name and password to make changes and plan wedding events

3.3 Functional and Data Requirements

3.3.1 Functional Requirements Use Cases

Use Case Name: RegistrationUnique Use Case ID: UC001Brief Description: The user registers to the system.



Actor(s): ClientPre-Conditions: NoneMain Flow of Events:

1. The system asks user for personal information(Name, Address, Phone number, …)2. The user enters the requested information.3. The system asks the user to define a username and password.4. The system asks a security question from the user (it will be used when the user forgets

his password).5. The user answers the security question.6. The user enters username and password.7. The system asks for the type of the package that the user wants to register for.8. The user chooses a package type.9. The system registers the new user.

Alternative Flows and Exceptions:1. Should the user enter a username that is used by another user before, the system asks for

a new username from user.2. Should the user enter a password that doesn’t meet the basic password format, the system

asks for a new password from user.3. Should the user hits cancel button before entering all information. The system will not

register the user into the system.4. Should the user’s personal information is exactly the same as a user that has already been

registered into the system. The system gives a message that the user is registered to the system before.

Development Constraints: Requires all the personal information about the user to be stored in the database for future use.Source: Requirements Elicitation meeting

Include Use Case Name: Log inUse Case ID: IUC-10Brief Description: The user enters a valid username and password and logs into the system.Actor(s): ClientPre-Conditions: The user has been registered to the system.Main Flow of Events:

1. The system displays prompts for the User.id and User. Password; The LOGIN button is displayed as well.

2. The user enters username and password and hits the LOGIN button.3. The system checks for the username/password validity and verifies user’s access rights.4. The system allows the user to log into the account and displays the overview of user’s

account.Alternative Flows and Exceptions:

1. Should the user enter a wrong username/password, the system asks for entering username and password again.

2. The user enters wrong password for 3 times. The system asks the security question from the user and if the answer is correct the system will send a new password to the user’s email.



Development Constraints: NoneSource: Requirements Elicitation meeting

Use Case Name: Create personal profileUnique Use Case ID: UC003Brief Description: The user creates the personal profile that will be used by the systemActor(s): Client, vendor, consultantPre-Conditions: User is logged in successfully and authorized to create their personal profileMain Flow of Events:

1. The system presents the user with Create personal profile option 2. The User provides his/her personal information. 3. The System based on the information provided by the user creates the Personal profile for

them.Post-Conditions: The system creates the personal profile for the userDevelopment Constraints: Requires the different page to be created where the user can fill their personal information. Source: Requirements Elicitation meeting

Use Case Name: Perform budget managementUnique Use Case ID: UC004Brief Description: The user types in values for various budget fields and submits the calculator. The system then performs an internal calculation based on data available from the user and returns an available balance.Actor(s): ClientPre-Conditions: User is logged in successfully and authorized to use the budget management tool.Main Flow of Events:

1. The user types in an overall budget value.2. The user steps through each field for which a wedding feature is available and inputs the

amount of money spent towards that particular aspect.3. The user selects the calculate button with the mouse or keyboard.4. The system performs an internal calculation against all spending fields versus initial

available budget.5. The system sends the resulting calculations to the budget page.

Post-Conditions: The system displays the results of the search. This includes the overall remaining budget as well as a budgetary suggestion of the amounts to be spent towards any remaining wedding features.Alternative Flows and Exceptions:

1. Should the user input anything other than a numerical value, they system will prompt the user for currency.

2. Should the resulting calculation be negative (client has overspent) the resulting display will notify that the current path is over budget and suggest a solution that is within the specified budget.



Development Constraints: Requires these fields to be stored in the database in order to save the users budgetary preference over time. Source: Requirements Elicitation meeting

Use Case Name: Perform smart search Unique Use Case ID: UC005Brief Description: The user types in a string of text and submits the search. The system performs an internal search of the data available to the user and returns a list of results in the form of links.Actor(s): ClientPre-Conditions: User is logged in successfullyMain Flow of Events:

1. The user types in a string of text as a search input. 2. The user selects the submit button with the mouse or keyboard.3. The system performs an internal search against all searchable data within the database.4. The system sorts the results and returns them to the search page

Post-Conditions: The system displays the results of the search.Alternative Flows and Exceptions:

1. Should the user input an empty string for a search the search will return an empty list to the search page, a prompt to enter search text will appear on the screen.

2. Should the search produce no results an empty list will be returned to the search page, Text will appear on the resulting screen displaying that the search yielded no results.

Development Constraints: Requires the searchable data in the database to be index-able in order to perform efficient results. Source: Requirements Elicitation meeting

Use Case Name: Utilize personal organizer toolUnique Use Case ID: UC006Brief Description: The user types updates for dates in personal organizer toolActor(s): ClientPre-Conditions: User is logged in successfully and authorized to use the personal organizer toolMain Flow of Events:

1. The user types in wedding date2. System calculates default/latest dates that events should be planned.3. The user steps through each of the dates when is the latest a task needs to be completed4. The user is allowed to customize dates based on preference.5. The user clicks on an event for more information on event vendors 6. User enters information about their event and quotes are sent to vendors.7. The system throws in hints about additional events and things that may be interesting

facts that relate to the users wedding on dates8. The system sends the vendor quotes to the user when complete and updates the

information inside the calendarPost-Conditions: The system displays the events dates that are needed for the wedding.Alternative Flows and Exceptions:



1. Should the user decide the Consultant can complete the steps of planning for the client? This service requires a more expensive package.

Development Constraints: Requires a calendar and planner be created and tracked in database. Create a default location of wedding event that are typically planned by wedding clients.Source: Requirements Elicitation meeting

Use Case Name: Input feedbackUnique Use Case ID: UC007Brief Description: Users provide feedback about the websiteActor(s): Client, vendor, consultantPre-Conditions: User is logged in successfullyMain Flow of Events:

1. The system provides the users with a page where they can provide feedback.2. The users enter their opinions about the website in the page specified by the system

Post-Conditions: The system displays the feedback of the users.Development Constraints: Requires the separate web page where users can input their feedback.Source: Requirements Elicitation meeting

Use Case Name: Send NotificationUnique Use Case ID: UC008Brief Description: The client gets notification from the system based on inference whenever an important event is created or modified, such as the case of vendors updating their price or quantity of their product or service. Also if a system administrator updates/deletes existing data and/or changes user preferences or applied patches/releases then the corresponding notification is sent to client user. The system will also send notification for any updates done by wedding consultants on the events as well as their contents.Actor(s): Client, vendor, consultant, adminTrigger: Whenever an important event or content is created or updated from the relevant vendor, consultant, or system administrator.Pre-Conditions: The system is operational. The user must have authentication rights and client is a paid member.Main Flow of Events:

1. The logged in non-client user is entering new content, editing an existing content, changing user preferences or applied patch.

2. Once the user does all the modifications, they click the submit button.3. All the changes are saved if there is no validation error (alternative flow)4. System sends notification to other users based on client’s package membership.5. Notification is in the form of SMS and email for gold package membership and only

email for both silver and bronze package membership.Post-Conditions: The notification has been successfully sent to the client user in form of e-mail (silver and bronze package membership only) or in form of SMS and e-mail (gold package membership only)



Alternative Flows and Exceptions:1. Should there be validation error, it will display to user the error along with its description.2. User corrects the error and clicks on the submit button3. Should there is no validation error, all the modifications are saved else the user is

required to repeat the process.Non-Functional Requirements: The notification message should be generated within 60 seconds of the recent relevant change. System administrators should have a permission from the client to modify their profile and user preferences.Priority: HighAssumptions: N/AIssues: N/ASource: Statement of work, Requirement elicitation meeting (4/1/2012)

Use Case Name: Manage user accountsUnique Use Case ID: UC009Brief Description: The admin perform basic account management operations, which includes creating new user account and also editing, and deleting user account. Actor(s): adminTrigger: A new user account is requested. Change of the information or content of existing account is requested. Delete this account is requested.Pre-Conditions: The system is operational and policy is in place to accept new users and manage their accounts. The admin is given authentication rights and the account to be managed exists in the system.Main Flow of Events:

1) The admin logs into the FWP system with his/her credentials2) The admin arrives to its main interface with all administrative functions.3) The admin clicks on manage accounts link.4) The admin is given a list of user accounts 5) If the admin wants to create an account. (See alternative flow ‘a’).6) If the admin wants to modify an account (see alternative flow ‘a’).7) If the admin wants to delete an account (see alternative flow ‘b’).8) When the account management operation is completed, the admin can return to the main

administrator interface.Post-Conditions: The user data is stored in the user account in the system and notification is sent to the appropriate client via email or SMS depending on their package membership.If the user data is invalid then no account will be created. No notification is sent to the appropriate user.If the user data or account has been deleted then the account no longer exists in the system. The notification of this is sent to the appropriate client.Alternative Flows and Exceptions:Alternative flow ‘a’ (admin enters invalid user account information or preference)

1. The system describes which entered data was invalid and presents the admin with description and suggestions for entering valid data.

2. The system prompts the admin to reenter the invalid information or preference.



3. The admin reenters the information or preference and the system revalidates it.4. If valid information is entered, the user account information or preference is stored.5. If invalid information or preference is entered, the system invalidates it and the

alternative flow ‘a’ is executed again. This will repeat until all user information or preference is valid. Or the admin cancels the change action (see alternate flow ‘c’).

Alternative flow ‘b’ (the admin cannot delete the account because of restrictions)1. The system will display the restrictions on the account that cannot be deleted.2. The deletion process is discontinued and the user account remains unchanged.3. The system notifies the appropriate client that the admin canceled the account deletion

request.Alternative flow ‘c’ (the admin cancels the change action)

1. At any time, the admin may cancel the account creation, deletion, or change. 2. If it happens, the processing is discontinued and the user account remains unchanged (for

change or delete request).3. The notification of request cancellation is sent to the appropriate client.

Non-Functional Requirements: The system should be able to handle 10 admin requests concurrently.Priority: HighAssumptions: N/AIssues: N/ASource: Requirement elicitation meeting

Extending Use Case Name: Add user accountBase Use Case Name: Manage user accountsExtend ID Number: UC009-E1Base ID Number: UC009Brief Description: The admin is requested to create a new user account and add it into the current list for this system. This is one of the basic account management operations.Pre-Conditions: The admin is granted permission to add account and this new account does not exist in the system yet.Additional Actors (not found in base flow of events): N/AFlow of Events:

1. The admin clicks on create a user account link.2. The admin enters the required user account information values.3. After all required form is filled, the admin click on submit button. 4. The system validates all the values and displays a successful message if no error is found.5. The system stores the user account information.6. The system notifies the client that the account has been created.

Post-Conditions: The user data is stored in the user account in the system and notification is sent to the appropriate client via email or SMS depending on their package membership.If the user data is invalid then no account will be created. No notification is sent to the appropriate user.Priority: Medium



Extending Use Case Name: Modify user accountBase Use Case Name: Manage user accountsExtend ID Number: UC009-E2Base ID Number: UC009Brief Description: The admin is requested to modify a particular user account by changing its preferences or information. This is one of the basic account management operations.Pre-Conditions: The admin is granted permission to modify account’s information or settings and this account has to exist in the system.Additional Actors (not found in base flow of events): N/AFlow of Events:

1. The admin clicks on change account settings link.2. The system displays to the admin all the existing accounts they can change like email,

name, password, permissions, and etc.3. The admin select an account to be modified and it displays all the user account

information and preferences.4. The admin selects any one of the user account information or preferences and proceeds

with modification.5. Once the admin has done all the changes they intend to do, they click on submit changes

button.6. The system validates all the changes and displays a successful message if no error is

found.7. The system sends a notification to the relevant client informing them about the changes

made in the preferencesPost-Conditions: The user data is stored in the user account in the system and notification is sent to the appropriate client via email or SMS depending on their package membership.If the user data is invalid then no account will be created. No notification is sent to the appropriate user.Priority: Medium

Extending Use Case Name: Remove user accountBase Use Case Name: Manage user accountsExtend ID Number: UC009-E3Base ID Number: UC009Brief Description: The admin is requested to remove a particular user account from the system. This is one of the basic account management operations.Pre-Conditions: The admin is granted permission to remove the particular account and this account has to exist in the system.Additional Actors (not found in base flow of events): N/AFlow of Events:

1. The admin clicks on delete an account link.2. The system displays to the admin all the existing accounts they can delete.3. The admin selects one account to be deleted.4. The account clicks on the delete button.5. The system deletes the user account information.6. The system notifies the client that the account has been deleted.



Post-Conditions: If the user data or account has been deleted then the account no longer exists in the system. The notification of this is sent to the appropriate client.Priority: Medium

Use Case Name: Send paycheck to employees Unique Use Case ID: UC010Brief Description: The system runs the payroll periodically to pay the admin and consultant for their hours charged in servicing the clients through this system. Actor(s): Client, consultant, adminTrigger: Whenever a pay cycle for each user type reaches to the end and it’s time to run the payroll.Pre-Conditions: The system is operational. The user must have charged the hours appropriately and has complied with labor charging policies. The admin or consultant must be eligible employee of the system.Main Flow of Events:

1. The system retrieves all employees who are to be paid at the end of pay cycle.2. The system calculates the pay based on current week timecards, employee information

(salary, benefits, and etc), and all legal deductions.3. Depending on the employee’s payment method (direct deposit or mailing) the system

sends the bank transaction to its payment system for processing (see alternative flow if the payment system is down)

4. The transaction for the employee (admin or consultant) to receive their pay is processed.Post-Conditions: The eligible employee is paid at the desired time.Alternative Flows and Exceptions:

1. If the payments system is down then the system waits for the specified duration before the attempt to retransmit the bank transaction.

2. If the payment system becomes available, the system will resend the bank transaction.3. If the payment system is still down, the system repeats the wait duration process before it

retransmits the transaction.Non-Functional Requirements: The system should be able to process multiple payroll operations up to the number of its total employees concurrently.Priority: HighAssumptions: N/AIssues: N/ASource: Requirement elicitation meeting

Use Case Name: Pay for servicesUnique Use Case ID: UC011Summary: User pays bill for wedding planning serviceActor: Client, VendorPrecondition: wedding planning service is functionalDescription:

1 User browses to the payment page2 System queries for the user account details and calculate the amount due based on user



role and package subscriptions.3 Display shows the service fee to the user4 <<payment>>5 System updates payment information in user account6 System displays thank you page to user

Alternatives:1. If an invalid payment is used, the system will maintain that user owes fees2. If the system is shut down for any reason, the system will not enforce payment due dates

until it becomes accessible again. Postcondition: User maintains access to the wedding planning system.

Extending Use Case Name: Pay by Credit CardBase Use Case Name: Pay for servicesExtend ID Number: UC011-E1Base ID Number: UC011Summary: User pays via credit card for services purchased on the wedding planning systemActor: Client, Vendor, Credit Card SystemPrecondition: Wedding planning system is functionalDescription:

1. User enters credit card and billing information and submits to the system.2. Wedding planning system reads in user account information and credit card data.3. Wedding planning system sends credit card data to credit card system.4. Credit card system validates credit card data and returns result to wedding planning

system.5. Wedding planning system validates credit card data.6. Wedding planning system displays receipt.

Extending Use Case Name: Pay by PayPal Account for services purchased on the wedding planning systemBase Use Case Name: Pay for servicesExtend ID Number: UC011-E2Base ID Number: UC011Summary: User pays via PayPal accountActor: Client, Vendor, PayPal systemPrecondition: Wedding planning is functionalDescription:

1. User enters PayPal credentials2. Wedding planning system reads in user account information and PayPal account

information.3. Wedding planning system sends PayPal data to PayPal system.4. PayPal system validates form of payment data and returns result to wedding planning

system.5. Wedding planning system validates payment data.6. Wedding planning system displays receipt.



Use Case Name: Apply patches/releasesUnique Use Case ID: UC012Brief Description: The admin typically installs patches to the system.Actor(s): AdminPre-Conditions: System is able to be taken down for a maintenance window.Main Flow of Events:

1. The admin sets timeframe for user logoff.2. The admin sends a please logoff message to users3. The admin disables system login for new users and account creation.4. The admin closes system after timeframe and users auto logged off5. The admin cause the system to shutdown 6. The patch is installed7. The system is rebooted and users are allowed to create accounts and logon.

Post-Conditions: Patch has been successfully installedAlternative Flows and Exceptions: NoneDevelopment Constraints: Requires a patch that can be applied when system shutdown. Also requires that method to turn off logon and account creation be created. Also requires that auto logoff timer be created.Source: Requirements Elicitation meeting

Use Case Name: Modify web interfaces (admin)Unique Use Case ID: UC013Brief Description: The admin will modify the website style, flow and widgets loaded.Actor(s): AdminPre-Conditions: System is able to be taken down for a maintenance window.Main Flow of Events:

1. The admin sets timeframe for user logoff.2. The admin sends a please logoff message to users3. The admin disables system login for new users and account creation.4. The admin closes system after timeframe and users auto logged off5. The admin cause the system to shutdown 6. The CMS changes are made7. The system is rebooted and users are allowed to create accounts and logon.

Post-Conditions: Website CMS has been successfully updatedAlternative Flows and Exceptions: NoneDevelopment Constraints: Requires that a CMS is part of the system to accommodate style changes. Source: Requirements Elicitation meeting

Use Case Name: Modify user interfaceUnique Use Case ID: UC014Brief Description: The user performs editing his/her account.



Actor(s): UserTrigger: change of the information or content of existing account is requested. Pre-Conditions: The system is operational and policy is in place to accept managing accounts from user side. Main Flow of Events:

The user logs into the FWP system with his/her username/password.2) The user clicks on change account settings link.3) When the user has done all the changes, they click on “Submit” button.4) The system validates all the changes and displays a successful message if no error is

found.5) The system sends a notification to the relevant client informing them about the changes

via email.

Post-Conditions: The user data is stored in the user account in the system and notification is sent to the appropriate client via email or SMS.

Alternative Flows and Exceptions: If the information entered by the user is not valid, the system describes which entered

data was invalid and presents the user with description and suggestions for entering valid data.

If the user clicks on “Cancel” button, no change will be submitted.

Non-Functional Requirements: The system should be able to handle 10 user requests concurrently.Priority: MediumAssumptions: N/AIssues: N/ASource: Requirement elicitation meeting



3.3.2 Functional Requirements Use Case Mock-ups

System Planner



Smart Search



Advanced Search

4. NON-FUNCTIONAL REQUIREMENTS

4.1 Look and Feel Requirements

4.1.1 The Interface

Fruition wedding planner shall help planning a wedding day easy and trouble free thereby reducing the stress involved with preparing one of the most important days in life. All kind of information including the management of the events, roles and seating arrangements, budget setting and expense tracking, gift management shall be provided in one site that ultimately saves the time of the wedding couples. Also, the information about the vendors shall be organized to ensure that the wedding and event specifics are handled smoothly and professionally. From the vendor page, client can send an email and view a map of the vendor’s address. Vendor information shall also appear in the Budget so that the client can identify the respective vendor while adding expenses. Fruition wedding planner also helps in scheduling the suitable honey moon vacations thereby attracting the newly married couples.



4.1.2 The Style of the Product

The wedding planning tool markets exclusively to engaged couples, so the look and feel requirement serves as a means to really move towards ‘romancing the product’. The user should get a feeling that love is in the air when they approach the website. The site should have bright colors and a happy mood, utilizing pinks and reds and other colors universally associated with love. The main intro pages for newcomers should be conservative in order to appeal to the diverse set of users visiting the site; however it should make very clear the association with the website and weddings. Another useful tool is to cycle through pictures of weddings with people of all different cultures in order to appeal to any audience. It is also important to note that engaged couples are making a lot of wedding decisions and that this is an extremely important event for them, where they want to have a feeling of full control. For this reason, the website should adhere to their wants, being very customizable, allowing them to have pages which meet their own style needs. This feature is vital because it allows the styling of the product to vary based on the tastes and preferences of each new user. Likewise, the vendors will want to market their services in their own layout with their own logos and information. A very customizable site will be able to adhere to all parties needs.

4.2 Usability and Humanity Requirements

4.2.1 Ease of Use

All user groups

The product shall have efficient user interfaces that require least amount of clicks or steps to complete common tasks.

The product shall have minimal overall number of content where appropriate. The product shall have efficient use of screen estate when displaying content, interfaces,

and widgets. The product shall have efficient paths created for core tasks. The product shall provide effective help and instructions throughout the navigation

schemes. Each common task performed on the product shall be clearly explained in series of well-

defined steps similar to wizard paradigm, the setup assistant. The product shall minimize the number of duplicated efforts or unnecessary manual labor

when navigating through the interfaces, making changes to settings, using their tools, creating/editing the content, and using their communication system.

The product shall have simplified interface or dashboard with relevant cues to keep the users’ feet on the ground.

The product shall have interface and architecture that are quickly and easily adopted by the users.

All tools and widgets such as budget planner, scheduler, and sophisticated search function in the product shall be easily accessible to the users.

The product shall provide less overwhelming help and instructions to the first-time users. The product shall restrict the customization of the content structures and interfaces for the

first-timers. The product shall enable customization of the content structures and interfaces for the



individual user groups at adequate time. The product shall have content structures and tools/widgets tailored to different but

specific needs of the individual user groups—wedding planning clients and wedding vendors depending on their frequency of use.

The product shall not require the wedding planning clients and wedding vendors to have technical knowledge or development skills to perform their common tasks on their component.

The product shall provide consultants (authors) with tools to manage the site in a non-technical way.

The product shall support both frequent and infrequent users. The frequency of the user usage of the product shall determine the amount of complexity

of the content structures and interfaces that is adequate to them. The product shall provide a capability to let the frequent users increase the complexity to

their liking while maintaining minimum complexities for the infrequent users. The product shall have interfaces and architectures that match the user’s mental model

which should come naturally to them at initial look. The product shall have content structures and arrangements that are intuitive and logical

to the users. The product shall have a simple registration process that is straightforward and

completely relevant for all user groups. The product shall have a simple log-in process with painless and quick password

recovery for all user groups. For wedding planning clients and wedding vendors, the product shall shield them from

technical complexities while providing them a set of powerful and adequate functions. The product shall be flexible to the user groups when it comes to handling different

navigation schemes and web-accessibility-friendly techniques. The training sessions and tutorials provided by this product shall be at very minimal.

Wedding planning clients

The product shall enable wedding planning users to complete common tasks from establishing budget tool to researching for vendors without relying on third-party assistance or support for 90% of their entire experience.

The product shall enable intuitive personalized browsing experience for wedding planning clients including the ease of browsing through services and products offered by high volume of vendors.

The product shall have a very brief but concise optional tutorial on setting up their profile, setting their preferences, and using their tools for wedding planning clients.

Wedding Vendors

The product shall have brief but concise tutorial on content authoring of the advertisement space and online store for wedding vendor users.

The content authoring function provided by this product shall be logical to the wedding vendor users.

The product shall have a very brief but concise optional tutorial on setting up their profile and using their tools for wedding vendors.



Wedding planning consultants (FWP)

The product shall have a dashboard with content interface and widgets organized logically for the wedding planning consultants.

The product shall provide wedding planning consultants intuitive and fast responsive tracking system for his or her clients as well as vendors.

The product shall provide consultant users ability to have complete site visualization of the CMS environment.

The product shall have short but concise training on content authoring of the data relevant to wedding planning process for wedding consultants.

Systems administrators

The product shall enable administrators to be self-sufficient in solving technical issues without a little or no need external assistance (software developers of this product).

4.2.2 Personalization and internationalization

The product shall support English and Spanish The product shall allow the user to select between available languages The product shall support personalization of web page by users The product shall adapt to words and phrase used by the user The product shall accept all major currencies The product shall provide currency conversions The product shall track users preferences by cookies and remember for future sessions The product shall offer different packages for a diverse set of client needs The product shall retain the buyer's package selection The product shall retain the clients vendor preferences

4.2.3 Ease of Learning

The person entering the data for their wedding should not have to waste time figuring out how the system takes input. The system should provide a walk thru interface that walks the customer thru the system and steps to organize and create a wedding. The customer should not have a problem interpreting the information required to plan their wedding. If he/she doesn’t have much knowledge about the computer, he can input into the wedding information data in a few hours and each step of the wedding should notify that all the information has been entered. This system should be designed that the Wedding planning administrators/moderators can start working with half day training at the first day. “Working” means that the Wedding Managers can add modify wedding planning information on photography in order steps of how a wedding in organized in phases. The project shall also be easy to use by wedding planners to add new capability and spaces to the website. The administrators will have a CMS (Content Management System) style interface with walk thru tutorial for how to change page settings and layouts for the entire site.

The product will be built with a tutorial and online help. And the system user interface should be designed simple an understandable as the input on a “things to do list”. At the top of the page is a breakdown of all steps that need to be complete as icons.



The product shall be easy for a bride to learn. An admin shall be able to manage all the separate accounts The bride shall be productive at organizing wedding in a short period of time. The product shall be able to be used by any public member as well as wedding

organizers. After receiving no training a client shall be able enter their input into the walk thru style

forms in minutes. The administrator shall achieve have a minor amount of tutorial and shall take around an

hour to train.

4.2.4 Understanding and Politeness Requirements

The fruition wedding planner shall be intended in organizing the successful wedding events for their clients without having them to bother with the technical difficulties associated with the projects. The website shall be simple and user interactive that could be easily understandable by the user community. The users shall use the simple process driven tools that would assist them in designing, planning and managing their wedding. The website shall use symbol and words that are naturally understandable by the user community. The technicalities associated with the detail construction of the system shall be hidden form the users.

4.2.5 Accessibility Requirements

The wedding planner website shall consider browser Compatibility (like compatibility with Internet Explorer, Firefox, Opera, and Safari). Also, we have to consider that not everyone is using the latest version of these browsers and our website has to be designed in a way that it can be accessible to the users who are not using the latest versions of the browsers. It is also practical that our website is equipped with a sitemap that shows the main sections of the website in order to help the users to have an idea of the whole website. Consistency for the structure and navigation across all pages of the website should also be considered. Images that convey important information should have alternative text giving information about the content of the image. Any of the forms in the website should be accessible to all the users. A website visitor may decide to fill out a form through the website and if the form is not accessible to him/ her, the website may lose a potential customer. We shall design our website in a manner that the users can quickly get the necessary information they need by just scanning the page. We shall use headings, bullet points or bold texts to help the users get the necessary contents faster.

4.3 Performance Requirements

4.3.1 Speed and Latency Requirements

The Wedding Management System must output responsive feedback to input on wedding pages within a reasonable duration of time. We will measure latency as the time period between when the user click out of a particular form field and an asynchronous message can be sent to the server to validate the user’s information. Until further discussed with the client, we will define the longest appropriate latency to be thirty seconds.



Should the user interface be unable to meet the requirement, the developer of this project must adapt a form submittal version of verification where the entire form is submitted and the user input is returned along with incorrect data.

Any interface between a user and the Wedding system on each form will have a max 30 second response time

The response shall be fast enough to avoid interrupting the user’s flow of thought The product shall provide informative feedback

Fit Criterion - Amount of time on form response

4.3.2 Reliability and Availability Requirements

The wedding planner website must be accessible and up and running 24 hours a day, 7 days a week and 365 days a year. Also, Web software and its accessibility by diverse types of web browsers is also a main consideration. It is a good habit to remove unique features to a particular Brower to ensure that different users won’t have any problem to access the website. Therefore, we have to guarantee cross-browser availability which is simply defined as the website accessibility to users through different browsers in differing times. Also it should be considered that the wedding planner website is offering a valid or reliable source of information. To ensure reliability, the website material has to be updated regularly in order to have recent contents and information as customers expect to see fresh and up-to-date information. In the case of accuracy which is an inevitable factor in reliability, the information in wedding planner website has to make sense and if there is any link to any other reliable site, it has to be relevant to the content of our website.

4.3.3 Robustness or Fault Tolerance Requirements

The product shall continue to operate in local mode whenever it loses its connection to the main servers.

The product shall re-establish acceptable performance after faults or abnormal happenings during the transactional processes with wedding planning clients and vendor users, and wedding planning consultants.

The product shall auto save the content authored by the wedding planning consultant at the adequate time.

The product shall be able to auto-save the user’s recently changed content where appropriate successfully 98% of the time.

The product shall auto-save any current unfinished contents on the page as draft before the user transitions to a different page.

In the event of abnormality or fault, the product shall recover data and make it available as soon as possible.

The product shall ensure that recovered data are intact and not corrupted as if data has not changed since the abnormal event.

The product shall display clear human-readable error messages that are relevant each user group type.

The product shall provide administrators suite of tools to monitor the health of the active applications, running server mainframes and troubleshoot any technical issues within the application.



The product shall have planned back-up and recovery of the user data for all downtime maintenance.

The product shall have hardware redundancy and replications of the servers and applications in case of the data corruption or loss of power.

The product shall have dynamic load balancing to regulate the flow of requests and responses during peak hours.

The product shall enable server partitioning and clustering to increase the availability of services and resources.

4.3.4 Longevity Requirements

Fruition wedding planner shall be expected to operate within a maximum maintenance budget for a minimum of five years.

4.4 Operational Requirements

4.4.1 Partner Applications

The Wedding Planning System must be able to interface with the PayPal payment system. The two systems must be able to transfer account information, purchase totals, and provide for complete and secure payment transactions. This interaction will be handling extremely sensitive data and will be used quite frequently (every transaction). The amount of information will not be large in volume. Basic account information and authentication will be necessary.

The Wedding Planning System must be able to interface with various vendor systems in order to retrieve data or make selections for products and services. This will be a very common interaction and in some cases depending on the vendor, can involve a large amount of data retrieval. The medium suggested for now is to provide a service based architecture allowing the Wedding Planning System to request data from the vendor systems on an as needed basis. This will reduce the amount of transactions as much as possible and keep the traffic overhead to a minimum.

4.5 Maintainability and Support Requirements

4.5.1 Maintenance Requirements

Computer hardware will require to be maintained on a host that is available 24X7. There will be data backups that need to be kept for the different forums as well as user data that will need to be kept so some form of database maintenance will be required. An new or software glitches will need to be reported and DRs written for fixes so some form of follow on maintenance contract for fixes will need to be built in or negotiated.

Motivation - To make everyone aware of the maintenance needs of the product.

Examples

New User accounts must be available upon creation on webpage All data must be maintained for security reasons for five years. Current capabilities must be able to be patched at night during weekly outages.



4.5.2 Supportability Requirements

The product shall allow users to create new workflows without the need for additional programming.

The product shall allow effective and efficient maintenance and support of the system. The product shall have installation and maintenance of the system done by the systems

administrators. The product shall designate systems administrators as the help desk for the wedding

planning clients, vendors, and consultants. The product shall designate the small team of software developers, who have developed

this product, to be the external support team for the systems administrators. For the most of the time, the product shall be self-supporting to wedding planning clients,

vendors, and consultants due to series of well-defined steps offered online.

4.6 Security Requirements

4.6.1 Access Requirements

Our website must have members-only areas. We want our visitors to have to sign in to see and access to our whole website. Some of the users can go for specific areas of our site. Some of them are not allowed to access these areas. So, we are simply using secure password protection for the members-only areas and as we have different types of users like customers, internal or external wedding planners, system administrators, we will have different types of access defined for each group accordingly.

4.7 Cultural and Political Requirements

4.7.1 Cultural Requirements

The fruition wedding planner being a web based company is centered to the people of different cultural background of all over the world. The wedding planner shall not be offensive to religious and ethnic groups and shall take into account cultural identity, values and norms of different users who would be interested towards the system. The system shall try to integrate the cultural specific style and traditions associated with the wedding ceremony of different varieties of people all around the world.

5. PROJECT ISSUES

5.1 New Problems

5.1.1 What problem could the new product cause in the current environment?

The development of online wedding planning system will affect the employment opportunities of the sales representatives who used to meet with clients and vendors in person as the pre-packaged wedding service is provided online to the clients. Also, the creation of new system



software components and any changes made to will affect the performance of the existing hardware components.

5.1.2 Will the product create other problems?

Fruition wedding planning system may sometime be fraught with the potential problems such as security risks, cancelations, equipment failures, and other problems introduced by the various parties involved in the system. Extensive increase in the demand of the clients may sometime cause the system to slow down.

5.1.3 What limitations exist in the anticipated implementation environment that may inhibit the new product?

The implementation environment for the system is not known at the time of this writing therefore we cannot state exactly its limitations. We expect that the existing infrastructure will be needed to update to meet the increase loads of the newly developed software and the improved clientele demands.

5.2 Risks

Inaccurate metrics (25%) there is a real probability that the metrics used in measuring both the success and the progression of the development of the system will prove to be inaccurate

Scheduling (25%) it is likely that the scheduling will go through various changes throughout the development process before the true deadlines are established. This will likely be largely dependent on other risk factors such as requirements creep and inaccurate requirements

Scope Creep (10%) the requirements may grow beyond the acceptable scope especially if no firm boundaries are set. Unfortunately, as the scope grows more tasks will follow and ultimately the budget and schedule will suffer.

External Interfaces (50%) some of the development will be done to interface with 3rd party vendor products and or systems. During this process the external systems will be required to develop or troubleshoot interfacing issues as well. This can be tricky because the risk now resides on a team which is not directly managed by development. It would be good to note that it is quite possible for scheduling to expand due to unforeseen issues with external systems.

Communications Barriers (5%) in all environments maintaining open and clear communications is a struggle. This can fall into the requirements, development, test, deployment, integration, or even management realms. It can be assumed that occasionally miscommunications will occur between parties causing backlash to the quality or schedule of the project.

5.3 Waiting Room

One of the requirements established in the SOW for the Wedding Planning system is as follows;

'The System should.... ….be easily used by all kinds of users from different parts of the world.



After further discussion it was determined that English would be the standard language for the interface for the first iteration with the option for clients to implement their own language when personalizing their profiles and any other pages. However, a future requirement is to meet the initial needs of the stakeholders and bring on linguists to translate the various interfaces within the Wedding Planning System and therefore become more inviting to prospective clients from all across the world.

When discussing the various aspects of planning a wedding the customers agreed to and prioritized a list based on preliminary studies by the systems engineers. However, some of the features were left out in the prioritization process. They are still important pieces to many weddings and will be captured here for future development.

Venue listing for reception and wedding/ events

RSVP/Save the date service Address book manager for invites Dress an Tux order Wedding decor organization make up vendor services limo services wedding gallery showcase

Another requirement for the wedding planning system is to incorporate an expansive search capability. The customers specified during a requirements elicitation session that they would like the search to encompass all internal data within the system boundaries. Thinking into the future it has been decided that expanding the search to perform a Google-like search would be useful. Also the ability to crawl and index data for the purposes of performing relevancy searches and persistent searches or scheduled searches are also future features to consider.

The initial wedding planning system is going to be a browser based website accessible from and internet devices but targeted towards users with laptops and computers. A future phase would be to build applications or mobile-based versions of the software so that users with mobile technology will be able to easily access and leverage the wedding tool sets.


wedding planning system

Documents

project constraints62

project drivers11

project issues335

project effort11

project driversthe purpose

product use case diagram103

product use case list103

software requirements