Business Finance
MSPM1 GC1000 Mobile Application Called X Locker Project

MSPM1 GC1000


Question Description

I’m trying to learn for my Management class and I’m stuck. Can you help?

following the requirement and finished the part work

my assigned part is

Project Conditions and Characteristics

  • The Solution
  • Stakeholder Characteristics
  • Product or Service Functions

only those three parts, details are already highlight on the template file, I will upload the project proposal

Unformatted Attachment Preview

The Requirements Document Guidelines Principles of Project Management MSPM1-GC1000 Edward Kleinert Overview: The requirements document is created for a project depending on the type of project, the needs for the project, and preferences of the organization, and the organizations stakeholders. This deliverable for this assignment requires that each ‘Team’ develop a ‘Project Requirements Document,’ to not exceed six (6) pages of content in length (double spaced,) (the cover sheet of the template is a seventh page.) The following sections must be prepared in the ‘Requirements Document’ template: 1. Executive Summary 2. The Requirements Document Purpose 3. Project Conditions and Characteristics 4. High-Level Scope of The Project 5. Detailed Project Requirements 6. Approvals 1 Requirements Considerations: The following are considerations that may be used in developing a project requirements document include: Stakeholder Analysis: Who do we need to talk to, to understand the business problem, opportunity, or directive? Who are the sponsor(s) and who are the key stakeholders, and what are their perspectives and requirements? Business Need: What is the business case that outlines the requirements and verifies the business need? Who is responsible for the solution that will be produced? Scope Specification: What is the definition of the scope of the project and the product(s) or process(s) that will be delivered? The Business Case:    What problem, opportunity, directive, or need is to be solved? What is the scope of the solution to the problem? Is the investment in solving the problem worth it? Functional Requirements What are the functional requirements for the project? Can these requirements be translated into specifications? Do they include software requirements, technical requirements, look, feel, features, and functions? Do they identify how the solution functions, operates, interreacts, performs, and delivers results? This may include:           Needs analysis Use cases Stories User interface assessment Workflow diagrams Business processes Data models User acceptance understanding Business procedures Checklists 2 Assessment: Exemplary (5.0-4.5 points): Provide full description of the requirements for the proposed project. Complete each of the required sections of the ‘Requirements Document.’ Write in clear and concise terms. Follow the guidelines for the format of the report and the naming convention. Each member of each team contributes to the narrative. Effective (4.4-4.0 points): Provide an adequate description of the of the requirements for the proposed project. Issues with the format, or the concise and focused narrative. Minimal requirements that do not follow the guideline. Ineffective (3.9-3.5 points): Selects requirements that are not well explained or that are not aligned with the proposal, without explaining why this is the optimal choice. Unacceptable (3.4-0): Failed to articulate sections of assignments or assigned deliverables, and/or failed to deliver the ‘Requirements Document.’ Format: Written Assignments: All written assignment must be word processed, with a 12pt font size, be double spaced, have normal margins, include page numbers, be submitted on the scheduled due date, and delivered as an MS Word file type (not as a .PDF) to the appropriate ‘Assignment Drop Box’ on the course homepage. Reports and/or papers that are submitted after the due date will be automatically reduced in score by twenty percent (20%) before they are read. All written reports/templates must be uploaded as a softcopy to the appropriate ‘assignment drop box’ in the ‘Assignment’ section of the course homepage. The ‘Documentation Specialist’ is responsible for uploading the completed work products for the ‘Team Project. The following naming convention must be used when uploading the project work products: Course Number Assignment Name Team Name and Semester Abbreviation Example: MSPM1-GC1000 The Requirements Document Team Name…. Delivery Channel: Upload the completed ‘Team’ assignments to the appropriate assignment drop box in the ‘Assignment’ section of the course home page. 3 Project Requirement Document Project Title Organization or Business Unit or Department Product/Process Date Team Name: Team Members Names: Course Name: Course ID Number: Date: Prepared By Document Owner(s) Project/Organization Role Executive Sponsor Project Manager Version Control Version Date Author Change Description The name of the Document Owner Document created The name of the Change Owner. • Change 1 • Change 2 • Change n The Principles of Project Management MSPM1-GC1000 Edward Kleinert 1 Executive Summary Provide a ‘high level’ statement of the proposed project, and the rationale and business justification for undertaking the project. Reference the business problem or opportunity that precipitated the initiation of the project. This is not a detailed review of the sections to follow, but rather a high-level overview. More detailed explanations are reserved for the respective sections that follow. The Requirements Document Purpose This section should be a short description of the purpose of this tool: ‘The Requirements Document.’ Explain to the reader why it is important to develop a document that includes a listing of what the customer/client requires in the solution that will be developed for the project. You may reference the proposed scope for this project, to provide context for explaining why it is important to develop a set of specific and systematic requirements that describe the features and functions that will be needed in the solution (deliverables) that will be produced in this project. A requirement document defines what you are looking to achieve or create, to solve the problem or take advantage of the opportunity, for which a project has been proposed. The purpose of the ‘Executive Summary’ of the requirements document is to provide a high-level overview, not a full explanation, of how this tool will be used to document the functional and non-functional (if applicable) requirements of the project. These requirements will be based on an active outreach to the project owner and its stakeholders, to understand their needs. It may be used to describe examples of the features and functions that the project ‘solution’ will be expected to deliver. This template is intended for use to facilitate the formal documentation of the requirements for a project. It will be version controlled to ensure that the iterations of an evolving set of requirements is systematically controlled. The primary audience for this document will be the stakeholders who have an interest and expectations for the deliverables that will be produced from this project. Use this section to explain the purpose that the ‘Project Requirements Document’ will serve. The contributors and reviewers of this document will include the project ‘Executive Sponsor,’ or ‘Project Owner,’ authorized ‘End-users’ and ’Subject Matter Experts,’ ‘Business Analysts’ and Technical Analysts (as appropriate,) and the ‘Project Manager’ and ‘Project Team Members.’ When this document is accepted by representatives of each stakeholder as an appropriate understanding of the statement of requirements for the project, then the team will use it as a guide to develop the business case, as a precursor to develop detailed specifications for the project, and as a critical resource for determining the formal scope of the project. 2 Project Conditions and Characteristics This section is to be written as a narrative and will provide a high level (non-technical) description of the project conditions and characteristics. Each of the following subheadings can be referenced in this narrative. It is preferable to retain the subheadings, and include a brief narrative related to each of them, under the subheading. • The Solution Why have you chosen to develop this product (or service) and the need that it will serve. Who the primary stakeholders are, who is developing the project, and who will benefit from the finished product. • The Solution Functionality What the features and/or functions are for this solution will deliver, what its purpose will be, and what is the primary need this solution will satisfy. • Stakeholder Characteristics Who the stakeholders are (and why,) including the participant stakeholders, the vested interest stakeholders, the customer and/or workforce stakeholders, and their motivation to use it. • Product or Service Functions What does product or service do? What is its purpose or function? What activities can users perform while using it? List the main functions and or features that you will build into your product here. • Assumptions Project assumptions are circumstances and events that need to occur for the project to be a success, but outside of the control of the project team. They are listed as assumptions if there is a high probability that they will happen. • Dependencies Project dependencies are logical links, between the tasks of a project, as well as links to other projects outside of the control of a project manager. These include logical planning dependencies (logic driven,) resource-based dependencies (resource limits,) and preference planning dependencies (the Project Manager’s preferences.) • Constraints These are restrictive conditions or limitations that the project may face, such as the availability of resources when needed, or restrictive date or time limitations. The three baseline constraints are represented here, including the ‘schedule’ baseline, the ‘budget’ baseline, and the ‘scope’ baseline, in addition to the influencing constraints, including ‘risk,’ quality,’ and resources. 3 The High-Level Scope of the Project This section is used to define the high-level logical boundaries of the project. The emphasis is on the ‘Goal(s’) of the project. It will include a high-level statement of purpose. The anticipated deliverables for the proposed project (both the ceremony of the project process as well as the product or service that is to be produced.) Provide enough explanation and detail for the reader to be able to understand what is being proposed. Note: these are stated in more general terms. Detailed Project Requirements This section of the document lists specific requirements, detailed deliverables (specific products or services) that the project is expected to deliver. This section lists specific requirements (functional and non-functional) for project. It may include features, functions, look, feel, design, operations, rules, regulations, policies, procedures, or compliance concerns that must be met. Requirements may be divided into the following sections as applicable: 1. User requirements. These are requirements written from the point of view of end users, usually expressed in narrative form (the most common of the requirements.) 2. System requirements. These are detailed specifications describing the functions the system must be capable of doing (see the systems requirements section below 3. Interface requirements. These are requirements about the user interface, which may be expressed as a list, as a narrative, or as images of screen mock-ups (If applicable.) • User Requirements (Functional) Requirements should be written from the point of view of end-users, expressed in a narrative form. They should describe the required look, feel, features, functions, behavior, and any other characteristics of the final deliverables of the solution(s)to be derived from the project. This may come from business rules, policies, procedures, regulations, or law. Discovery typically is through the elicitation sessions with users, stakeholders, and other stakeholders. It will include gathering data and information from surveys, focus groups, reports, a scan of information from the external environment, and other methods that are associated with determining the scope of the project • System Requirements (Non-Functional)(If applicable) Note: for a systems related (IS/IT) project, it is common to collect what is known as nonfunctional systems requirements. These are requirements that typically are not visible or obvious to the customers or clients for home this project is focused. These requirements may be related to the design or implementation of a system solution, and can include performance requirements, security requirements, volume of use requirements, or reliability requirements. It is important to be aware of this type of requirement, but it may not be applicable to all projects. 4 Approvals: Prepared by __________________________________ Project Manager Approved by_ Edward Kleinert_________________________________ Project Executive Sponsor __________________________________ Other Appendices (If applicable): This section of the requirements document represents various resources that be important to refer to that will have an impact upon identifying requirements and supporting their needs. They are different types of document resources that may be included (if applicable.) Use this to list the various support documents that you may acquire see the following examples. • • • • • Legal and Regulatory Documents Policies and Procedures That Apply to The Governance of an Organization Product Design Documents Standards and Practice Documents Environmental Analysis Documents 5 Exhibit: Rules for Effective Requirements Note: this appendix is for your use in helping to develop a project requirement. It does not need to be developed for the requirements document assignment, but rather is a reference for the work that needs to be done for this assignment. Is not needed Each requirement must form a complete sentence, containing a subject and a predicate. These sentences must consistently use the verb ‘shall,’ ‘will’ or ‘must’ to show the requirement’s mandatory nature, and ‘should’ or ‘may’ to show that the requirement is optional. The whole requirement specifies a desired end goal or result and contains a success criterion or other measurable indication of the quality. 1. Identify and define objectives • Explain for what purpose the system is being deployed • Qualified objectives identify the desired deliverables • The value proposition explains return-on-investment 2. Verify the requirements against the objectives • Validate accurate scope for high-level requirements • Assure consistent focus for application rules • Provide critical management tools for scope change decisions • Verify every iteration of the requirements and design documents 3. Defining a good requirement • • • • • • • • • Correct (technically and legally) Complete (express a whole idea or statement) Clear (unambiguous and not confusing) Consistent (not in conflict with other requirements) Verifiable (it can be determined that the system or solution meets the requirement) Traceable (uniquely identified and tracked) Feasible (can be accomplished within cost and schedule) Modular (can be changed without excessive impact) Design-independent (do not pose specific solutions on design) 6 Team Name: XLocker Team Members Names: Course Name: Principles of Project Management Course ID Number: GC1000 Date: 02/18/2020 Proposal for XLocker Principles of Project Management MSPM1-GC1000 Edward Kleinert Summary of the Proposed Project Our team proposes to develop a mobile application called “XLocker” which would store important documents such as passport, state ID, driver’s license, medical insurance card, and social security proof. The mobile app will be a verified platform for digital document storage by the United States Government. The digital versions of the documents will be accepted at all airports, train and bus stations, hospitals and all government organizations and departments such as the Department of Motor Vehicles (DMV), national security departments, etc. The Problem or Opportunity Most of us end up carrying a lot of important documents, especially during travel which can be lost or misplaced leading to unwanted consequences such as identity theft and personal confidential data being compromised. This is where XLocker comes in. It is a government-vetted secure storage place for documents and can only be accessed with a numerical passcode, face identification or fingerprint biometrics, which will ensure access to the documents only to verified users and their respective verified accounts. The High-Level Scope of the Proposed Project Since the application for XLocker will be government verified, it will be marketed through the government and its agencies for easy adoption by the residents of the US. !2 The app can be downloaded from the app store on apple, google and android devices. Once download is complete, the user will have to enter some preliminary information to verify his/her identity. Once verified, the user will be able to create a profile by choosing a username and password, and filling in the forms for the respective documents that have to be uploaded. The forms will need information such as the number on the document, date of issue, date of expiry, issuing authority, address associated with the document, etc., which will be verified by the government to issue the digital version of the documents to be stored on the app. A unique QR code will be associated with each approved document that can be scanned in place of the original physical document. Once the application is verified by the government and released to the public, the Xlocker team, in conjunction with the government will market and advertise the app through social media platforms, public modes of transport and billboards. The company will also set up customer service and IT helplines for any questions and/or concerns. Proposed Deliverables and Objectives o A Mock-Up Mobile Application - Building a mock-up of the app with the necessary UI/UX , and integrating functions such as upload, verification by third party organizations, etc. This process will include a continuous feedback loop until finalization. !3 o The Mobile Application - Once final changes are made, and the US Government approves the mock-up and its functions, the app will be built. Once fully developed, it will be tested with some target consumers to check for glitches and bugs before eventual release to the public. Since the application is government verified, the company XLocker, along with government advertising agencies will market the app for quick adoption by the residents of the US. !4 ...
Purchase answer to see full attachment
Student has agreed that all tutoring, explanations, and answers provided by the tutor will be used to help in the learning process and in accordance with Studypool's honor code & terms of service.

Final Answer

let me know if this is all good! thanks.

Project Conditions and Characteristics
The Solution
Our team has decided to develop this product to simplify the act of keeping important documents
which includes our ID. Our mobile application “XLocker” will make it easier for us to organize
all our essential documents and make them available within just the click of a button. There are a
lot of instances in which we are required to show our ID. Examples include airports, train
stations, DMV, hospitals, and many more. There are even more instances in which we misplace
our documents, accidentally spill water (or other liquids or foods) on them, or simply forget to
bring them with us. Thus, with our product, we don’t need to deal with the hassle of these
problems. Instead, we can simply open the app and show our ID through our mobile phones,
which we are less likely to forget to bring around. Prim...

Rice University

Return customer, been using sp for a good two years now.

Thanks as always for the good work!

Excellent job

Similar Questions
Related Tags