systemrequirements xscope xfunctionalrequirementsspecification x
need to make a Functional Requirements Specification document for my system engineering project “RFID tags with phone applications “. I already finished doing the scopedocument and system requirements specification which will be attached below to have an idea about the project.
I attached the functional requirements specification template that have all the requirements I need. You just need to fill it out.
Thank you,
Running Head: SYSTEM REQUIREMENTS SPECIFICATION
SYSTEM REQUIREMENTS SPECIFICATION
2
System Requirements Specification
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 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
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.
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.
2.7 Functional Analysis and Allocation
Req. analysis
Internal/external interfaces
Functional architecture
synthesis
Functional levels
higher level decomposition
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 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
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 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, 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.
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.
9. Index
Running Head:
RFID TAGS WITH PHONE APPLICATIONS
1
7
RFID TAGS WITH PHONE APPLICATIONS
RFID tags with phone applications
Table of Contents
Introduction: Project description
2
Problem statement
3
Project objectives
3
List of functionality
4
Timeframe
4
Target customer
7
Risks 7
High-level risks 7
Insignificant risks
8
Outstanding issues
8
Assumptions
9
Constraints
9
Dependencies
10
Critical success factors
10
Policy impacts
11
Procedure impacts
11
Legal impacts
12
Training 12
Benefits of the project
12
Possible failures of the project
13
Conclusion
13
Title:
Attaching a RFID tag to a car for each parking spot and connecting it to a phone application.
Introduction: Project description
The project will be based on an improvement of services offered by an organization through designing a RFID tag that will be attached to each and every car at every parking spot. The organization which will accommodate the project is a mega mall that has an approximation of 750,000m2. The mega mall accommodates 640 retail spaces, a screen cinema complex, an exhibition area and a parking space that accommodates 6000 vehicles. Due to the large size of the mall, RFID tags are the best for use in the location of cars after a keen analysis of the advantages of using the tags in other organizations. The tags will be majorly located in the parking slots where they will be attached to each and every vehicle that is parked and linked to a phone application that is capable of sending information on the location of the vehicles and other information concerning location area of retail stalls and routes to follow. Moreover, the application will also be able to locate the entry points and exit points of the mall as well as other shopping centers that are around the mega mall.
Problem statement
The mega mall is a very large spaced organization with numerous of activities that are carried on. Several customers averaged at 450,000 per week visit the mega mall for shopping and other services. Moreover, the routes to follow within the mall are numerous and may end up very confusing. Due to the lots of activities that take place within the mall, it is common to have cases where customers forget the spaces they have parked their vehicles and may go a very long period trying to locate their vehicles. The mall is also very big and searching for routes to entry and exit may be confusing. There are a lot of visitors in the mall daily which makes it hard for most customers to locate their way in and out of the mall easily. Due to the problems experienced by the mall on the location of vehicles in the parking lots, the location of routes and retail shops, the introduction of RFID tags would provide a major solution and reduce the problems as mentioned.
Project objectives
The project has the main objective of optimum satisfaction of customers who visit the mega mall each and every day. The objectives will be achieved after introducing RFID tags on the cars at each parking spot to ensure easy tracking of vehicles by customers at the parking lots. Moreover, the application that will be developed will implement other functions such as access to routes to specific retail shops and routes to entry and exit from the mega mall. The success of the project will lead to the realization of the objectives set above. However, any interference with the process would be due to improvement of the system to allow for a more efficient program that will be better than the use of RFID tags on vehicles (Weinstein, 2005). In addition to that, if the system does not prove to be efficient, more research will be based on the possibilities of its failure and new methods devised for a more efficient program. The processes will, therefore, lead to the achievement of the main objective of the organization upon introduction of RFID tags on vehicles at parking slots.
List of functionality
The project is based on enhancement of efficiency in the location of vehicles as well as routes within the organization. A phone application must be developed to help in communication with the customer. A RFID tag should also be available to enable location of a vehicle or an item (Weinstein, 2005). The radio frequency identification tag will be able to send its location after being tagged on a vehicle to the user. The tag has a series of numbers that needs to be fed into the application for access to the location services of the vehicles. Development of the application will require a skilled outsourced expert who will be able to develop an accurate phone application. The application should have a connection to the waves sent by the RFID tag (Weinstein, 2005). To develop the application, the expert requires a range of computer programs that will help in generating an effective application that can communicate to the radio-frequency identification tags irrespective of their locations. The tags used should have radio frequencies enabled that is capable of directing signals to a specific user (Weinstein, 2005). The tags are activated as the phone applications are activated and connected to allow for location of the tag. Therefore, the major functionalities that will be required to start up the project will include Radio-frequencies identification enabled tags, experts to develop a phone application and range of computer program assisting in the development of phone application (Weinstein, 2005).
Timeframe
The entire project should take a range of three weeks to two months. The entire project will involve the development of the phone application, development of the RFID tags and encoding of information into the tags for easy identification by the phone application (Pentilla, 2005). The last procedure for the project would involve its testing to identify the weaknesses, strengths, and possible fallouts during implementations. The project will, therefore, be sectioned into different time periods which will allow for completion of specific sections within given time limits. The program of the project is divided into four sections. The first section would involve sourcing of information to build up a phone application. The second section will involve activation of radio-frequency identity on the tags and creation of phone application. The third section would involve testing of the compatibility of the two services through radio frequencies. The fourth section involves addition of services into the phone application and correction of any fall outs that might have been realised in the third section. The time frame for the sections as named are, the first section would take one week, the second section will cover two weeks, and the third section will cover one week while the fourth will cover two weeks. A total of six weeks will be required for full completion of the entire project and its implementation. Moreover, the time limits might be extended when technicality issues arise to the system. The technicality issues include faulty tags and unresponsive phone applications. The project would, therefore, consider extension for the time period to allow for development of effective system. The following is a summary for the time schedule for the project.
Project Program
Activities
Sourcing of information
Week 1
– Obtaining Information regarding the type of phone application to be developed
– Deriving information on compatibility of the radio frequencies and the phone application to be created.
Creation of a phone application and activation of RFID tags
Week 2 and 3
· The phone application will be created using an expert
· Radio frequencies will be activated in the radio frequency identification tags.
Testing compatibility
Week 4
· The phone application will be tested on the connection and location of the tags upon activation.
Repairs
Week 5 and 6
· Any possible fall outs will be repaired in this stage as more information is fed into the phone application to allow for other more services other location of a tag.
Target customer
The project aims at creating a program that will enable easy location of vehicles at the parking garage which is its main strategy. The mega mall receives a huge number of customers in each week and due to the large numbers, there are a lot of confusions from the customers on the entrance, exit and location of their vehicles. The big mall has several parking slots which may lead to tiresome search for the right vehicle and search for direction for exit and entrance into the mall. The main target for the project is on the customers who own vehicles (Kracklauer, 2004). The tags are only provided to customers who own vehicles. The vehicles are parked and left with tags that are fitted with radio frequencies and connected to a phone application. Activation of the system allows for location of the vehicle. However, other customers are also able to use the phone application for location of their routes and the retail shops that are available in the mega mall. The phone application also has an entry and exit direction for the mega mall. However, the project is aimed at producing the use of RFID tags in the mega mall which is targeting the vehicle owners who are also customers at the mega mall.
Risks
The project may experience series of risks. The risks can be classified as either high-level risks or insignificant risks. The risks are any problems that are foretold that may take place to the project upon its development and implementation. The next is an illustration of the high level risks.
High-level risks
The high-level risks involve very significant risks that may take place to a project that involves the availability of resources, skills of a person, changes in priorities and time period changes. Over the development and implementation period, the period might experience different risks that prevent its success hence slows down the implementation. Since development of the RFID tags involves technical know-how, selection of the experts should consider their past experiences (Wood, 2008). The development process may face wrong application of devices which leads to errors in connection of the tags to the phone applications. Moreover, the development process may also face delayed progress due to the experience of the experts used in the process and availability of enough resources (Cooper, 2009). Resources used in the project should be ready to avoid any delays. Moreover, the project may face a risk on the priorities of the organization in the creation of the program. The organization might priorities on other requirements that might slow down the success of their system or reduce the concentration on the development of the system leading to its failures (Cooper, 2009).
Insignificant risks
The risks do not have much impact on the project (Ekinsmyth, 2002). The risks include documentation of the process and record keeping. During the process of developing the system for RFID tags, it should be documented for easy retrieval of the entire process for future use. However, the organization might face the risk of lack of documented reports on some procedures that have been conducted. The documentation does not directly affect the project but has future effects on the project (Ekinsmyth, 2002).
Outstanding issues
The project has several key issues that may result in its success. However, there are some other outstanding issues that, when not realized, might lead to failure of the project. The outstanding issues that result in reduced success include the extent of the cooperation of the organization to the demands of the project managers. The organization should be swift in responding to the demands of the project managers to ensure effective issuance of information to the project managers (Ekinsmyth, 2002). The information helps in developing an effective system. The next part illustrates the assumptions that have been used by the project.
Assumptions
The project, during its development, will implement a number of assumptions. The assumptions will help in generate successful result for the entire process of its development and implementation. During the start-up of the project, it is assumed that the resources are easy to find or they are available (Ekinsmyth, 2002). The resources should be easily available so as to have a smooth process of developing the entire phone application and linking it to the RFID tags. The project will also assume that there will be customers who own vehicles in the mall. Most of the customers do not own vehicles but in most cases, the parking slots have several parked vehicles. Therefore, the project assumes that the customers that attend to the mall have vehicles or that there will be vehicles present every day at the mall. In addition to that, the project will have an assumption that the radio frequencies have a very wide area of signals that are capable of helping the customers to locate the position of the tagged vehicles and also give direction even on long distances.
Constraints
Development of the project will experience some constraints that will reduce the efficiency of the process of development. Constraints can be as a result of financial fall outs, increase in prices of resources. Labor costs and efficiency of the devices used in the development of the project. Since the project requires skilled personnel, there will be constraints in the labour provided by the employees of the organization do not have enough knowledge on the development of a phone application and setting up of a RFID tag that is accessible by the phone application (Pentilla, 2005). The organization will have to outsource a skilled individual who will increase the expenses on labour. Shortage of skilled and experienced labour is a source of constraint on the process of development of the project. Moreover, financial constraints can also slow down the process of development as the organization has to buy many tags that will accommodate all the customers. Purchase of the tags would also come along with replacement tags. The organization, therefore, has to plan for the expenses of the tags and other resources that are required which may lead to a change in priorities due to financial constraints. However, the restrictions do not lead to failure of the process, but they just slow down the whole process. Therefore, the process will still be a success in the long run.
Dependencies
The project would depend on the mobile phones with the phone applications built by the organization. A customer who does not have a cell phone may not be able to have the tags to locate their vehicles. Moreover, customers who have run out of power from their phones may also be inconvenienced by the method of finding vehicles. Therefore, the success of the project depends on the availability of a mobile phone and availability of power on the phone.
Critical success factors
The third phase of the project will involve testing of the devices if they are capable of linking up and locating the direction and location of the tags. The phase will, therefore, test for the success of the entire project. The fourth phase will involve replacement of any defaults that might have been realized during testing of the system. However, for the success of the whole project, the procedures must be keenly followed. The procedures for developing the phone application and linking with the radio frequencies should be followed step by step to realize a responsive system. After connecting the tags to the phone application, the next procedure should ensure that the radio frequencies are sensitive even at long distances. The tests should make sure that the obstacles such as other vehicles do not interfere with the radio frequencies. Therefore, the step to step procedures of the entire project is the major key to its success. In addition to that, other critical factors include the skills and experience of the labor provided for the development of the phone application and the RFID tags (Pentilla, 2005). The skills and experience contribute largely to the success of a project since the labor will be able to identify the reliable procedures to undertake the process and how to connect the devices that will be used for the project.
Policy impacts
Different businesses implement various policies that govern their day to day activities. The systems can act as a source of rules and regulations for the organizations that should be adhered by all the stakeholders of the business. However, some changes in business might lead to interference of the policies of the firm. The project will maximize on the plans of parking on the parking lot and also increase the payment of the taxes at the parking lots. It is the policy of the organization to tax on the vehicles that have been parked in their parking lots depending on the time taken by the owners. Using the application and the tags will help in indicating the time adopted by the vehicle in the parking garage and the taxes will be imposed on the owners of the vehicles. The taxes are as a source of income to the organization. Moreover, the parking spaces will also have a maximum attention as the owners of the vehicles will not be able to park their cars away from the parking area within the premises of the organization. Therefore, the policies of parking will be maximized.
Procedure impacts
The project will not interfere with the normal processes of the business as it will only ease the work of the owners of the vehicles other than affecting the activities at the organization. The normal procedures of the firm will be as usual.
Legal impacts
The business should be licensed for the services they offer at a fee on the parking garage. The project will introduce a new source of income to the organization which must be indicated in their trading license as a source of revenue or business they conduct. Moreover, the project will also affect the regulatory measures by the organization on the entry and exit points. The customers will strictly obey the exit and entry routes of the premises to avoid commotions among themselves. The phone application will be indicating the exit and entry points of the building.
Training
The project involves improvised technology that requires a technology expert. Since the device will be new to several customers, the employee of the organization who would act as a guidance should have better knowledge of the tools used (Wood, 2008). The employee has to learn all the basics that are required and have to train on how to use the tools to enable them to use them in the presence of the customers. The training process that is required by the employee is easy and takes at least two days to master all the operatives of the devices to be initiated by the project. Apart from the trainees who will be assisting the customers in comprehending the use of the devices, other employees are required for instructions on how and where to park to avoid wastage of space and congestion at the parking spaces.
Benefits of the project
The project will accrue several benefits to the organization. The mega mall is a huge building with several retail shops and customers who interact on daily basis. The number of vehicles that are used by the customers is relatively high and requires a method of locating their respective locations. The project will, therefore, result in several benefits which are explained below:
1. The project will reduce the risk of theft. The tags help in locating the position of the vehicles. Therefore, in case the vehicle is in motion, the owner is capable of knowing and identifying through the tag placed on the vehicle.
2. Reduced wastage of time by the customers. Customers can easily access the location of their vehicles without much struggle. The traditional method allows the customers to manually search for their cars which might be so much time and tiresome when the vehicles are so many in a place.
3. The project will help in the proper organization of the parking garage as the cars will be arranged in a suitable order ensure easy to search and location.
4. The project will also help in generating some income to the organization. The taxes that will be raised by the customers will be as a source of revenue to the organization.
Possible failures of the project
The project is developed through a RFID tag and a phone application which will access the location of the vehicles that are labelled. However, the devices are not forcefully imposed on the customers as they are conducted on their willingness. Since the project will be a source of taxing the customers, some customers might be able to evade it by not downloading the phone application and not requesting for the RFID tags and instead use the manual means to seek for the location of their vehicles.
Conclusion
In conclusion, the information provided in the above scope summarizes the weaknesses, strengths, resources and objectives of the project of initiating the use of RFID tags on vehicles in a mega-mall parking lot. The illustrations indicate basic concepts of analysing a scope as it explains the time frame, constraints, target customers, functionalities, risks, policy impacts and benefits of the project. The illustrations provide detailed concepts that support the project to be set up and implemented.
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.
XYZ System Documentation
Functional Requirements Document Template
[subtitle]
Author:
Judy McManus
Document
Date
:
04/10/2008
Version
1.1
© 2016
XYZ Company [logo]
Table of Contents
1 Introduction 4
2 Current System Summary 5
3 Functional Requirements 6
4 Use Case 8
List of Figures
Figure 51: Generic Context Diagram
7
Figure 52: Sample Requirements Group 1
7
Introduction
[Provide an overview of the system and some additional information to put the system in context.]
Purpose
[Provide an overall description of the Functional Requirements Document (FRD) and its purpose. Reference the system name and identifying information about the system to be implemented.]
Scope
[Discuss the scope of the document and how it accomplishes its purpose.]
Background
[Describe the organization and its overall responsibilities. Describe who is producing the document and why.]
Project References
[List references and controlling documents, including: meeting summaries, white papers, other deliverables, etc.]
Assumptions and Constraints
[Provide a list of contractual or task level assumptions and/or constraints that are preconditions to preparation of the FRD. Assumptions are future situations beyond the control of the project, whose outcomes influence the success of the project.
Describe any assumptions and constraints that will affect development and operation of the system. Identify any limitations affecting the desired capability, any desired capabilities that will not be provided by the proposed system, as well as any anticipated operational changes that will affect the proposed operation of the system.]
Assumptions
Examples of assumptions include: availability of a technical platform, legal changes and policy decisions.
Constraints
Constraints are boundary conditions on how the system must be designed and constructed. Examples include: legal requirements, technical standards, strategic decisions.
Constraints exist because of real business conditions. For example, a delivery date is a constraint only if there are real business consequences that will happen as a result of not meeting the date. If failing to have the subject application operational by the specified date places the organization in legal default, the date is a constraint.
Preferences are arbitrary. For example, a date chosen arbitrarily is a preference. Preferences, if included in the FRD, should be noted as such.
Document Overview
[Provide a description of the document organization.]
Current System Summary
This section describes (in non-computer-oriented language) the existing system functions to establish a context for the proposed system. If the existing system is a manual process, describe that.
Background
Provide background information concerning the uses and purposes of the current system. Refer to interfacing systems when needed to enhance the general description.
System Objectives and Current Functionality
State the major requirements and goals of the current system. These statements should be concise, quantified if possible, and may include examples. When applicable, related events may be discussed.
Provide an explanation of how the current system interacts with the functional processing supported. Identify products from other systems used with the current system.
Current Methods and Procedures
Briefly describe the current methods and procedures being employed to satisfy the existing information requirements. Provide a graphic representation that depicts the existing data flow through the functional system from data acquisition through its processing and eventual output. The graphic may be complimented by a narrative explanation of the sequence in which the user performs the operational functions. Include in your explanation the information requested in the following subsections.
Equipment Being Used
Discuss equipment being used.
Input and Output
Discuss input and output, including volume and frequency.
Provide a general description of each of the batch and online inputs and outputs. Include information regarding the following:
Reports and queries to be generated by the system
Interface
s to other systems
Online input, including data from presently used manual forms
Provisions in the Existing System Design
Discuss provisions in the existing system design, including operation in degraded modes or at alternate sites in the event of emergency, disaster, or accident.
Deficiencies
Discuss deficiencies, including limitations, such as time delays.
Functional Requirements
Context
[Provide a context diagram of the system, with explanations as applicable. The context of a system refers to the connections and relationships between the system and its environment.]
Figure 51: Generic Context Diagram
Functional Analysis and Allocation
[Decompose the top-level system functional flow block diagram to second-level functions, third-level functions, and etc.]
Functional Requirements
[List the functional requirements of the system.]
Functional Requirements Group 1
[List the functional requirements for each functional requirements group. Here you will be breaking down your Type A functional requirements into Type B hardware and software requirements.]
Section/ Requirement ID
Requirement Definition
FR
1.0
.
The system shall [parent requirement group 1].
FR1.1
The system shall [child/parent requirement].
FR1.1.1
The system shall [child requirement].
FR1.1.2
The system shall [child requirement].
Figure 52: Sample Requirements Group 1
Functional Requirements Group 2, etc.
[same]
Use Case
[Provide a use case diagram of your project and a fully dressed use case here. You should include in the fully dressed use case the following: brief description of use case, name of use case, primary actor(s), assumptions, preconditions, main success scenario (MSS), adverse conditions, extensions/alternative scenarios, functional requirements derived from use case, nonfunctional requirements derived from use case, and post-conditions.]
Glossary
[Define terms, acronyms, and abbreviations used in the FRD.]
malware Malware (for “malicious software”) is any program or file that is harmful to a computer user. Thus, malware includes computer
virus
es,
worm
s,
Trojan horse
s, and also
spyware
, programming that gathers information about a computer user without permission.
Source:
www.whatis.com
Revision History
The Revision History lists all versions of the Functional Requirements Document Template:
Date | Version |
Author/SME |
Description |
04/10/2008 | 1.0 | Judy McManus |
Created from www.jiludwig.com and www.hud.gov. |
1.1 |
Adapted for general use. Note that not all headings may apply; delete as required. |
Data 6
Data 1
Data 3
Data 4
Data 7
Data 2
Data 8
System/
Application
Name
Interface
Name 2
Interface
Name 4
Interface
Name 1
(User)
Interface
Name 3
Data 5