It has to be the same previous writer. This assignment is related to “Order ID: 117109741”. This week you will create an analysis model with communication diagrams for your project. For each use case in the baseline use-case model posted by your facilitator, develop a communication diagram.

The models in this assignment will be assessed using the following AnalysisModelRubrics.doc expectations rubric.
—————–
I uploaded three files: AnalysisModelRubrics.doc, Software Requirements Specification.doc (Previous project), and ClientRequest-1.doc.
——————–
Discipline: Modern Software Engineering Note: You must use SRS: use-case diagrams, use-case specifications & UIs.
Software Requirements Specification (SRS) for a Client Request Design
Software Requirements Specification (SRS) for a Client Request Design
This Software Requirements Specification (SRS) document describes the design of an in-store Bridal Registry application for a Case Study departmental store called Tegrat. The proposed application should enable betrothed couples to create a BR and populate it with various products they would like to receive as gifts from friends and relatives during their wedding. Consequently, wedding customers, who are the Tegrat customers, can obtain printed copies of the registry in order to purchase products while in the store.
1. Background
1.1 Goals and Objectives
The main goal of this project is to ensure that the proposed application meets specified goals and objectives. The project aims to meet three main goals:
i. To design an application that enables communication between the gift givers (guests) and the receivers (Couples)
ii. The application should assist guests in finding appropriate gifts and keep the purchases discreet from the gift recipient until gift giving
iii. The application should prevent guests from giving duplicate gifts by enabling the retailer to remove purchased items from the registry
The following are the key requirements, features, and functionalities of the proposed system:
• The proposed application should allow couples to create BR and populate it with desired gifts
• Tegret customers should access an appropriate printed copy of the BR from the cashier to purchase products while in the store
• The system should allow guests to find the registry given the couple’s names in combination with additional information such as address and wedding dates
• The application should be able to handle multiple gift requests
• The system must store address and telephone information of the betrothed couples
• Application should archive the registry one week after the wedding date and provide access to store employees
1.2 Statement of Scope
The application being developed gives users a powerful tool to identify gifts and provide assistance in finding these products in the store. The application is designed in a way that it can be useful in handling multiple gift requests while also allowing betrothed couples to update the gift list after it is created.
1.3 Software context
In software development, the software and project context determines the most appropriate software process. For this particular project, the application being developed is a new system. Therefore, one would envisage that the design element to be the most detailed but the software would require medium technical complexity and minimum quality relevance. We also envisage high level of client involvement, consistent with best practices.
1.4 Major constraints
Constraints refer to fixed design decisions or limitations that must be satisfied. In any software design project, constraints are two-fold: business and technical. The most significant technical constraint envisaged in this project is the need to design the software to be supported in the most common platforms to allow guests to print it. That is, it should work on Windows, Windows XP, Linux, (or iOS), and Solaris. On the other hand, the main business constraint is for the application to provide single in-store BR (retailer-specific solution) to customers.
2. Usage Scenarios
In system engineering and software development, functional requirements refer to requirements that define specified functions or behaviors. For this particular project, the functional requirements are:
i. The system will allow the retailer to manage the registry and wish lists
ii. The application will allow couples to update the registry
iii. The system will allow the guests to find and print registries
iv. The application should optionally interface with the in-store inventory system

2.1 User Profiles: Actors
Actors refer to stakeholders such as people, a computer system, or organizations that interact with a system. We envisage three actors for the proposed solution:
Guest/customer: Guests are important actors in the proposed system. Their primary role is to buy gifts. The guests are also the customers for the retail store.
Couple: Both brides and bridegrooms are primary actors. They are also customers for the retail store.
Administration: The system cannot work without an admin. The admin can be a sales person in the retail store or a sales manager, who should access the database.
2.2 Use Cases
Logon Use-Case
Couples and guests have the ability to logon to the system and use the application. This use case might not be mandatory based on the system scenario. Initially, all users will user username/password identification/authentication but the system has the ability to support other various login possibilities.

Figure 1: Logon Use-Case
This use case involves three steps:
• The user selects the ‘Logon’ link
• The user types the username and password, and
• The user clicks the ‘OK’ button.
Register User Case
Guests have the ability to join the system as users. The precondition is that user has an email address, and the post condition is that user is active.

Figure 2: Register Use-Case
The steps involved in this use case are as follows:
• User selects the ‘Register’ link
• User is shown a screen where to create user name
• User should add his/her email, password (mandatory) and location
• User presses ‘OK’
• The system sends an activation link to the submitted email
• User clicks on the link for activation
Create Registry Use-Case
Couples have the ability to create a registry and modify entries to add/delete gift, edit registry or delete registry.

Figure 3: Create Registry Use-Case
To achieve this, the user follows the following steps:
• The user logs into the system
• The user hits the ‘Create Registry’ link on the system
• The user provides personal details including contacts and details of the wedding event such as date and venue
• The user adds details of the gifts with the option to delete or edit the registry
Archive Bridal Registry
One week after the wedding date, the application should archive the registry. The admin will click the link ‘Archive’ to make the registry accessible to the store employee or hit the link ‘Delete’ to delete the registry from the database.

Figure 4: Archival Bridal Registry Use-Case
3. User Interface Prototype
We propose to use user-friendly Web application interface that emphasizes on intuitiveness using jQuery framework CSS, HTML, and Java. We propose to use XML develop fixed interface elements and to utilize Java to produce runtime components. This choice emphasizes W3C recommendations as the best practices. The idea is to design specific roles or permissions to create a display view with the main content and a side menu.
Figure 5 below illustrates the sketch for the Web app user interface.

Figure 5: Illustration of the BR user interface
Figure 6 below depicts a sketch of the user login view of the Bridal Registry application.

Figure 6: Bridal Registry application login view
4. Glossary
Application – software that allow users to perform specific tasks
Hypertext Markup Language (HTML) – a set of codes of markup symbols usually inserted in a file for Display on a Web page
JQuery – a fast but concise library based on JavaScript language mainly used to simplify HTML (traversing) client-side scripting
Prototype – an initial model or early sample of a software product
W3C – An international standards body based on the World Wide Web
XML – A markup language defined by the W3C, usually for encoding documents in a machine and human-readable format

It has to be the same previous writer. This assignment is related to “Order ID: 117109741”. This week you will create an analysis model with communication diagrams for your project. For each use case in the baseline use-case model posted by your facilitator, develop a communication diagram.

The models in this assignment will be assessed using the following AnalysisModelRubrics.doc expectations rubric.
—————–
I uploaded three files: AnalysisModelRubrics.doc, Software Requirements Specification.doc (Previous project), and ClientRequest-1.doc.
——————–
Discipline: Modern Software Engineering Note: You must use SRS: use-case diagrams, use-case specifications & UIs.
Software Requirements Specification (SRS) for a Client Request Design
Software Requirements Specification (SRS) for a Client Request Design
This Software Requirements Specification (SRS) document describes the design of an in-store Bridal Registry application for a Case Study departmental store called Tegrat. The proposed application should enable betrothed couples to create a BR and populate it with various products they would like to receive as gifts from friends and relatives during their wedding. Consequently, wedding customers, who are the Tegrat customers, can obtain printed copies of the registry in order to purchase products while in the store.
1. Background
1.1 Goals and Objectives
The main goal of this project is to ensure that the proposed application meets specified goals and objectives. The project aims to meet three main goals:
i. To design an application that enables communication between the gift givers (guests) and the receivers (Couples)
ii. The application should assist guests in finding appropriate gifts and keep the purchases discreet from the gift recipient until gift giving
iii. The application should prevent guests from giving duplicate gifts by enabling the retailer to remove purchased items from the registry
The following are the key requirements, features, and functionalities of the proposed system:
• The proposed application should allow couples to create BR and populate it with desired gifts
• Tegret customers should access an appropriate printed copy of the BR from the cashier to purchase products while in the store
• The system should allow guests to find the registry given the couple’s names in combination with additional information such as address and wedding dates
• The application should be able to handle multiple gift requests
• The system must store address and telephone information of the betrothed couples
• Application should archive the registry one week after the wedding date and provide access to store employees
1.2 Statement of Scope
The application being developed gives users a powerful tool to identify gifts and provide assistance in finding these products in the store. The application is designed in a way that it can be useful in handling multiple gift requests while also allowing betrothed couples to update the gift list after it is created.
1.3 Software context
In software development, the software and project context determines the most appropriate software process. For this particular project, the application being developed is a new system. Therefore, one would envisage that the design element to be the most detailed but the software would require medium technical complexity and minimum quality relevance. We also envisage high level of client involvement, consistent with best practices.
1.4 Major constraints
Constraints refer to fixed design decisions or limitations that must be satisfied. In any software design project, constraints are two-fold: business and technical. The most significant technical constraint envisaged in this project is the need to design the software to be supported in the most common platforms to allow guests to print it. That is, it should work on Windows, Windows XP, Linux, (or iOS), and Solaris. On the other hand, the main business constraint is for the application to provide single in-store BR (retailer-specific solution) to customers.
2. Usage Scenarios
In system engineering and software development, functional requirements refer to requirements that define specified functions or behaviors. For this particular project, the functional requirements are:
i. The system will allow the retailer to manage the registry and wish lists
ii. The application will allow couples to update the registry
iii. The system will allow the guests to find and print registries
iv. The application should optionally interface with the in-store inventory system

2.1 User Profiles: Actors
Actors refer to stakeholders such as people, a computer system, or organizations that interact with a system. We envisage three actors for the proposed solution:
Guest/customer: Guests are important actors in the proposed system. Their primary role is to buy gifts. The guests are also the customers for the retail store.
Couple: Both brides and bridegrooms are primary actors. They are also customers for the retail store.
Administration: The system cannot work without an admin. The admin can be a sales person in the retail store or a sales manager, who should access the database.
2.2 Use Cases
Logon Use-Case
Couples and guests have the ability to logon to the system and use the application. This use case might not be mandatory based on the system scenario. Initially, all users will user username/password identification/authentication but the system has the ability to support other various login possibilities.

Figure 1: Logon Use-Case
This use case involves three steps:
• The user selects the ‘Logon’ link
• The user types the username and password, and
• The user clicks the ‘OK’ button.
Register User Case
Guests have the ability to join the system as users. The precondition is that user has an email address, and the post condition is that user is active.

Figure 2: Register Use-Case
The steps involved in this use case are as follows:
• User selects the ‘Register’ link
• User is shown a screen where to create user name
• User should add his/her email, password (mandatory) and location
• User presses ‘OK’
• The system sends an activation link to the submitted email
• User clicks on the link for activation
Create Registry Use-Case
Couples have the ability to create a registry and modify entries to add/delete gift, edit registry or delete registry.

Figure 3: Create Registry Use-Case
To achieve this, the user follows the following steps:
• The user logs into the system
• The user hits the ‘Create Registry’ link on the system
• The user provides personal details including contacts and details of the wedding event such as date and venue
• The user adds details of the gifts with the option to delete or edit the registry
Archive Bridal Registry
One week after the wedding date, the application should archive the registry. The admin will click the link ‘Archive’ to make the registry accessible to the store employee or hit the link ‘Delete’ to delete the registry from the database.

Figure 4: Archival Bridal Registry Use-Case
3. User Interface Prototype
We propose to use user-friendly Web application interface that emphasizes on intuitiveness using jQuery framework CSS, HTML, and Java. We propose to use XML develop fixed interface elements and to utilize Java to produce runtime components. This choice emphasizes W3C recommendations as the best practices. The idea is to design specific roles or permissions to create a display view with the main content and a side menu.
Figure 5 below illustrates the sketch for the Web app user interface.

Figure 5: Illustration of the BR user interface
Figure 6 below depicts a sketch of the user login view of the Bridal Registry application.

Figure 6: Bridal Registry application login view
4. Glossary
Application – software that allow users to perform specific tasks
Hypertext Markup Language (HTML) – a set of codes of markup symbols usually inserted in a file for Display on a Web page
JQuery – a fast but concise library based on JavaScript language mainly used to simplify HTML (traversing) client-side scripting
Prototype – an initial model or early sample of a software product
W3C – An international standards body based on the World Wide Web
XML – A markup language defined by the W3C, usually for encoding documents in a machine and human-readable format