System Requirements Homework - System Engineering

timer Asked: Nov 15th, 2016

Question description


I'm working on my project " RFID tags with phone applications" and I already finished doing the scope and the system specification requirements. My system specification requirements file will be attached below.

I just need a little help on four things:

1- I need detailed explanation about the system and operational requirements (functional and non-functional)

2- brief explanation about the functional flow block diagram. (diagram is attached)

3- brief explanation about assumptions made.

4- create an index of the file information. (file is attached)

Thank you,

System Requirements Homework - System Engineering
System Requirements Homework - System Engineering
Running Head: SYSTEM REQUIREMENTS SPECIFICATION System Requirements Specification SYSTEM REQUIREMENTS SPECIFICATION 2 System Requirements Specification (version 1.0) Project: RFID tags with phone applications Date(s): November 7, 2016 Prepared by: Document status: Proposed 1. Introduction This document contains the system requirements for ‘RFID tags with phone applications’. These requirements have been derived from several sources, including a. An introduction to RFID technology b. RFID: a technical overview and its application to the enterprise c. RFID field guide: deploying radio frequency identification systems 1.1 Purpose of This Document This document is intended to guide development of ‘RFID tags with phone applications’. It will go through several stages during the course of the project: Draft: The first version, or draft version, is compiled after requirements have been discovered, recorded, classified, and prioritized. Proposed: The draft document is then proposed as a potential requirements specification for the project. The proposed document should be reviewed by several parties, who may comment on any requirements and any priorities, either to agree, to disagree, or to identify missing requirements. Readers include end-users, developers, project managers, and any other stakeholders. The document may be amended and proposed several times before moving to the next stage. Validated: Once the various stakeholders have agreed to the requirements in the document, it is considered validated. Approved: The validated document is accepted by representatives of each party of stakeholders as an appropriate statement of requirements for the project. The developers then use the requirements document as a guide to implementation and to check the progress of the project as SYSTEM REQUIREMENTS SPECIFICATION 3 it develops. 1.2 How to Use This Document We expect that this document will be used by people with different skill sets. This section explains which parts of this document should be reviewed by various types of readers. Types of Reader This document is aimed at security practitioners and system administrators. They are the key targets, as they are in a better position to offer technical support. Technical Background Required To understand the documentation, the reader needs a bit of knowledge about how mobile applications work. The jargon used in the documentation is not overly technical, but requires some understanding of the terminologies used. Overview Sections For readers, whose only interest is gaining a rough knowledge of the system, they could just read the sections about product description. Reader-Specific Sections Section 3 is for technically conversant readers. It features detailed and specific information about the system. Readers could therefore read or skip this section depending on their needs. Section Order Dependencies The documentation is in the order it is intended to be read in; hence, readers can just follow along as easily. 1.3 Scope of the Product This product realized through this project is aimed for mass production. The target clientele are people with cars, and the technology will be applied in parking places. 1.4 Business Case for the Product SYSTEM REQUIREMENTS SPECIFICATION 4 The product is required because parking spots are limited at the mega mall. After it is put to use, it will be easier for owners to locate cars using their mobile phones. At the mega mall, locating one’s car in the midst of six thousand other cars is quite a challenge. 1.5 Overview of the Requirements Document The proposed project is medium in size. Since it only involves one mall, it is not big enough to be considered large. Also, it cannot be considered small, since the mega mall is a pretty big shopping place, serving hundreds of thousands of customers weekly. 2. General Description The RFID tags and phone applications project was coined to address the growing need to easily access one’s car in crowded parking places. When the project goes through, people will be able to locate their cars with ease at such places. The project targets frequent shoppers, especially those shopping at the mega mall. In during the development period, there were challenges of implementation of the project due to costs, especially of the chips. Also, gathering data from the mall was restricted, citing security reasons. So, information such as number of customers per a given period was assumed. 2.1 Product Perspective The RFID program is developed for remedy the challenges of accessing cars from crowded parking places. It will allow for efficacy in parking, and accessing cars afterwards. The primary stakeholders are players in the transport and security industry. They have been key in development of the program. The product is being developed by a team of visionaries seeking to revolutionise shopping at the mega mall. The finished product will be beneficial to shoppers at the mall, especially those who drive. 2.2 Product Functions The product uses radio frequencies to monitor and inform people about the location of their cars in parking spots. Using the program, car owners can determine where their cars are in real time, thereby accessing them effortlessly after they are done shopping. SYSTEM REQUIREMENTS SPECIFICATION 5 2.3 User Characteristics The program is user-friendly. Users shall not require technical knowledge to use the application. The only necessary skill is conversance with the use of smartphones, since the application will be run on such platforms. 2.4 General Constraints There were particular constraints facing developers in the process of completing the program. Time was limited, since the program was needed for approval within a specified time frame. Also, developing the app for different mobile platforms, mainly iOS and android was time consuming and repetitive. Finally, the program was built from scratch, with no underlying preexistent software to reduce development time. 2.5 Assumptions and Dependencies The project developers worked on the assumption that the finished product would be appealing to target consumers, and that they would be satisfied by the invention. The program is dependent on an administrative team. The team will be maintaining and securing databases containing client data from the application. 2.6 Maintenance and Support Concept During the programs development life-cycle, the development team will be maintaining all stages of the projects life-cycle. During its beta version, the maintenance team will be making improvements and corrections in the programs operations, whereas the support team will be garnering responses from the users, and using these to model an appropriate final version. SYSTEM REQUIREMENTS SPECIFICATION 6 2.7 Functional Analysis and Allocation Req. analysis higher level decomposition Functional levels Functional architecture Internal/extern al interfaces synthesis SYSTEM REQUIREMENTS SPECIFICATION 7 2.8 Cost Analysis Implementing the system is budgeted at $300000. It is a massive project that especially requires lots of funding due to the cost of hardware to be used in the program. The projected costs are inclusive of development fee and other miscellaneous costs. The chips are budgeted at $50 each, and $24000 when bought in bulk. The remaining $60000 will be used to pay the development process. 3. Specific Requirements This section of the document lists specific requirements for ‘RFID tags with phone applications’. Requirements are divided into the following major sections: System and Integration requirements: These are detailed specifications describing the functions the system must be capable of doing. Operational requirements: These are detailed non-functional requirements describing other desired attributes of the overall system and how the system will run and communicate with operations personnel. User 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. 3.1 System and Integration Requirements The system is minimal. As such, the system shall only be processing outputs from data it is fed with by the user. The system shall have minimal to zero reliance on preexistent systems. 3.2 Operational Requirements The system requires to be online to operate. An internet connection shall be required. Other than, an internet connected device is the only other necessary thing. 3.2.1 Performance The system operates on a real-time basis. As such, the user shall receive updates on queries regarding car packing timely. The user shall require an internet connection to access the information. Updates in this system are instant. The system has been designed to avoid all instances of lag and malfunction. Considering that cars are constantly getting in and out of the SYSTEM REQUIREMENTS SPECIFICATION 8 parking spaces in their hundreds per minute, update of queries for this system shall be as fast as well. 3.2.2 Physical Characteristics The RFID chips are small in size, as well as weight. Therefore, they will not be cumbersome. Their speed, however, is phenomenal. 3.2.3 Effectiveness/Reliability The effectiveness of the system shall be seen through the output of the desired results to the clients. It is reliable and shall output the necessary information regarding the particular query. The probable damage under the use of this system is loss of time to the client. There are no risks of physical damage at all, since it does not include mechanical components. 3.2.4 Availability The mega mall is open for shopping full time, day and night, all year around. To meet these needs, the program shall be online and operation as much time as well. The maintenance and support teams shall see to it that, the system is never offline, rendering its inaccessible to clients. 3.2.5 Recoverability The system features real-time analysis mechanisms. Also, it runs in multiple duplicated databases. In the instance one is inaccessible for whichever reason, it shall switch the databases to stay online. That way, such errors shall remain unnoticed. Client data will stay uncompromised. Also, the databases are set on auto-save. Therefore, any that fails shall be restored to the moment right before it went offline. With that, data loss shall be minimal if any. Cloud storage also offers remote storage of data from our physical databases. In the instance that the databases incur physical damage, clients will be served from the cloud, allowing to continuity of operations. 3.2.6 Maintainability SYSTEM REQUIREMENTS SPECIFICATION 9 The system’s components, both software and hardware, are capable of extension, as well as reuse. 3.2.7 Usability The system is outright and easy to use. It entails a minimal interface that will be easy to use. Customers need not be proficient with using such systems, since it also includes a user manual just in case. 3.2.8 Supportability The development team has put into consideration, future needs that may come up, requiring changes in the code or infrastructure. The software has been written into segments that can be individually written without majorly affecting the other system components. As for the hardware, duplication makes is easy to turn some parts off, and repair or replace them. 3.2.9 Portability/Mobility Since it is meant for mobile users due to the circumstances of its operation, production has targeted the major mobile platforms, android and IOS. With time, development shall consider BlackBerry, Symbian, and Windows. As for the hardware, the program is pretty lightweight, hence no need for high-end mobile resources. Average specification mobile phones shall run the application seamlessly. 3.2.10 Sustainability The program is sustainable. After launch, it requires nothing other than minimal updates and hard/software maintenance. The chips used are very durable, and shall not need to be replaced every now and then. 3.2.11 Security and Privacy Users are required to keep the login details in confidence. On the server side, user data shall be encrypted so that, even if accessed, the intruder shall not decipher the information, safeguarding the users’ interests. User information is not shared with third parties. It is the SYSTEM REQUIREMENTS SPECIFICATION 10 business of the users and the service providers. Confidential information shall remain in confidence, and will never be disclosed. 3.2.12 Safety Since users will mostly come into contact with the soft, rather than the hard components of the system, safety is not really an issue. It only applies to the staff who will be managing the infrastructure. Even with the personnel, the risks are nothing out of the ordinary. The venture is of no harm to the environment whatsoever. 3.2.13 Maintenance To keep the system running, personnel skills required will be database administration and management, and online security. These people shall ensure the system is running seamlessly, as well as securely to avoid data breaches. 3.2.14 Data Retention Client data shall not be held indefinitely. For registered users, certain information shall be retained in the system servers, such as preferences. This data will be erased from the systems as other data is stored. There is not specific time that user data shall be held by the company. The only information that will be held indefinitely is client data pertaining to registration and user profiles. 3.2.15 Environmental factors The system is not reliant on environmental factors for its operation. It will be operable in whichever environmental situations. 3.3 User Interface Requirements The user interface is easy to interpret. It comprises of a bird view of the parking space. Due to its real-time capacity, it will also include two blinking dots, a blue and a red one. The blue one indicates where the user is, on the map. The red one indicates where the user’s car is, and distance in feet. Also, it will include a compass that shows the directions, and major components of the parking place shall be labeled. Once the user starts moving, it will indicate in real time, SYSTEM REQUIREMENTS SPECIFICATION 11 how much distance is left to cover. When a user eventually gets to the car, the two dots merge, and become green, showing success. 4. High-Level Technology Architecture The application is web based; hence, makes use of typical architecture. The system will make use of simulation systems that provide demo instructions for custom situations. Besides, the program on the user’s gadget will be interacting with the chipset in the car system to simulate routes and ways to get to the parked car. 5. Customer Support The customer support team shall address client queries. The program includes an easily accessible hotline. Through it, the clients can reach the support team, who can then offer timely responses. Besides, other modes of communication are accommodated as well. Clients can send emails, instant messages, and text messages as well. Moreover, they can interact directly with the support team on social media sites where they can access solutions to similar problems people have had in the past. Through this, shared problems on social media will make it easier for other users to access solutions for potential problems. 6. Appendices The complete documentation and licenses will be appended with this document. Also appended will be, the software information and aspects of the code that are public 7. Glossary RFID – radio frequency identification Phone Application – software designed to run on a mobile device. Mega Mall – a shopping area that is very large, and had many businesses of all kinds. Parking – a place where cars are left temporarily. Activation – the process of rendering something active after certain processes. Risks – situations where damage or loss are likely to occur. Documentation – official information about the product. Dependency – reliance on other aspects of a system. Phase – a stage in the development process. SYSTEM REQUIREMENTS SPECIFICATION 12 8. References Bhuptani, M., & Moradpour, S. (2005). RFID field guide: deploying radio frequency identification systems. Prentice Hall PTR. Cooper, R. G. (2009). Identifying industrial new product success: Project NewProd. Industrial Marketing Management, 8(2), 124-135. Ekinsmyth, C. (2002). Project organization, embeddedness and risk in magazine publishing. Regional studies, 36(3), 229-243. Hovakimian, G. (2011). Financial constraints and investment efficiency: Internal capital allocation across the business cycle. Journal of Financial Intermediation, 20(2), 264-283. Kracklauer, A. H., Mills, D. Q., & Seifert, D. (2004). Customer management as the origin of collaborative customer relationship management. In Collaborative Customer Relationship Management (pp. 3-6). Springer Berlin Heidelberg. Need, W. C. D. H. P. (2006). Human resource management: Gaining a competitive advantage. Penttila, K., Pere, N., Sioni, M., Sydanheimo, L., & Kivikoski, M. (2005, June). Use and interface definition of mobile RFID reader integrated in a smart phone. In Proceedings of the Ninth International Symposium on Consumer Electronics, 2005.(ISCE 2005). (pp. 353-358). IEEE. Want, R. (2006). An introduction to RFID technology. IEEE Pervasive Computing, 5(1), 25-33. Weinstein, R. (2005). RFID: a technical overview and its application to the enterprise. IT professional, 7(3), 27-33. Whited, T. M., & Wu, G. (2006). Financial constraints risk. Review of Financial Studies, 19(2), 531-559. Wood, A. (2008). Globalisation and the rise in labour market inequalities. The economic journal, 108(450), 1463-1482. SYSTEM REQUIREMENTS SPECIFICATION 9. Index 13

Tutor Answer

(Top Tutor) Studypool Tutor
School: Boston College
Studypool has helped 1,244,100 students
flag Report DMCA
Similar Questions
Hot Questions
Related Tags
Study Guides

Brown University

1271 Tutors

California Institute of Technology

2131 Tutors

Carnegie Mellon University

982 Tutors

Columbia University

1256 Tutors

Dartmouth University

2113 Tutors

Emory University

2279 Tutors

Harvard University

599 Tutors

Massachusetts Institute of Technology

2319 Tutors

New York University

1645 Tutors

Notre Dam University

1911 Tutors

Oklahoma University

2122 Tutors

Pennsylvania State University

932 Tutors

Princeton University

1211 Tutors

Stanford University

983 Tutors

University of California

1282 Tutors

Oxford University

123 Tutors

Yale University

2325 Tutors