Bugs vs. Feature Requests
CMGT/410 v19
Business Requirements Template
CMGT/410 v19
Page 2 of 15
Business Requirements Document
Mobile Management Inventory Management System
Table of Contents 1. Executive Summary 3 1.1 Project Overview 3 1.2 Purpose and Scope of this Specification 3 1.2.1 purpose 3 1.2.2 Scope 3 1.2.2.1 In Scope 3 1.2.2.2 Out of Scope 4 2. Product/Service Description 4 2.1 Product Context 4 2.2 User Characteristics 4 2.3 Assumptions 4 2.4 Constraints 5 3. Requirements 5 3.1 Functional Requirements 5 3.2 User Interface Requirements 6 3.3 Usability 7 3.4 Performance 7 3.4.1 Capacity 7 3.4.2 Availability 7 3.4.3 Latency 7 3.5 Manageability/Maintainability 7 3.5.1 Monitoring 7 3.5.2 Maintenance 8 3.5.3 Operations 8 3.6 System Interface/Integration 8 3.6.1 Network and Hardware Interfaces 8 3.6.2 Systems Interfaces 8 3.7 Security 9 3.7.1 Protection 9 3.7.2 Authorization and Authentication 9 3.8 Data Management 9 3.9 Portability 9 4. User Scenarios/Use Cases 10 5. Deleted or Deferred Requirements 10 6. Requirements Confirmation/Stakeholder Sign-Off 11 Appendices 11 Appendix A: Definitions, Acronyms, and Abbreviations 11 Appendix B: References 11 Appendix C: Requirements Traceability Matrix 12 Appendix D: Organizing the Requirements 12
1. Executive Summary
1.1 Project Overview
The importance of the information technology is felt in almost all the aspects of human practices and especially for the management services. The mobile inventory management system allows small business owners to manage and track the inventory of their business and avoid problems associated with poor inventory management. This paper describes the development of the mobile inventory management system development requirements.
1.2 Purpose and Scope of this Specification
1.2.1 purpose
The purpose of this paper is to describe the business requirements for the development of the mobile inventory management system. The paper will primarily concentrate on the requirements important for the development from the initiation to deployment phases.
1.2.2 Scope
1.2.2.1 In Scope
The document addresses the project requirement at the development process in the requirement gathering and analysis phase of software development life cycle.
· Assessment of the gathered requirements to find out if they meet the required standards towards the solution of the problem.
· Modification and classification of each other requirement for easy designing and implementation of the mobile inventory functionalities.
1.2.2.2 Out of Scope
The out of scope requirements are those requirements need to be avoid for the project to stay on track.
· The documents will not include how the requirements shall be implemented in the system.
· Also, the requirements which are important for the project development shall not be discussed in this project document.
2. Product/Service Description
2.1 Product Context
The mobile inventory management system allows the business owners to manage their business from any location that they are in provided they have internet connection. The project is similar to other inventory application normally used for the inventory management in most organization, but these products require the user to be a specific location in order to use the system; probably a set- a-side office in the organization.
2.2 User Characteristics
The project document is about the inventory system management system requirements. Basically, the business manager is the primary user of the system which he will use to manage the business from whatever location he is in. This user must have management skills to manager the businesses in the organization. Also, he/she must have basics on the functionalities of the mobile software products.
2.3 Assumptions
The following assumption are observed on the management of the software development.
· The requirements are adequate for solving the problem the business requirement
· The requirements are enough for the development of the product that can work in all platforms on mobile devices.
· The resources for the designing and implementation of the project are adequate.
2.4 Constraints
The constraints are the possible issues that might hamper the development and implementation of the project (Liang, 2013). The following are constraints that affect the designing and implementation of the project.
· The availability of adequate resources and expertise for the development.
· Time frame for the designing, development, implementation, and deployment.
· The designing standards
· Access, management, and security
· Criticality of the application
· System resource constraints
3. Requirements
The system requirements allow the developers to determine the ultimate goals of the project and determine way through which the system will be designed, implemented, and deployed. The developers need to study all the requirement, functional, non-functional, and user interface requirements (O'Shaughnessy, 2019).
3.1 Functional Requirements
3.2 User Interface Requirements
The system will interact with users through it interface; therefore, the system should be friendly to use. It will take inputs through the use of a scanner, keyboard, and the files stored in the memory. It will also generate the printable output, display them on the screens, and other peripheral. The system shall communicate with the database through the use of the SQLite database and JDBC connector to interact and communicate with the database (Liang, 2013).
3.3 Usability
Learnability
· The user documentation and help should be complete.
· The help should be context sensitive and explain how to achieve common tasks.
· The system should be easy to learn.
3.4 Performance
The organizations inventory shall be used on the desktop and on the mobile platform. Therefore, the users based on the organization’s premises shall interact with the system where about 90% of the transaction shall be processed in one second. But, the mobile terminal where the system will be hosted will only allow one traction at a time after the authentication to minimize security issues from occurring.
3.4.1 Capacity
The system will only have one user, i.e. the inventory manager of the organization who will assess how the inventory is managed in the organization.
3.4.2 Availability
The system will operate on 12 hours a day when it is available. The system will not be available on other hours when the business premises are not operational. During these working hours, the system shall experience a downtime of less than 5 minutes.
3.4.3 Latency
The system will not experience latency that is more than 2 minutes upon the request of the service.
3.5 Manageability/Maintainability
3.5.1 Monitoring
The system will be able to monitor every action happening in the system and its resources. First, the system shall monitor error in the system such as the system failures; logging; which include the time of tried logging, device, and location; correction of the system errors through the use of artificial intelligence to determine what the user wants; and monitoring health of the system resources.
3.5.2 Maintenance
The system shall be monitored and track for the necessary improvement, correction of errors and possible. This will make the system more reliable, effective, and secure.
3.5.3 Operations
The system shall allow that conduction of other user operations. The following are operations that that system will conduct.
· Data processing support functions
· Backup and recovery operations
· Safety considerations and requirements
· Disaster recovery and business resumption
3.6 System Interface/Integration
The system shall interact through other resources to perform effectively. These resources include software and hardware.
3.6.1 Network and Hardware Interfaces
The system holding the resources communicate with each through the use of interfaces. Network, wired and wireless connection, are mainly used to connect all the resources together. The system shall be hosted on the mobile device; therefore, a wireless connection, internet, will be mainly used to connect the system to server where the inventory data are stored in the organization.
3.6.2 Systems Interfaces
The system will interact with organization through the internet connection. This connection allows the use to retrieve the desired data from the organization server regarding the inventory management. Therefore, the system is design according to the database of the organization. The database SQL quarries are used to access the target data.
3.7 Security
3.7.1 Protection
The information and data security is priority to the organization and should be implemented effectively. There various methods that will be used to implement the security strategies. Since the system will be hosted in mobile device then the active logging, data integrity checks and data encryption shall be used to implement the security strategies.
3.7.2 Authorization and Authentication
The authorization and authentication shall be used to determine who access the system resources. Both of strategies shall be achieved through the different methods. Authorization: the strategy though the implementation of Login form, HTTP authentication, and custom authentication method. Authentication: this different method to access the permission access resources and the methods such the use of access controls for URLS, secure objects methods, and access control list.
3.8 Data Management
The organization use the strategies to manage the data stored in the organization database. Properly managed data minimizes the errors experienced with regard to the data operations processes. A database management system shall be used and accessed through internet connection. Therefore, the data access, integrity constraint, data format, and data entities and relationship functions shall be used.
3.9 Portability
The system shall be used only by authorized person responsible for the management of the organizations’ inventory. Therefore, it will only be hosted on one system and the specification of that system for the kept for authentication so that no other system shall access the resources. Also, the devices that host the system are those only owned by the organization (Bae, 2016). If portability is a requirement, specify attributes of the system that relate to the ease of porting the system to other host machines and/or operating systems.
4. User Scenarios/Use Cases
The product shall be used through a mobile device. The following table describe the use cases of the system.
|
Use case name |
Update resource in the database |
|
actors |
Initiated by the business manager |
|
Flow of events |
1. The user, manager activates update resources database function. 2. The system presents a list of transaction done on the day. 3. The manger approves or disapprove the transactions. 4. The system saves the transaction for the responsible persons to access and use. 5. Correction are done for approval.
|
|
Exit condition |
A notification of process completion for acknowledgement. |
5. Deleted or Deferred Requirements
6. Requirements Confirmation/Stakeholder Sign-Off
Appendices
Appendix A: Definitions, Acronyms, and Abbreviations
Define all terms, acronyms, and abbreviations used in this document.
MIMS – mobile inventory management system
HTTP – Hypertext Transfer Protocol
URLS - Uniform Resource Locators
Appendix B: References
Bae, S. M., Han, K. H., Cha, C. N., & Lee, H. Y. (2016). Development of Inventory Checking System Based on UAV and RFID in Open Storage Yard. 2016 International Conference on Information Science and Security (ICISS).
Liang, C. (2013). Smart Inventory Management System of Food-Processing-and- Distribution Industry. Procedia Computer Science, 17, 373-378.
O'Shaughnessy, K. (2019). Inventory Management Software Features & Requirements Checklist. Retrieved from https://selecthub.com/inventory-management/inventory-management-software-top-features-requirements/
Sairam, N., Nagarajan, S., & Ornitz, S. (2016). Development of Mobile Mapping System for 3D Road Asset Inventory. Sensors, 16(3), 367.
Appendix C: Requirements Traceability Matrix
|
MI_FR_01 |
|
X |
|
X |
|
|
|
X |
X |
|
|
|
X |
|
MI_FR_04 |
X |
|
|
X |
|
|
|
|
X |
|
X |
|
X |
|
MI_FR_07 |
X |
|
|
X |
|
X |
|
|
X |
|
X |
|
|
|
MI_FR_08 |
|
X |
|
|
|
|
|
|
X |
|
|
X |
|
Appendix D: Organizing the Requirements
This section is for information only as an aid in preparing the Requirements section of the document.
Detailed requirements tend to be extensive. Give careful consideration to your organizations scheme. Some examples of organization schemes are described below:
By System Mode
Some systems behave quite differently depending on the mode of operation. For example, a control system may have different sets of functions depending on its mode: training, normal, or emergency.
By User Class
Some systems provide different sets of functions to different classes of users. For example, an elevator control system presents different capabilities to passengers, maintenance workers, and fire fighters.
By Objects
Objects are real-world entities that have a counterpart within the system. For example, in a patient monitoring system, objects include patients, sensors, nurses, rooms, physicians, medicines, etc. Associated with each object is a set of attributes (of that object) and functions (performed by that object). These functions are also called services, methods, or processes. Note that sets of objects may share attributes and services. These are grouped together as classes.
By Feature
A feature is an externally desired service by the system that may require a sequence of inputs to affect the desired result. For example, in a telephone system, features include local call, call forwarding, and conference call. Each feature is generally described in a sequence of stimulus-response pairs, and may include validity checks on inputs, exact sequencing of operations, responses to abnormal situations, including error handling and recovery, effects of parameters, and relationships of inputs to outputs, including input/output sequences and formulas for input to output.
By Stimulus
Some systems can be best organized by describing their functions in terms of stimuli. For example, the functions of an automatic aircraft landing system may be organized into sections for loss of power, wind shear, sudden change in roll, vertical velocity excessive, etc.
By Response
Some systems can be best organized by describing all the functions in support of the generation of a response. For example, the functions of a personnel system may be organized into sections corresponding to all functions associated with generating paychecks, all functions associated with generating a current list of employees, etc.
By Functional Hierarchy
When none of the above organizational schemes prove helpful, the overall functionality can be organized into a hierarchy of functions organized by common inputs, common outputs, or common internal data access. Data flow diagrams and data dictionaries can be used to show the relationships between and among the functions and data.
Additional Comments
Whenever a new Requirements Specification is contemplated, more than one of the organizational techniques given above may be appropriate. In such cases, organize the specific requirements for multiple hierarchies tailored to the specific needs of the system under specification.
There are many notations, methods, and automated support tools available to aid in the documentation of requirements. For the most part, their usefulness is a function of organization. For example, when organizing by mode, finite state machines or state charts may prove helpful; when organizing by object, object-oriented analysis may prove helpful; when organizing by feature, stimulus-response sequences may prove helpful; and when organizing by functional hierarchy, data flow diagrams and data dictionaries may prove helpful.
Copyright© 2018 by University of Phoenix. All rights reserved.
Copyright© 2018 by University of Phoenix. All rights reserved.