Fluent Essays

Instructions for the Final Project t is important that you understand what youre supposed to do, and what youre not supposed to do.  Youll be listening to a series of interviews with your customer, and as a class, conducting a series of interviews with your customer.  Then, based on that, youre going to produce a requirements specification in the format of your choice that covers her needs.  The first 3 interviews will appear in this week.  Two will appear immediately upon you checking this item off as having been read.  The third will be appearing a bit later.  The remaining will be any or all of you asking questions of your customers in the Bidders Forum.  Your requirements documents will explain your customers needs, all your customers needs, and no needs but your customers needs. It is very important that you understand that the first interview, Season 1 Episode 1 is an introduction to the characters involved and the situation only.  All of those needs are in the past.  You should not be basing anything in your specification off season 1, except perhaps to mention as reference points things that have already occurred.  Season 2 Episode 1 is my first interview with your customer.  All of season 2s needs are to be addressed completely.  Theres no stop at 8 rule.  Season 2 Episode 2 will be a follow up interview Ill be doing.  The rest of Season 2 takes place in the Bidders Forum, before and/or after Episode 2 drops. Ill be constructing the answer key from the interviews, including the Bidders Forum as soon as I get the first paper in, and the Bidders Forum will close at that point. A warning:  You may use any reasonable format you like, with or without a template.  For instance, you can use the template from assignment 1 or 2, or find one to your liking elsewhere.  But, if you do use a template, be sure its a template only.  Dont work from someone elses work, because this customers needs are extremely different than any other customers needs (unless youve contracted with JLA). Heres how I go about grading this assignment:  The Bidders Conference establishes the fine points of the assignment.  I construct an answer key by going through the customer interview transcripts, and further conversations with the customer in the Bidders Conference.  Im going to look for use cases or stimulus/response/requirement sets that fulfill all of the main points in the sessions with the customer.  Im also going to go through your work and make sure that nothing you have violates anything in the main points or in the fine points.  Ill also check for overscope (things you have [other than suggestions] that the customer didnt want or need).    Season 1 Episode 1 Customer-Interaction Role-Playing Game for SWEN 645 Typically, in this slot, youd be getting a final.  However, I dont like finals that much, because they take up time just repeating stuff you already know, when instead we could better be using our time to continue with learning experiences.  So here goes… So far in class, weve been dealing with requirements handed to you, and making improvements from there, or reverse-engineering projects already accomplished back to requirements.  Now, as a further learning experience, were going to back up a bit, and do some role-playing. You will play the project manager, requirements writer, and business analyst.  Someone will play the clueless customer. Heres how it will work: • The customer will make a broad requirements statement. • You will ask questions as needed, using the Bidders Conference forum, and she will respond.  Repeat this step as often as required.  When I respond, responses will be marked [SL].  When she responds, her responses will be marked [CM]. • When you have enough information to proceed, write the requirements document and submit it.  The requirements document shall assume a Waterfall development model, and should use a format similar to one already used in class. • Doing what the customer specifically asked you to do with get you 70\%.  Doing everything the customer answers will give you 90\%.  Putting in what the customer needs but didnt think of will get you to 100\%.  As usual, Ill ding you for every mistake you make, even if its just a comma.  But, also as usual, Ill give you a chance to correct. • After you submit your first draft of the specification, Ill make my comments as the professor.  You can also expect that the customer will also pull a standard stupid customer move, which will cause you to modify the requirements document.  Be sure to leave yourself time for that one. • Ill post my own follow-up interview 9 days after this posts.  Turn in your assignment after that second post, and before the close of class. • Half of your grade locks in on the first submission, so be careful! Now, heres the customer request, both as a regular interview in A/V form, and as a transcript: [Sheldon Linker] Okay, this is the initial customer interview for the SWEN645 RPG project, also known as project #4.  We have with us the proprietor of the SwenCo comic book shop, Captain Maryland.  Why dont you tell our business analysts, or at least aspiring business analysts, what you need. [Captain Maryland] In my comic book store I am looking for a location tracker, a contact me page, a means of selling me second-hand comics or non comic items.  I need a page that shows what non-comic-book merchandise I have, such as figurines.  I need a manga section that is separate from my comic book merchandise.  I need a trading system for people to bring me their second-hand comics; employment opportunities, a comic book rarity tracker, what rare merchandise we have in stock now, and what comics we get on a regular basis. [SL] Anything else you need to add? [CM] No. [SL] May I include a picture? [CM] Most people have already seen me in the news, so might as well. [SL] Ok, thats it people.  Go for it! BIDDER’S CONFERENCE Here, just as in real life, you can send questions to your customer through me.  You dont need to post here, but you do need to read this forum every day.  If the customer says she wants something, or doesnt want something, that had better affect your SRS.  Dont annoy your customer by asking questions already answered.  Remember that shes newer to this process than you are, and is in no way a computer expert.  When the 2nd interview posts, and then the first turn-in of this assignment happens, this forum will close, even if you have a question entered but not yet answered. · Captain Maryland Interview Audio   Im Done Top of Form  Starts Jul 28, 2021 12:01 AMEnds Aug 13, 2021 11:00 PM Bottom of Form This is Season 2 Episode 1, and constitutes part 1 of the final/RPG project description.  You must provide a spec in the format of your choice (any reasonable format, at my discretion).  Include all of your customers requirements.  Dont over-spec.  If you have questions, ask in the Bidders Forum.  Dont assume (but if you must, list it as an assumption). CAPTAIN OF MARYLAND INTERVIEW TRANSCRIP Your Professor (SL):  I’m on a call with Captain Maryland.  For those who don’t keep up with the news, let me recap the story so far:  Captain Maryland is well-known in this area.  Shes a superheroine, of course.  Or is it superhero now?  But she also has a comic-book store.  As of last year, the Captains store, Swenco Comics, was operating as a brick-and-mortar store, with some mail-order business, and does business mainly in the US and Japan, with comics, manga, and related figurines and the like.  Last years class did the specification for a web-site, allowing her to do business — quite effectively — online, as well as in the store.  But, as you know, many things have changed since then.  With Covid changing a lot of lives, the storefront is currently not in operation, and the entirety of the business is done online, but not as much total business as there had been before.  There has also been a lot of social unrest, with provocateurs and rioters interspersed amongst the well-intentioned demonstrators.  So, Captain, what can we help you with today? Captain Maryland (CM): I have a few satellites that can detect the visible spectrum, infrared, microwave, and radio. I’ve nicknamed them ‘The Turtles.’ I’m hoping to set things up such that I can use them to deal with the recent violence, as well as help with the pandemic. SL: How do you propose to do that? CM: Well, with infrared especially, you can detect temperatures of all sorts. Imagine for a moment that you can utilize that to detect arsonists, since apartments being burned down has been such a problem in some areas. Not only that, but you could use that to detect person-shapes with fevers as well, and possibly get people with the virus to stop spreading the pandemic. SL: So you want to use infrared to detect person shapes causing trouble, and find sick people? CM: Exactly. And I can use radio to figure out who is who in these cases, even in groups, and figure out who’s calling the shots. Plus, I can use radio to keep in mind where law enforcement are. SL: Sounds useful. Anything else? CM: Yes, actually. I’m a little low on funds at the moment. My day-job as a comic store owner can only do so well in the current climate. You guys helped so much in getting my website up, and as it turns out, it was just in the nick of time. I had to close my physical store entirely for the time being. SL: I’m sorry to hear that. CM: I appreciate it. As things are, I need to find a way to attract customers and make a bit more money so I can keep rent, and also hopefully any repairs The Turtles will need in the future. So I’d like to set up an auction system on the website. SL: What do you have in mind? CM: Well, I have several camera drones lying around that I’d like to program to peruse my physical store for things about to be auctioned. SL: How many camera drones do you have? CM: Twelve. I want users on my site to be able to control them to see the stock at their leisure. SL: What will the auctions look like? CM: They’ll be livestreamed. People can use the site to virtually raise their hand and bid, if they’re logged in. Other than that, I don’t really mind how it works. SL:  Ok, Captain.  We’ll get on it.  Class:  Get to it.  If you have any clarifying questions, send them to me via the Bidders’ Conference discussion board, and I’ll forward them to the Secret Warehouse lair of Captain Maryland. Customer-Interaction Role-Playing Game for SWEN 645 Abstract—Improvement of quality of products is a required for the clients to promote a reliable approach of generating better store activities. The bidders conference forum offers a proper environment for clients to interact with professionals in the fields. An increase in profitability is the ultimate outcome that increases positive outcome of all business procedures. Business analysis is the basis of proper development since it is possible to create reliable performance-based activities to increase the client’s value of the comic book store. Keywords—business analysis, interact, profitability I. Introduction The process of increasing positive outcome of the comic book store’s activities is dependent on the internal operational factors. It is possible to detect areas where clients required better operational outcomes depending on the prevailing conditions. The comic book store already possesses a strong customer preference factor as it involves books that improve on entertainment. Increase in positive outcome of the store is possible as it handles new clients everyday and find its easy to correlate with their requirements. Incorporation of new technological factors is the suitable direction to handle the store’s management since it is possible to increase availability of the resources and possibility of increasing market share. Captain Maryland gave a comprehensive explanation of how the comic book store already offers good products yet it could offer more beneficial outcomes. II. CUSTOMER ASSESSMENTS Availability of better working store hours is the basis of promoting customer preferences. The customer prefers a location tracker, possibility of selling second-hand comics, a contact me page, and selling of non-comic items. The process of improving positive appearance of the comic books is possible while ensuring proper display of the components according to the client needs. Since the customer needs the comic books to contain a separate page showing their preferred item, it is mandatory to increase profitability of the entire business venture. The process of selling second-hand comics is the best in promoting reliability and an increase in the customer’s satisfaction. Separation of the manga section from the comic book’s contents is the best approach of increasing positive outcome of the client’s direction and aligning internal business activities to the ultimate goals. III. IDENTIFIED CHANGES Transformation of the comic book store is a requirement that can improve on reliability and the management of client preferences. Since inclusion of a separate page is customer requirement, all comic books would have this feature to ensure suitable customer preference sessions. An increase in the amount of comic books at the store is required to facilitate proper improvements and the possibility of allowing customers to engage with their favorite characters. Collaboration between existent and new clients is a requirement that can increase positive outcome of the process while enhancing possibility of creating reliable connections and the constant increase in customer satisfaction. Development of a trading system is required using technological capabilities since it would be possible to facilitate all client preferences. A technological tool to get used as a trading system is the best approach of promoting proper changes. Creation of changes is required to handle the diverse client activities since receiving of second-hand comics requires proper management. Creation of employment opportunities would be possible once a new trading system gets implemented to handle client requirements. There would be a higher possibility to involve persons from diverse backgrounds in the program and facilitate suitable selections for customer development. Comic books management has proven to be a reliable approach to handle customer needs. In the event that clients get provided with more options, it would be easier to increase profitability at the comic book store. IV. suitable direction Selection of external technological systems’ providers is required as it promotes better outcomes for the business venture. The process of ensuring client preferences get handled is the best in promoting security for the comic-book store’s activities. Availability of variety of comic books is required to increase the positive outcome of the internal business management procedures. It is possible to implement a dependable approach to ensure business progress once all participants understand their responsibilities. Since the initial procedure of handling the comic books exchange and selling activities involves interactions, the new employment opportunities would get relied on. Improvement of available merchandise would get guaranteed during the entire business. Since comic books are entertaining and contain diverse figurines, customer would always view a variety to choose from. The technological trading system would offer a guaranteed approach to increase profitability of the entire comic book management process. It would be possible to promote solutions-creation during the entire business ventures. Management of comic books in stock and any new pieces would get performed. XXX-X-XXXX-XXXX-X/XX/$XX.00 ©20XX IEEE Instructions for the Final Project t is important that you understand what youre supposed to do, and what youre not supposed to do.  Youll be listening to a series of interviews with your customer, and as a class, conducting a series of interviews with your customer.  Then, based on that, youre going to produce a requirements specification in the format of your choice that covers her needs.  The first 3 interviews will appear in this week.  Two will appear immediately upon you checking this item off as having been read.  The third will be appearing a bit later.  The remaining will be any or all of you asking questions of your customers in the Bidders Forum.  Your requirements documents will explain your customers needs, all your customers needs, and no needs but your customers needs. It is very important that you understand that the first interview, Season 1 Episode 1 is an introduction to the characters involved and the situation only.  All of those needs are in the past.  You should not be basing anything in your specification off season 1, except perhaps to mention as reference points things that have already occurred.  Season 2 Episode 1 is my first interview with your customer.  All of season 2s needs are to be addressed completely.  Theres no stop at 8 rule.  Season 2 Episode 2 will be a follow up interview Ill be doing.  The rest of Season 2 takes place in the Bidders Forum, before and/or after Episode 2 drops. Ill be constructing the answer key from the interviews, including the Bidders Forum as soon as I get the first paper in, and the Bidders Forum will close at that point. A warning:  You may use any reasonable format you like, with or without a template.  For instance, you can use the template from assignment 1 or 2, or find one to your liking elsewhere.  But, if you do use a template, be sure its a template only.  Dont work from someone elses work, because this customers needs are extremely different than any other customers needs (unless youve contracted with JLA). Heres how I go about grading this assignment:  The Bidders Conference establishes the fine points of the assignment.  I construct an answer key by going through the customer interview transcripts, and further conversations with the customer in the Bidders Conference.  Im going to look for use cases or stimulus/response/requirement sets that fulfill all of the main points in the sessions with the customer.  Im also going to go through your work and make sure that nothing you have violates anything in the main points or in the fine points.  Ill also check for overscope (things you have [other than suggestions] that the customer didnt want or need).    <Project Name> Version: <1.0> Software Requirements Specification Date: <dd/mmm/yy> <document identifier> <Project Name> Software Requirements Specification For <Subsystem or Feature> Version <1.0> [Note: The following template is provided for use with the Rational Unified Process. Text enclosed in square brackets and displayed in blue italics is included to provide guidance to the author and should be deleted before publishing the document. A paragraph entered following this style will automatically be set to normal.] [To customize automatic fields (which display a gray background when selected), select File»Properties and replace the Title, Subject and Company fields with the appropriate information for this document. After closing the dialog, automatic fields may be updated throughout the document by selecting Edit»Select All (or Ctrl-A) and pressing F9, or simply click on the field and press F9. This must be done separately for Headers and Footers. Alt-F9 will toggle between displaying the field names and the field contents. See Word Help for more information on working with fields.] [Note: The Software Requirements Specification (SRS) captures the complete software requirements for the system, or a portion of the system.  Following is a typical SRS outline for a project using use-case modeling. This artifact consists of a package containing use cases of the use-case model and applicable Supplementary Specifications and other supporting information. For a template of an SRS not using use-case modeling, which captures all requirements in a single document, with applicable sections inserted from the Supplementary Specifications (which would no longer be needed), see rup_srs.dot.] Many different arrangements of an SRS are possible. Refer to [IEEE93] for further elaboration of these explanations, as well as other options for SRS organization.] <Company Name> Revision History Date Version Description Author <dd/mmm/yy> <x.x> <details> <name> Table of Contents 1. Introduction 4 1.1 Purpose 4 1.2 Scope 4 1.3 Definitions, Acronyms and Abbreviations 4 1.4 References 4 1.5 Overview 4 2. Overall Description 4 2.1 Use-Case Model Survey 4 2.2 Assumptions and Dependencies 4 3. Specific Requirements 5 3.1 Use-Case Reports 5 3.2 Supplementary Requirements 5 4. Supporting Information 5 Software Requirements Specification Introduction [The introduction of the SRS should provide an overview of the entire SRS. It should include the purpose, scope, definitions, acronyms, abbreviations, references and overview of the SRS.] Purpose [Specify the purpose of this SRS. The SRS should fully describe the external behavior of the application or subsystem identified. It also describes nonfunctional requirements, design constraints and other factors necessary to provide a complete and comprehensive description of the requirements for the software.] Scope [A brief description of the software application that the SRS applies to; the feature or other subsystem grouping; what Use Case model(s) it is associated with, and anything else that is affected or influenced by this document.] Definitions, Acronyms and Abbreviations [This subsection should provide the definitions of all terms, acronyms, and abbreviations required to interpret properly the SRS.  This information may be provided by reference to the project Glossary.] References [This subsection should provide a complete list of all documents referenced elsewhere in the SRS. Each document should be identified by title, report number (if applicable), date, and publishing organization. Specify the sources from which the references can be obtained. This information may be provided by reference to an appendix or to another document.] Overview [This subsection should describe what the rest of the SRS contains and explain how the SRS is organized.] Overall Description [This section of the SRS should describe the general factors that affect the product and its requirements. This section does not state specific requirements. Instead, it provides a background for those requirements, which are defined in detail in section 3, and makes them easier to understand. Include such items as product perspective, product functions, user characteristics, constraints, assumptions and dependencies, and requirements subsets.] Use-Case Model Survey [If using use-case modeling, this section contains an overview of the use-case model or the subset of the use-case model that is applicable for this subsystem or feature.  This includes a list of names and brief descriptions of all use cases and actors, along with applicable diagrams and relationships.  Refer to the use-case model survey report, which may be used as an enclosure at this point.] Assumptions and Dependencies [This section describes any key technical feasibility, subsystem or component availability, or other project related assumptions on which the viability of the software described by this SRS may be based.] Specific Requirements [This section of the SRS should contain all the software requirements to a level of detail sufficient to enable designers to design a system to satisfy those requirements, and testers to test that the system satisfies those requirements.   When using use-case modeling, these requirements are captured in the use cases and the applicable supplementary specifications. If use-case modeling is not used, the outline for supplementary specifications may be inserted directly into this section.] Use-Case Reports [In use-case modeling, the use cases often define the majority of the functional requirements of the system, along with some non-functional requirements. For each use case in the above use-case model, or subset thereof, refer to or enclose the use-case report in this section. Make sure that each requirement is clearly labeled.] Summary: [Give a brief synopsis of the overall purpose and flow of this functionality. Often, a an implementation priority is given.] Preconditions: [List the preconditions, if any, that must be true for this scenario to start, either as a single item, or as a bulleted list.] Triggers: [List the trigger(s) for this function, typically as a single item, but possibly as a bulleted list.] Basic course of events (main scenario): Actor System Screen [Numbered steps here, starting with the triggered as step 1, one step per table row. Youll almost always be using multiple rows.] [Numbered steps here, typically starting with step 2, one step per row, but often with the response to the Actors action on the same row.] [A picture, drawing, or description of the screen contents for this step, assuming that there is a screen for this step, and assuming that were on step 1, or that the screen contents have changed for this step. If the picture is too large to fit here, move it to an appendix, and just have a reference here.] Alternate courses of events (alternate scenarios) Actor System Screen [Same rules as above, but omit any steps here that are the same as the main scenario.] [Same rules as above, but omit any steps here that are the same as the main scenario.] [Same rules as above, but omit any screens here that are the same as the main scenario.] Post-conditions: [List the post-conditions, if any, that will have occurred to permanent state, or to session state, either as a single item, or as a bulleted list.] Supplementary Requirements [Supplementary Specifications capture requirements that are not included in the use cases. The specific requirements from the Supplementary Specifications which are applicable to this subsystem or feature should be included here, refined to the necessary level of detail to describe this subsystem or feature. These may be captured directly in this document or refer to separate Supplementary Specifications, which may be used as an enclosure at this point. Make sure that each requirement is clearly labeled.] Supporting Information [The supporting information makes the SRS easier to use. It includes: a) Table of contents, b) Index, c) Appendices. These may include use-case storyboards or user-interface prototypes. When appendices are included, the SRS should explicitly state whether or not the appendices are to be considered part of the requirements.] Confidential <Company Name>, <year> Page 5 <Project Name> Version: <1.0> Software Requirements Specification Date: <dd/mmm/yy> <document identifier> <Project Name> Software Requirements Specification For <Subsystem or Feature> Version <1.0> [Note: The following template is provided for use with the Rational Unified Process. Text enclosed in square brackets and displayed in blue italics is included to provide guidance to the author and should be deleted before publishing the document. A paragraph entered following this style will automatically be set to normal.] [To customize automatic fields (which display a gray background when selected), select File»Properties and replace the Title, Subject and Company fields with the appropriate information for this document. After closing the dialog, automatic fields may be updated throughout the document by selecting Edit»Select All (or Ctrl-A) and pressing F9, or simply click on the field and press F9. This must be done separately for Headers and Footers. Alt-F9 will toggle between displaying the field names and the field contents. See Word Help for more information on working with fields.] [Note: The Software Requirements Specification (SRS) captures the complete software requirements for the system, or a portion of the system.  Following is a typical SRS outline for a project using use-case modeling. This artifact consists of a package containing use cases of the use-case model and applicable Supplementary Specifications and other supporting information. For a template of an SRS not using use-case modeling, which captures all requirements in a single document, with applicable sections inserted from the Supplementary Specifications (which would no longer be needed), see rup_srs.dot.] Many different arrangements of an SRS are possible. Refer to [IEEE93] for further elaboration of these explanations, as well as other options for SRS organization.] <Company Name> Revision History Date Version Description Author <dd/mmm/yy> <x.x> <details> <name> Table of Contents 1. Introduction 4 1.1 Purpose 4 1.2 Scope 4 1.3 Definitions, Acronyms and Abbreviations 4 1.4 References 4 1.5 Overview 4 2. Overall Description 4 2.1 Use-Case Model Survey 4 2.2 Assumptions and Dependencies 4 3. Specific Requirements 5 3.1 Use-Case Reports 5 3.2 Supplementary Requirements 5 4. Supporting Information 5 Software Requirements Specification Introduction [The introduction of the SRS should provide an overview of the entire SRS. It should include the purpose, scope, definitions, acronyms, abbreviations, references and overview of the SRS.] Purpose [Specify the purpose of this SRS. The SRS should fully describe the external behavior of the application or subsystem identified. It also describes nonfunctional requirements, design constraints and other factors necessary to provide a complete and comprehensive description of the requirements for the software.] Scope [A brief description of the software application that the SRS applies to; the feature or other subsystem grouping; what Use Case model(s) it is associated with, and anything else that is affected or influenced by this document.] Definitions, Acronyms and Abbreviations [This subsection should provide the definitions of all terms, acronyms, and abbreviations required to interpret properly the SRS.  This information may be provided by reference to the project Glossary.] References [This subsection should provide a complete list of all documents referenced elsewhere in the SRS. Each document should be identified by title, report number (if applicable), date, and publishing organization. Specify the sources from which the references can be obtained. This information may be provided by reference to an appendix or to another document.] Overview [This subsection should describe what the rest of the SRS contains and explain how the SRS is organized.] Overall Description [This section of the SRS should describe the general factors that affect the product and its requirements. This section does not state specific requirements. Instead, it provides a background for those requirements, which are defined in detail in section 3, and makes them easier to understand. Include such items as product perspective, product functions, user characteristics, constraints, assumptions and dependencies, and requirements subsets.] Use-Case Model Survey [If using use-case modeling, this section contains an overview of the use-case model or the subset of the use-case model that is applicable for this subsystem or feature.  This includes a list of names and brief descriptions of all use cases and actors, along with applicable diagrams and relationships.  Refer to the use-case model survey report, which may be used as an enclosure at this point.] Assumptions and Dependencies [This section describes any key technical feasibility, subsystem or component availability, or other project related assumptions on which the viability of the software described by this SRS may be based.] Specific Requirements [This section of the SRS should contain all the software requirements to a level of detail sufficient to enable designers to design a system to satisfy those requirements, and testers to test that the system satisfies those requirements.   When using use-case modeling, these requirements are captured in the use cases and the applicable supplementary specifications. If use-case modeling is not used, the outline for supplementary specifications may be inserted directly into this section.] Use-Case Reports [In use-case modeling, the use cases often define the majority of the functional requirements of the system, along with some non-functional requirements. For each use case in the above use-case model, or subset thereof, refer to or enclose the use-case report in this section. Make sure that each requirement is clearly labeled.] Summary: [Give a brief synopsis of the overall purpose and flow of this functionality. Often, a an implementation priority is given.] Preconditions: [List the preconditions, if any, that must be true for this scenario to start, either as a single item, or as a bulleted list.] Triggers: [List the trigger(s) for this function, typically as a single item, but possibly as a bulleted list.] Basic course of events (main scenario): Actor System Screen [Numbered steps here, starting with the triggered as step 1, one step per table row. Youll almost always be using multiple rows.] [Numbered steps here, typically starting with step 2, one step per row, but often with the response to the Actors action on the same row.] [A picture, drawing, or description of the screen contents for this step, assuming that there is a screen for this step, and assuming that were on step 1, or that the screen contents have changed for this step. If the picture is too large to fit here, move it to an appendix, and just have a reference here.] Alternate courses of events (alternate scenarios) Actor System Screen [Same rules as above, but omit any steps here that are the same as the main scenario.] [Same rules as above, but omit any steps here that are the same as the main scenario.] [Same rules as above, but omit any screens here that are the same as the main scenario.] Post-conditions: [List the post-conditions, if any, that will have occurred to permanent state, or to session state, either as a single item, or as a bulleted list.] Supplementary Requirements [Supplementary Specifications capture requirements that are not included in the use cases. The specific requirements from the Supplementary Specifications which are applicable to this subsystem or feature should be included here, refined to the necessary level of detail to describe this subsystem or feature. These may be captured directly in this document or refer to separate Supplementary Specifications, which may be used as an enclosure at this point. Make sure that each requirement is clearly labeled.] Supporting Information [The supporting information makes the SRS easier to use. It includes: a) Table of contents, b) Index, c) Appendices. These may include use-case storyboards or user-interface prototypes. When appendices are included, the SRS should explicitly state whether or not the appendices are to be considered part of the requirements.] Confidential <Company Name>, <year> Page 5 Mahamadou Diallo University of Maryland Global Campus SWEN 645 Final Project Dr. Sheldon Linker Contents 1 Introduction 2 1.1 Purpose 2 1.2 Scope 2 1.3 References 3 1.4 Overview 3 2 Overall description 3 2.1 Product perspective 3 2.2 Website interface 3 2.2.1 The user interfaces 3 2.2.2 System interface 4 2.2.3 Communication interface 4 2.3 Website memory constraints 4 2.4 Website function 4 2.5 Temperature detection 4 2.6 Creation of group location/asset 5 2.7 Virtual bidding 5 2.8 Camera control system 5 2.9 An auction system 6 2.10 Radio system 6 2.11 New system addition user characteristics 6 2.12 Constraints 10 2.13 Dependencies and assumptions 10 2.14 Apportioning of system requirements 10 3 System specific requirements 10 3.1 External interface needs 10 3.2 Website functional requirements 11 3.2.1 Use cases 11 3.3 Performance requirement 24 3.4 Data needs 24 3.5 Quality needs: 25 3.5.1 System reliability 25 3.5.2 Availability 25 3.5.3 Maintainability 26 3.5.4 Portability 26 3.5.5 Usability 26 4 References 27 Introduction This software requirements specification SRS document refined details the customer requirements to enhance the overall features and operability of website of project SWEN645 RPG that will include the unification of various business activities together. The preliminary websites requirements include inventory, the contact me page, means of selling second hand non-fiction inventory, a page showing all the existing inventory in the store, a separate manga section, the trading system for the second-hand comic products, employment opportunity section, comic book rarity track and the type of merchandise that is in store. The website is created to meet the current store requirements as mitigation to the current unprecedented terms and conditions in which the businesses are operating. This SRS document is created to fulfill all the requirements of Project #4. The document reports the customer system requirements based on the meeting of the customer and the professor, the instructor of this course (enter course name). Purpose The SRS gives the website user features and the site functions, and it specifies in details of all the qualities and functional needs of the website. The document is intended for Project #4, the comic and non-comic book store owner and the website operator. Scope The new web functionalities is unified to be available on the home page of the website. The system will cover such functionalities as temper detection, arsonist detection, detection of personal shapes with fevers and how to contain them using infrared, radio to monitor crowds and identify the person calling the shots, radio to monitor the location of law enforcers, an auction system, the camera control system and the virtual bidding section in the website. References Mokhov, S. (2010). Selected Project Requirements. In Concordia University. http://users.encs.concordia.ca/~c55414/selected-project-requirements.txt IEEE Std 830-1998 IEEE Recommended Practice for Software Requirements Specifications, In IEEE Xplore Digital Library. http://ieeexplore.ieee.org/Xplore/guesthome.jsp Overview This file is produced in accordance to standards of the SRS that are elaborated in the ‘IEEE Recommended Practice for Software Requirements Specifications.’ Overall description Product perspective Project #4 is a continuing project that do not require the creation of a new website. It is specifically designed to meet the additional customer requirements with the addition of several tabs to the website. The website additions are designed to be secure and can be easily accessed by the authenticated user. Nonetheless, the access of some of the additional features such as camera control, arsonist detection will have a restricted access for only the website administrator. Website interface From the previous website specifications are available in a CSV format. The installation of new features to Project #4 will need an API in order to obtain data from the files. The user interfaces The user interface adopted will be easy to manipulate with minimum to no training required. Both the website admin and the guests will be able to interact with the website in any of the languages that is included in the language menu. The website will use the ZUI graphical environment which will assume the existing sense of contrast and color, and all the pages are printable using the functional keys. The additional website features will be made accessible from any of the pages opened. System interface The website was previously developed in a CSV format. UUIS will thus require an API to help in the importation of the data and the needed files. Communication interface The website contains an UI that is easily manageable and can be manipulated easily. The new customer requirements will be added in a format that could be accessed from any of the available ports. It will form the basis of communication between the new features and the user. The new features will be able through all the browsers where HTML papers interact. Website memory constraints The additional website features require 512 MB minimum memory on the primary disc and 3.5 GB on the secondary memory for efficient installation and execution. Website function The website will perform the following functions. The functions will however depend on the user’s level and the permission level as put by the features of the user. Temperature detection The new installation will help in system monitoring of the temperatures and help in the detection of arsonist in the current unprecedented time where most of the business have been looted and torched down during protests. The temperature detection will also help in the monitoring of the customer personal shapes to identify those with fevers which is vital in containing the Covid-19 virus. The feature will be available on the system menu functions on the administrator’s side. Add, edit, view, delete records This function will allow the website administrator with the ability and permission to add, edit, view, delete records in the most appropriate categories on Project #4. The four main databases that will affect the new additions include the ‘location’, ‘assets’, ‘persons’, and ‘licenses. The website administrator has also the authority to make bulk entry. The deleted information will mean the change of status. Creation of group location/asset The function will allow the grouping of all the inventory into various subgroups and combining the list of assets present in the store and help in monitoring the rare comic items in the store. Virtual bidding The functions will allow customers to place bids on various items through the website and the method of payment is reconfigured in the site. Camera control system This function will allow the administrator to have appropriate ability to control the cameras that will be installed in the store and monitor all the activities in the store. Th control will follow the user maps that will be preinstalled to control the movement of the cameras on the areas that needs covering. In case of the overlapping maps, the system will create the problem file which will allow the administrator to check it manually. An auction system The function will allow for the auction of various merchandise in the store and will be done live and streamed from the website. It allows the users to create merchandise subgroups and group them according to their price, rarity and according to the types. The auction function will have various packages within the system. Radio system This tab will have two subsections; monitoring the location of law enforcers and monitoring the groups to identify the ring leader and the person calling the shots. This is a security feature that will connected to both the computer system and the phone system for easy monitoring and ready access. New system addition user characteristics The users of these new features will be assigned various levels. the levels are as follows; The website administrator level, the customer and the new user. System usage leveling is mostly used for these features as an area of visibility so as to show data for the store, various store segments and on individual merchandise. For example, the system administrator is able to manage all the store assets while the employees take care of merchandise in the store. Moreover, the system usage leveling is used for approval or rejection of requests. Once one system user of some level submits his or her request, it is seen, approved or rejected by the main administrator. An exception of this is the requests submitted by the level three system user which does not need approval from anyone. These requests are approved automatically and directly after submission. Same roles from the different user levels have different approval permissions. From the general point of view, the following are some of the groups in which the users are grouped into: i. Store owner ii. Store employees iii. Users iv. New visitors The store owner, being the main administrator of the site has the overall power to change the role of user access to the new added features in the system. the typical set of permission for each level of the user are defined in the table below; Role Permission Store owner- system administrator i. Insert asset ii. Addtypeasset iii. See asset iv. Edit asset v. Delete asset vi. Borrow asset vii. Add group asset viii. Add type asset ix. Add subgroup asset x. Import asset xi. Dispatch asset to customer xii. See my merchandise xiii. Insert merchandise shelf location xiv. See merchandise shelf location xv. Delete shelf location xvi. Add merchandise group location xvii. See store print floor plan xviii. Import store floor location xix. Assign floor location to employee xx. Assign location to location xxi. Assign location to a group of employees xxii. See my store location xxiii. Insert all the merchandise licenses xxiv. See merchandise license xxv. Edit merchandise license xxvi. Delete merchandise license xxvii. Borrow merchandise license xxviii. Add type license xxix. Import merchandise license xxx. Assign license xxxi. See merchandise license xxxii. See merchandise xxxiii. Delete merchandise xxxiv. Add merchandise electric identification xxxv. Import merchandise xxxvi. Add merchandise subgroup Store employee i. Add temperature detection ii. Advanced crowd search iii. Auctioning of assets iv. Camera control v. Borrowing licenses vi. Create print report vii. Create bidding print report viii. Create auction print report ix. See merchandise x. Radio control xi. Create radio control print report Users i. Advanced auction merchandise search ii. Danced bidding merchandise search iii. Virtual store visits iv. Control camera store visits v. See merchandise shelf location New users i. See permissions for the regular customer Constraints The UUIS system used in the website is implemented in JAVA. In order to add new additions to the site, JVM system is required. In addition, the website will require phpMyAdmin and Tomcat. The website will be maintained to support up to 1000 users at the same time. Dependencies and assumptions The personal data information- title, ID, username, communication information, user’s level in the website and the user role is previously determined for all the users utilizing the newly added features. The access to the new features have some restrictions in relation to the information required and the level of the user in the system will determine the level of restrictions imposed. The system administrator- store owner, verifies and can access the users’ account in the system. the action that will be conducted on the new features need to be recorded and saved on a separate database for auditing and future reference purposes. Apportioning of system requirements The features will be available in all the existing site languages. While the whole websites might wait for future upgrades and versions, the new features will be available for all future upgrades and versions. The SDD of the website can be referred for a detailed list of the new functions. System specific requirements External interface needs The new features will take input from the external equipment such as the cameras, keyboards, scanners and the files stored in the memory. Various segments of the newly added features will develop printable output both on the screen and peripherals. They will utilize JDBC and MySQL system connectors to aid in communication with the database. Website functional requirements Use cases This will describe the required exemptions and procedures foreach of the function added. The required permissions of each of the website user are listed in the table described in section 2. Addition of new merchandise for bidding and auctioning Website actors: users with the required permissions Pre-requirements: i. No such merchandise or addition to the existing subgroup ii. Authentication of the session iii. Submission and approval of appropriate request Trigger: click bidding/auction menu, ‘add new.’ Procedure: a. User on the main page ‘click either bidding or auction menu’ merchandise and system transfers it to page ‘merchandise – add new’ b. The system will open the store ‘merchandise’ c. User selects the merchandise to be added from the available list displayed and the system indicates the appropriate features of each merchandise d. The system creates the date added e. The user provides the following information concerning the merchandise; name, subgroup, serial number, purchase number, barcode, color, rarity, request number, publisher and author of the book. f. The user assigns the location on the shelf g. The user terminates the process · User clicks create to save the changes made to the ‘bidding or auction page.’ · System checks the uniqueness of the barcode · The system updates the actions on the relevant tabs · The changes can be aborted by clicking cancel Post conditions: the new merchandise is added to the subsequent shelf Exceptions: a. Error from the database b. Error message from the system c. Empty required field d. Error message with a request for the user to repeat the process again e. Barcode not unique f. Error message with user requested to change the barcode Camera operation and store view Actors: users with the require permissions Preconditions: 1. Authenticated session 2. Cameras are running in the store Trigger: click menu’ monitoring- camera (choose camera number) – choose location to view Procedure: 1. Administrator user on the main page · Administrator user on the ‘main page’ click on ‘menu’ click on ‘monitor’ transfer to ‘camera’ click on ‘store section’ click on ‘camera number’ · Administrator user on the page ‘main’ click on menu ‘licenses’ transfer to store location · User on the page ‘main’ click on ‘location’ view area 2. System display · The system displays DB ‘camera’ in the list. The display depends on the section the user is in and the role of the user · System displays DB ‘location’. display depends on the role of the user · System displays ‘camera’. Depends on the role of the user · The user clicks on the display/virtual tab to see the camera details and to access the required section of the store · The system updates the action on the records for audits Post conditions: 1. Records on the appropriate camera is reviewed Exceptions: 1. Error message displayed by the system 2. Database error Radio system for monitoring Actors: the users with the required permissions Preconditions: h. Required activity present in the UUIS i. Authenticated session j. Submitted and approved appropriate request Trigger: click link ‘monitor’- click ‘radio monitors’ (choose between crowd radio monitor or law enforcement radio locator) Procedure i. User on the ‘main’ page · Click on the menu ‘monitors’ and system transfers to ‘monitors’ · Click on the radio monitor dropdown and system takes to ‘radio monitor’ display depends on the level and role of the user ii. System display · System displays the two types of radio installed in the store- crowd monitoring radio and law enforcement locator radio · System displays the type of radio identified and sends records to the memory for auditing and future use iii. User clicks view to view ‘crowds’ or identify the exact location of the law enforcers iv. System opens a sub window that shows activity of the party observed v. User makes decision on the same Post conditions: The records are modified and stored Exceptions: i. Error from the database ii. Error message displayed by the system iii. No crowd or law enforcement activity in the area iv. Error system display by the system and user requested to repeat again v. Radio monitor not selected vi. The system identifies an error in the selection of the radio monitor and requests the user to change the selection Editing data in the system Actors: website user with appropriate permissions Preconditions: i. Appropriated request submitted to the system ii. Authenticated session iii. Appropriate merchandise exists on the list to be selected Trigger: Click link ‘merchandise’ click the ‘edit’ button- select item location, click ‘edit’ click ‘add’ to add to the list of items on auction or for bidding Procedure: 1. User in the main page: · On the main page, click on the tab merchandise and the system transfers to the list of the available merchandise on the shelfs · On the main page, click on the page persons, systems redirects to the page persons · On the main page click location, the system redirects to the page location 2. System display · The merchandise available in the store is displayed in a table. The user is able to show the hidden columns and also be able to change the number of lines in any given page. However, the display is dependent on the level and the role of the user as well as the authority. · The system displays the location in a tabular form. The user is able to show or hide columns, as well as change the number of lines per page within the display. · System displays person in a tabular form. The user is able to show and hide columns, and as well as be able to change the number of liner per page. The display largely depends on the level, role and the authority of the user. 3. The user, system administrator, clicks edit next to the place tat require addition of the item 4. The system leads to a new window which shows the lists of merchandise already in line 5. User initiates the edits 6. The user clicks on the submission button to save the changes made and back to discard the changes initiated · The system checks on all the required data from the book such as the price, the author, the type, the barcode, the Dui number and the author · The list of the items available is updated Post conditions: Records in the store database are modified and updated. Exceptions: i. System error message and user asked to rectify ii. Database error iii. Information not matching any of the items iv. Error message and barcode change required v. Empty compulsory empty Deleting records from the bidding and auction section Actors: users with the required permission Preconditions: i. Session authentication ii. Existence of nonempty DB in the UUIS Trigger: Click on the menu asset then delete/ location- delete/ license- delete/ person- delete Procedure: i. On the main page, the user: · On the main page, the user clicks on the page assets- delete and the system will transfer the user to the new page ‘asset- delete’ · User on the main page clicks on the menu location- delete and the system transfers the user to the location- delete window · On the main page, the user clicks on the license- delete tab and the system opens the license- delete tab · On the main page, the user clicks on the tab person- delete and the system displays the person- delete window. 2. System display · The system will display the merchandise in a tabular form. The user has the permission to show or hide columns and change the number of the lines in any given page. The information displayed in this page is based on the level and the authority of the user · The display on the information on the location is on a tabular form. The user is able to change the number of lines per page. Information displayed is dependent on the level and the authority of the user · The information displayed regarding license is done in a tabular form. The users has the ability to show or hide the number of the line’s user page. The information displayed is dependent on the level and the authority of the user 3. The users are able to scroll through the list of the merchandise to see the different records in a tabular form 4. The user identifies and selects the items that are to be deleted by checking on the appropriate boxes on the right-hand side of the list 5. The user then clicks on the ‘delete selected items’ 6. The system shows, ‘are you sure you want to delete the selected items?’ click ‘ok’ to confirm. 7. System automatically updates the database and audit the files Post conditions 1. Records in the database are deleted Exceptions: i. Error message displayed by the system ii. Database error iii. No selection made by the user iv. Error message but user required to do the selection afresh Creation of group of merchandise for auction Actors: users with the required permission Preconditions: 1. Session authentication 2. There is need for such subgroup of merchandise in the auction process Trigger: Click on the asset ‘menu- create a group’ or click on ‘location – create group’ Procedure: i. On the main page, click on the tab ‘assets- create a group’ or ‘location- create a group and the system will transfer the user to the ‘asset-create a group’ or ‘location- create a group’ ii. The system displays ‘asset’ or ‘location’ in a table. The user is able to hide or show columns, be able to change the number of lines in a page. The information that ill be displayed depends on the level and the authority of the user. iii. A scroll bar will help the user to see the existing records in the table iv. The user will be required to select the ‘asset master’ which translates to the name of the group v. The user selects the asset master vi. The user is required to select the next step · User select on the ‘add master’ button so as to confirm the operation · In order to cancel the whole operation, the user clicks on ‘cancel button’ vii. The user is prompted by the system to select the ‘add children’ so as to confirm operation. The user can repeat this process as many as possible viii. User terminates the operations · the group is created in the store website location is created after the user clicks ‘create group’ 1. the process is updated on the audit file · the process can be aborted by the user by clucking ‘cancel post conditions: i. The new group of merchandise is created in the websites DB location Exceptions: i. the database error ii. error message from the system iii. more than one selection of the asset master iv. error message requiring the user to select only one asset master importation of camera graphics and images Actors: the users with the appropriate permission Preconditions: i. Session authentication ii. Need to integrate the old data and the UUIS Triggers: On the main page: click asset- import’ or ‘location- import’ or ‘person- import’ Procedure: 1. On the main page, the user; · The user clicks on the merchandise- import and the system will automictically transfers to the merchandise- import page · User clicks on the location- import and the system transfers to the page location · From the main page, the user clicks on the ‘person- import’ and the system redirects to the page 2. The user to select the type of import: · From the file location · User opens the camera file storage section · The copy of the videos or images is made 3. From the available list, the required media is selected 4. From the drop-down menu, the section where the items are to be imported to is selected 5. The user terminates the operation: · The user clicks to ‘insert data’ to add the selected files to be imported · The system will insert the imported assets into the identified database · The system generates the importation date · The audit file updates is automatically updated · ‘cancel’ button negates the process 6. The user fills the empty fields manually and he inserts in the appropriate databases Post conditions: i. The file is imported to the UUIS Exceptions: 1. The data imported is converted to the incorrect format 2. System error displays to indicate need to save in the right format 3. The user did not select the selection to import the data to 4. Database error 5. Error message from the system 6. System error requiring user to select location Auction and bids approval Actors: users with the appropriate permission Preconditions: 1. Session authentication 2. There is a request in the system which needs to be approved or rejected Trigger: The user clicks on the given request Procedure: 1. In the main page, click on ‘request- approve reject’ and the system displays information on the ‘request- approve/reject’ page 2. The user views all the auction and bidding requests that needs approval 3. The requests are selected from the given list 4. The user is able to view the request and analyze the details that come with it 5. The reaction button is chosen based on the decision of the user: · Click ‘approve’ if the bid is accepted. The changes are automatically updated on the system. · Click ‘reject’ if the request is rejected. 6. The website will update and save the changes on the audit file 7. The next level request is mapped by the system 8. An email is sent to the customer to notify on the status of their bid Post conditions: i. The bid is approved or rejected Exceptions: i. The user did not provide the reason for the rejection of the bid ii. The system shows an error message and requires the user to provide the reason for the rejection. View of all the system requests Actors: user with an appropriate permission Preconditions: Session authentication Trigger: Click on ‘requests- view all requests. Procedure: i. On the main page, the user clicks on ‘requests- view list of all the requests and the website will display the page. ii. All the requests are displayed on the screen iii. The user chooses their request of choice Post conditions: 1. All the requests are reviewed Exceptions: No exceptions Performance requirement The new features are required to provide support to the store activities simultaneously. The functions should support the number of site visitors as the existing one. Data needs The following is the ER diagram of the database requirements: Quality needs: System reliability The integrated website should work reliably with various backup and site recovery features put in place. In case there is an abruption end of any particular session, the unsaved data should be retrievable without loosing it and be displayed to the respective user so as the data can be saved or the session can be continued. The audit files and all the database files should be updated in the backup. Availability The website and all the features and functions to be made available throughout the year, except during the announced periodic maintenance processes. System security The website should be accessed by the authorized users at any given time. the website to employ a cryptographic protocols for example SSL. Automated system responses should be restricted by using CAPTCHA system. the sessions are to be ended by the system automatically when there is no activity for a specific period of time. Maintainability The interface should be user friendly so as to enable easy execution and use of the website. Portability The website to be accessed from all the browsers both for the mobile and desktop. The server and administrative technologies are made to be standard for the new features so as to be used in many platforms. Usability The GUI should be easy to learn. References Srs.doc. In itmorelia. Retrieved Aug. 5, 2021 from http://antares.itmorelia.edu.mx/~jcolivar/documents/srs.doc Software requirements specs. In techwr-l. Retrieved Aug. 5, 2021, from http://www.techwr-l.com/techwhirl/magazine/writing/softwarerequirementspecs.html UML Use Case Diagrams: tips and FAQ. In Andrew. Retrieved Aug 7, 2021, from http://www.andrew.cmu.edu/course/90-754/umlucdfaq.html#branching Van Vliet, H. (2008). Software engineering: Principles and practice (3rd ed.). Chichester, UK: John Wiley & Sons. Uber Ride Version: 4.2 Software Requirements Specification Date : 10/06/2021 MInc-001 Software Requirements Specification For Uber Ride Version 4.2 Mahamadou Mahi Diallo UMGC SWEN645 9040 Date Version Description Author 07/27/2021 4.0 overview description Mahi Diallo 07/28/2021 4.1 Use case model survey Mahi Diallo 07/30/2021 4.2 Application users modelling. Mahi Diallo 07/31/2021 4.3 Definition of specific requirements Mahi Diallo 08/01/2021 4.4 Case reports Mahi Diallo 08/02/2021 4.5 Supplementary requirements Mahi Diallo 08/03/2021 4.6 Supporting information added Mahi Diallo 08/04/2021 4.7 Appendix added Mahi Diallo 08/05/2021 4.8 Final edits Mahi Diallo Contents Introduction 4 1.1 Purpose 4 1.2 Definitions, Acronyms and Abbreviations 4 1.2 Scope 5 1.3 References 6 1.4 Overview 6 2.Overall Description 7 2.1 Use-Case Model Survey 9 2.1.1 Application Users’ Roles 12 2.1.2 Assumptions and Dependencies 14 2.2 Specific requirements 15 2.2.1 Use-case reports 15 Supplementary Requirements 32 Supporting Information 32 Appendix 34 Introduction Comment by Sheldon Linker: A title or header should not be the last thing on a page. (throughout) Mahi Inc specializes in the review and analysis of various applications and their features and also quality software in general. Mahi Inc also keeps track of the trends in various applications by having records of their features. This document is the Software Requirement Specification for Uber Ride System. It outlines most of the features of the application. 1.1Purpose The purpose of this document is giving an overview of Uber application requirements, its use cases and describing various techniques used in the designing these use cases. In addition, this document outlines the requirements of the application in the form of textural use cases. The system will implement several Use Cases which includes the following: · Requests a ride. · Make payment. · Enters details · Accept customer rider request. · Confirms payment. · Pick and drop passengers. · View passenger list 1.2 Definitions, Acronyms and Abbreviations · App – application · Application – this refers to a computer program that is designed to accomplish a specific task in the computer system. · Driver – a person who accepts ride requests from users, picks and takes them to their destinations. · Feature – an important component of the application that help users find what they are looking for. · GPS – Global Positioning System · PCs – Personal Computers · PDAs – Personal Digital Assistants · Rider – a user who takes rides using Uber app · SRS – Software Requirements Specification 1.3Scope The purpose of the Uber application is to make it easy for customers to get to their destinations by providing them with information on locations, such as those in Texas or even Silicon Valley, easy ways of requesting for a ride, estimated time of arrival, driver-partner information such as type of the vehicle, first name and license plate number. In addition, the application also calculates the fare automatically for customers when they arrive at their destinations. There are various features of the applications that will be discussed, and these features include. · Real-time tracking of driver · Allowing others to follow ride in real-time. · Keeping trip history · In-app call or chat option · Saves destinations. · Preferred driver · Multiple options of payment · Booking a ride for now or later · Adding multiple points of drop-off · Reviewing and rating of drivers 1.4References Alley, J. K. (2016). The impact of Uber Technologies on the New York city transportation industry. Grabher, G., & van Tuijl, E. (2020). Uber-production: From global networks to digital platforms. Environment and Planning A: Economy and Space, 52(5), 1005-1016. learn.umgc.edu. (n.d.). https://learn.umgc.edu/d2l/le/content/583657/viewContent/21631183/View. Comment by Sheldon Linker: Be consistent in your vertical spacing rules. Mäntymäki, M., Baiyere, A., & Islam, A. N. (2019). Digital platforms and the changing nature of physical work: Insights from ride-hailing. International Journal of Information Management, 49, 452-460. 1.5.Overview This subsection illustrates the software requirements specification of the Uber application, its features and how the SRS is organized. The requirements specification for this application is described further in the use cases. The features of this application are also described, roles and responsibilities of the users are explained. The use case model will also be designed to give more information on the processes that take place in the Uber application. The following Software Requirements Specification is divided into two major sections: Overall Description and Specific Requirements. 2.Overall Description Uber is a technology platform whereby the applications on our smartphones connect riders and driver-partners. Users is the cities where Uber is operating are able to use Uber rider application to request for a ride. In most of parts where Uber operates, users are allowed to pay their fare in cash, but they must select this option before requesting for a ride. The information about the rider is also provided in the app. In addition, the Uber application has the following features. i. Book a ride for now or later. This feature in the Uber application enables users to book the ride. With the book now or later feature, driver-partners can easily get rides and travel easily from one place to another. The book later feature enables users to easily book rides for a trip in future. This feature is very important for users who are about to leave their homes, office or even going for a doctor’s appointment and they want to get there in time. ii. Multiple options of payment Not every customer is comfortable paying via card or cash for their ride. Some of the users do not carry cash while a few of them do not want to share their card details in the application. Therefore, including multiple options of payments in the application has made it easy for the riders whereby they are able to select from various options that are available in the app. iii. Real-time tracking of driver This feature is included in the application to boost the satisfaction level of the users and make sure they are not frustrated when they are in the unknown regarding the driver. This is achieved with the help of GPS integration. This feature helps in tracking the location of drivers and which way they are traveling. iv. Preferred driver Regular Uber riders who take rides for their homes and offices come across several drivers and after some time they start having preferences of drivers based on the experience with them. The application allows these users to have a choice of their preferred drivers, and this gives Uber an added advantage. v. Allow others to follow ride in real-time. Since safety comes first to everyone, it feels safe when riders are able to share their details of the ride with some else who is mostly close to them. This feature allows someone else to keep an eye on the route that is taken by the driver and also letting persons know if they have reached their respective destinations safely or not. This feature is also very useful if the rider is new to a particular city and are not aware of the route that is being used by the driver. Therefore, sharing these details helps one to get an idea of whether the route taken is right or wrong and gives a chance for the person they’re sharing with to give insights into the route taken by the Uber driver. vi. In-app call or call option This feature is very important when the user wants to connect with driver mostly to ask them for direction and inquire on their whereabouts. In some other cases, users would want to chat directly with the support team for help. In addition, this feature also helps drivers to avoid the trouble of rider’s address when they can just call or chat with riders and get the details and also get directions. vii. Driver rating and review The reviews and ratings of the drivers provide more point of information about them, their behavior, and the kind of experience they offer to the riders. The riders who have had a trip with the driver in the past share their feedback and this helps one to know what they expect. The ratings are reviews are excellent ways of improving the business of Uber. viii. Add multiple drop-off points. ix. Saving of destinations x. Keeping of trip history 2.1 Use-Case Model Survey Users of the application should be able to retrieve information of their trip at any time and given an option to share this with their close relatives and friends. The following figure is the use case diagram for Uber. Figure 1: Driver & Rider Summary Use Case Diagram There are 7 Use Cases that make up the requirements of the Uber application and other details are shown in the table below: Use Case Description 1. Request a ride. Displays various functions to enable the rider to select the type of ride they need, location and request for the ride. Comment by Sheldon Linker: Dont allow a row to span a page boundary. You can control that with table row attributes. 2. View passenger list. Displays a list of the available riders who have requested for a ride. 3. Pick and drop passengers. Displays information on the locations to pick up and drop riders. 4. Confirms payment. Enables driver to confirm that the payment for the ride has been made by the customer. 5. Accept customer request. Notifies drivers of the requests made by the rider and gives them an option to accept the request. 6. Make payment. Displays various modes of payment a rider can choose from and enables them to make the payment. 7. Enter details Gives users an interface to input their detail 2.1.1 Application Users’ Roles This specifies and describes the roles, the associated responsibilities and all the use cases primarily driven by the users. Driver Driver is the role played by the persons specifically registered by Uber to accept ride requests from customers and take them to their destinations. Responsibilities The following are the responsibilities of a rider. · Accepting ride request from the customers and promptly attending to them. · Viewing the list of all the available passengers. · Picking up and dropping of passengers. · Confirming receipt of payment. Required capabilities. The rider requires the following skills to effectively interact with the Uber app. · Basic skills required in using a smartphone. · Ability to use Google Maps. · Good interpersonal skills. · Able to locate simple functionalities on smartphone such as GPS and others. i. Rider Definition A rider is the role played by the customers of the Uber app who request for rides using the application. Responsibilities The following are the responsibilities of a rider. · Entering their pick-up location. · Entering their destination. · Registering and entering their details into the system. · Choosing the type of ride, they need. · Requesting for a ride Required capabilities. The rider requires the following skills to effectively interact with the Uber app; · Basic skills required in using a smartphone. · Ability to use Google Maps. · Able to locate simple functionalities on smartphone such as GPS and others. 2.1.2 Assumptions and Dependencies External hardware · Client hardware · Employee workstations: these are the personal computers used by the workers to carry their daily tasks. · User client: refers to all the devices used in communication, such as PCs, PDAs and smartphones. · Client hardware · Local Area Network: this is the internal local area network that is used for communication among Ubers employees. · Internet: the global network applied in communication among users of the app, employees, drivers, and the Uber platform. Other assumptions i. It is assumed that all the riders are requesting for the ride while at the cities where Uber operates. ii. Another assumption is that the riders will pay the fare through option they chose before placing a ride. iii. It is also assumed that drivers are all-over the city so no customer will miss their ride. 2.2 Specific requirements This section outlines the requirements for the Uber application captured in the use cases and any applicable supplementary specifications. 2.2.1 Use-case reports This subsection describes the functional and non-requirements of the application. Use Case 1: Request a Ride Summary: The Request Ride option helps a rider to place a ride on the application. Preconditions: Pick up and drop off locations are selected. The type of ride is selected. Triggers: The rider select the Confirm Ride option after select pick up and drop points. Basic course of events (Scenario) Actor System Screen 1. The rider selects Enter pickup point. 2. The system displays a window to input the pickup location and destination. 3. The rider selects and confirms the ride type. 4. The system displays the Confirm Pickup option for the user. Alternative paths: · The requested ride is canceled. Actor System Screen 1. Rider selects Cancel 2. The system displays the Cancel Request. 3. Rider clicks the Cancel Request option. 4. The system notifies the driver that the ride has been cancelled. Post conditions: · A ride has been requested. · Successful cancellation of a ride. · Exceptional cases: · No ride available in the area. · Rider changes their route or cancels ride. · Use Case 2: Accepts customer ride request · Summary: The Accept Ride Request option helps a driver to view the available rides and either accepts or doesn’t. · Preconditions: A rider must request for a ride. · Triggers: The rider asks for a ride. · Basic course of events Actor System Screen 1. The system notifies driver of the available rides. 2. User selects the accept ride option. Post conditions · The driver accepts the ride request. · Exceptional cases · Driver time out · Insufficient account balance Use Case 3: View Passenger List Summary: The system displays a number of the available passengers that drivers should choose from or rather accept the rides. Preconditions: A ride has been requested by a customer. The type of ride is also selected. Triggers: The driver selects the view available rides option. Basic course of events (Scenario): Actor System Screen 1. The user selects the view passenger list option. 2. The system displays the list of available rides. Alternative paths: · The requested ride is canceled. Actor System Screen 1. The system removes that ride from the list Post conditions: · A ride has been requested. Exceptional cases: · No ride available in the area. · Rider changes their route. · Rider Cancels ride. Use Case 4: Confirm payment Summary: The Confirm Payment option helps the driver to verify that payment has been made by the rider and it is of the right amount. Preconditions: The rider has been picked up and dropped off at their destinations. Payment has been made by the rider. Triggers: The rider clicks the make payment option. Basic course of events (Scenario) Actor System Screen 1. The rider makes payment. 2. The system displays the amount paid. 3. The driver confirms payment. Post conditions: · Payment has been made · The right amount of fare has been paid Exceptional case: · No payment method available Use Case 5: Make payment Summary: The Make Payment option enables a rider to choose the mode of payment they want to use in making payment and paying for their fare. Preconditions: Pick up and drop off locations are selected The ride is confirmed The type of ride is selected Triggers: The rider select the Make Payment option after confirming the ride. Basic course of events (Scenario) Actor System Screen 1. The system displays the mode of payment. 2. User selects a mode of payment and makes the payment for the fare. Alternative paths: · The preferred mode of payment is not displaying Actor System Screen 1. The system displays the other available payment methods. 2. Rider selects the method of payment they want and finish the payment process. 3. System processes the charge 4. Displays a receipt for the changeuser. 5. Displays a receipt for user Post conditions: · A rider selects their preferred payment method · The ride is also confirmed Exceptional case: · No payment method displayed by the system Use Case 6: Pick up and drop off passengers Summary: The system displays options for the users to notify users of their pickup and drop off ETA Preconditions: Pick up and drop off locations are selected. The type of ride is selected. The ride has been confirmed Triggers: The rider select the Confirm Pickup and Destination option Basic course of events (Scenario) Actor System Screen 1. The rider enters the pickup and destination. 2. The system displays the available locations for pickup and destination. Alternative paths: · The rider changes the pickup location and destination Actor System Screen 1. Rider selects an alternative pickup and destination. Post conditions: · System accepts the entered locations · The rider confirms that the locations entered are correct Exceptional case: · No pickup and destinations Use Case 7: Enter details Summary: This option enables users to update their personal information in the system Preconditions: User selected the create profile option Triggers: The rider select the Create Profile option Basic course of events (Scenario) Actor System Screen 1. The rider selects create profile option. 2. The system displays a confirm account setup window. 3. The rider selects and confirms the ride type. 4. The system displays the Confirm Pickup option for the user. Post conditions: · A user profile has been set up Supplementary Requirements The application has other more requirements and even more use cases. Riders are also able to cancel ride requests before they are picked, and this might be due to several reasons such as to attend to a personal emergency. The applications are only supported on smartphones, and this means that both the driver and rider must have one. The phone should also support GPS to make it easy for the rider and driver to locate each other. Supporting Information The following is an image for Uber application and other related information. Appendix The Uber application can be downloaded from the Google Play store. Guidelines on how to install and use the application can be found on their official website, that is, www.uber.com. 31