100) Wedding Planning

The Wedding Planning System
Wedding Planning System
Table of Contents
1. PROJECT DRIVERS ......................................................................................................................................... 1
1.1 THE PURPOSE OF THE PROJECT ...............................................................................................................................1
1.1.1 The user problem or background of the project effort...........................................................................1
1.1.2 Goals of the Project ................................................................................................................................1
1.2 CLIENT, CUSTOMER, AND OTHER STAKEHOLDERS ........................................................................................................2
1.2.1 Buyer and Owner of the System .............................................................................................................2
1.2.2 Customers of the System .......................................................................................................................2
1.2.3 Other Stakeholders ................................................................................................................................2
1.3 USERS OF THE PRODUCT ........................................................................................................................................3
1.3.1 The hands-on users of the product ........................................................................................................3
1.3.2 The Priorities Assigned to Users .............................................................................................................4
1.3.3 User Participation ..................................................................................................................................4
1.3.4 Maintenance users .................................................................................................................................5
1.3.5 User Hierarchy .......................................................................................................................................6
2. PROJECT CONSTRAINTS ................................................................................................................................ 6
2.1 MANDATED CONSTRAINTS .....................................................................................................................................6
2.1.1 Solution Design Constraints ...................................................................................................................6
2.1.2 Implementation Environment of the Current System .............................................................................7
2.1.3 Partner or Collaborative Applications ....................................................................................................7
2.1.4 Anticipated Workplace Environment .....................................................................................................8
2.1.5 How long do the developers have for the project? ................................................................................8
2.1.6 What is the financial budget for the project? ........................................................................................8
2.2 NAMING CONVENTIONS AND DEFINITIONS ................................................................................................................8
2.2.1 Definitions ..............................................................................................................................................8
3. FUNCTIONAL REQUIREMENTS ...................................................................................................................... 9
3.1 THE SCOPE OF THE WORK ......................................................................................................................................9
3.1.1 Context Diagram ....................................................................................................................................9
3.2 THE SCOPE OF THE PRODUCT ................................................................................................................................10
3.2.1 Product Use Case Diagram ..................................................................................................................10
3.2.2 Product Use Case List ...........................................................................................................................10
3.3 FUNCTIONAL AND DATA REQUIREMENTS .................................................................................................................11
3.3.1 Functional Requirements Use Cases ....................................................................................................11
3.3.2 Functional Requirements Use Case Mock-ups......................................................................................23
4. NON-FUNCTIONAL REQUIREMENTS ............................................................................................................ 25
4.1 LOOK AND FEEL REQUIREMENTS ............................................................................................................................25
4.1.1 The Interface ........................................................................................................................................25
4.1.2 The Style of the Product .......................................................................................................................26
4.2 USABILITY AND HUMANITY REQUIREMENTS .............................................................................................................26
4.2.1 Ease of Use ...........................................................................................................................................26
4.2.2 Personalization and internationalization .............................................................................................28
4.2.3 Ease of Learning ...................................................................................................................................28
4.2.4 Understanding and Politeness Requirements ......................................................................................29
4.2.5 Accessibility Requirements ...................................................................................................................29
4.3 PERFORMANCE REQUIREMENTS ............................................................................................................................29
4.3.1 Speed and Latency Requirements ........................................................................................................29
4.3.2 Reliability and Availability Requirements ............................................................................................30
4.3.3 Robustness or Fault Tolerance Requirements ......................................................................................30
Software Requirements Specification Page

ii
4.3.4 Longevity Requirements.......................................................................................................................31

4.4 OPERATIONAL REQUIREMENTS..............................................................................................................................31
4.4.1 Partner Applications ............................................................................................................................31
4.5 MAINTAINABILITY AND SUPPORT REQUIREMENTS .....................................................................................................31
4.5.1 Maintenance Requirements .................................................................................................................31
4.5.2 Supportability Requirements ...............................................................................................................32
4.6 SECURITY REQUIREMENTS ....................................................................................................................................32
4.6.1 Access Requirements ...........................................................................................................................32
4.7 CULTURAL AND POLITICAL REQUIREMENTS ..............................................................................................................32
4.7.1 Cultural Requirements .........................................................................................................................32
5. PROJECT ISSUES .......................................................................................................................................... 33
5.1 NEW PROBLEMS ................................................................................................................................................33
5.1.1 What problem could the new product cause in the current environment? .........................................33
5.1.2 Will the product create other problems? .............................................................................................33
5.1.3 What limitations exist in the anticipated implementation environment that may inhibit the new
product? .............................................................................................................................................................33
5.2 RISKS ...............................................................................................................................................................33
5.3 WAITING ROOM ................................................................................................................................................34

iii
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
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.

2
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

3
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.

4
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.

5
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.

6
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

7
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.

8
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

9
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)

10
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: Registration

Unique Use Case ID: UC001
Brief Description: The user registers to the system.
11
Actor(s): Client
Pre-Conditions: None
Main 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 in

Use Case ID: IUC-10
Brief Description: The user enters a valid username and password and logs into the system.
Actor(s): Client
Pre-Conditions: The user has been registered to the system.
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.
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.

12
Development Constraints: None

Use Case Name: Create personal profile

Brief Description: The user creates the personal profile that will be used by the system
Actor(s): Client, vendor, consultant
Pre-Conditions: User is logged in successfully and authorized to create their personal profile
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 user
Development Constraints: Requires the different page to be created where the user can fill their
personal information.
Use Case Name: Perform budget management

Brief 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): Client
Pre-Conditions: User is logged in successfully and authorized to use the budget management
tool.
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.
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.

13
Development Constraints: Requires these fields to be stored in the database in order to save the
users budgetary preference over time.
Use Case Name: Perform smart search

Brief 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): Client
Pre-Conditions: User is logged in successfully
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.
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.
Use Case Name: Utilize personal organizer tool

Brief Description: The user types updates for dates in personal organizer tool
Actor(s): Client
Pre-Conditions: User is logged in successfully and authorized to use the personal organizer tool
1. The user types in wedding date
2. 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 completed
4. 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 dates
8. The system sends the vendor quotes to the user when complete and updates the
information inside the calendar
Post-Conditions: The system displays the events dates that are needed for the wedding.

14
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.
Use Case Name: Input feedback

Brief Description: Users provide feedback about the website
Actor(s): Client, vendor, consultant
Pre-Conditions: User is logged in successfully
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.
Use Case Name: Send Notification

Brief 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, admin
Trigger: 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.
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)

15
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 button
3. 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: High
Assumptions: N/A
Issues: N/A
Source: Statement of work, Requirement elicitation meeting (4/1/2012)
Use Case Name: Manage user accounts

Brief Description: The admin perform basic account management operations, which includes
creating new user account and also editing, and deleting user account.
Actor(s): admin
Trigger: 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.
1) The admin logs into the FWP system with his/her credentials
2) 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 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.

16
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: High
Assumptions: N/A
Issues: N/A
Source: Requirement elicitation meeting
Extending Use Case Name: Add user account

Base Use Case Name: Manage user accounts
Extend ID Number: UC009-E1
Base ID Number: UC009
Brief 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/A
Flow 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.
appropriate user.
Priority: Medium
Extending Use Case Name: Modify user account

17

Brief 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.
Flow 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 preferences
appropriate user.
Priority: Medium
Extending Use Case Name: Remove user account

Brief 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.
Flow 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.

18
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

Brief 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, admin
Trigger: 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.
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.
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: High
Assumptions: N/A
Issues: N/A
Use Case Name: Pay for services

Summary: User pays bill for wedding planning service
Actor: Client, Vendor
Precondition: wedding planning service is functional
Description:
1 User browses to the payment page
2 System queries for the user account details and calculate the amount due based on user

19
role and package subscriptions.

3 Display shows the service fee to the user
4 <<payment>>
5 System updates payment information in user account
6 System displays thank you page to user
Alternatives:
1. If an invalid payment is used, the system will maintain that user owes fees
2. 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 Card

Base Use Case Name: Pay for services
Summary: User pays via credit card for services purchased on the wedding planning system
Actor: Client, Vendor, Credit Card System
Precondition: Wedding planning system is functional
Description:
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 system
Base Use Case Name: Pay for services
Summary: User pays via PayPal account
Actor: Client, Vendor, PayPal system
Precondition: Wedding planning is functional
Description:
1. User enters PayPal credentials
2. 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.

20
Use Case Name: Apply patches/releases

Brief Description: The admin typically installs patches to the system.
Actor(s): Admin
Pre-Conditions: System is able to be taken down for a maintenance window.
1. The admin sets timeframe for user logoff.
2. The admin sends a please logoff message to users
3. The admin disables system login for new users and account creation.
4. The admin closes system after timeframe and users auto logged off
5. The admin cause the system to shutdown
6. The patch is installed
7. The system is rebooted and users are allowed to create accounts and logon.
Post-Conditions: Patch has been successfully installed
Alternative Flows and Exceptions: None
Development 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.
Use Case Name: Modify web interfaces (admin)

Brief Description: The admin will modify the website style, flow and widgets loaded.
Actor(s): Admin
Pre-Conditions: System is able to be taken down for a maintenance window.
1. The admin sets timeframe for user logoff.
2. The admin sends a please logoff message to users
3. The admin disables system login for new users and account creation.
4. The admin closes system after timeframe and users auto logged off
5. The admin cause the system to shutdown
6. The CMS changes are made
7. The system is rebooted and users are allowed to create accounts and logon.
Post-Conditions: Website CMS has been successfully updated
Alternative Flows and Exceptions: None
Development Constraints: Requires that a CMS is part of the system to accommodate style
changes.
Use Case Name: Modify user interface

Brief Description: The user performs editing his/her account.

21
Actor(s): User
Trigger: 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.
 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.
sent to the appropriate client via email or SMS.

 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: Medium
Assumptions: N/A
Issues: N/A

22
3.3.2 Functional Requirements Use Case Mock-ups
System Planner

23
Smart Search

24
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.

25
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.

26
 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.

27
 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.

28
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

29
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.
30
 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.

31
 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.

32
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,
33
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.

34

100) Wedding Planning

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

100) Wedding Planning

Enviado por

Direitos autorais:

Formatos disponíveis

The Wedding Planning System

Wedding Planning System

Software Requirements Specification Page

4.3.4 Longevity Requirements.......................................................................................................................31

Software Requirements Specification Page

1.1 The Purpose of the Project

1.1.1 The user problem or background of the project effort

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%

Software Requirements Specification Page

1.2 Client, Customer, and other Stakeholders

1.2.1 Buyer and Owner of the System

1.2.2 Customers of the System

1.2.3 Other Stakeholders

Software Requirements Specification Page

Representatives of external associations (vendors) – Need to be familiar with the system in

1.3 Users of the Product

1.3.1 The hands-on users of the product

Fiancé and fiancée

Representative of wedding vendors

FWP consulting agent

Software Requirements Specification Page

FWP System Administrator

1.3.2 The Priorities Assigned to Users

Key users (critical)

 Client (FWP) – major influence

Secondary users (important)

Unimportant users (useful)

1.3.3 User Participation

Software Requirements Specification Page

1.3.4 Maintenance users

Software Requirements Specification Page

1.3.5 User Hierarchy

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

Software Requirements Specification Page

2.1.2 Implementation Environment of the Current System

2.1.3 Partner or Collaborative Applications

PayPal Payment System

Software Requirements Specification Page

2.1.4 Anticipated Workplace Environment

2.1.5 How long do the developers have for the project?

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

Software Requirements Specification Page

3.1 The Scope of the Work

3.1.1 Context Diagram

Software Requirements Specification Page

3.2 The Scope of the Product

3.2.1 Product Use Case Diagram

3.2.2 Product Use Case List

Software Requirements Specification Page

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

3.3 Functional and Data Requirements

3.3.1 Functional Requirements Use Cases

Use Case Name: Registration

Include Use Case Name: Log in

Software Requirements Specification Page