Bugs vs. Feature Requests

profilemackey66
Wk2pt1.docx

CMGT/410 v19

Business Requirements Template

CMGT/410 v19

Page 2 of 15

C:\Users\djshirey\OneDrive - University of Phoenix\F_Drive\Style Guides\UPX Logos\Horizontal format\UOPX_Sig_Hor_Black_Medium.pngBusiness 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

Req #

Requirement

Comments

Priority

Date Received

SME Reviewed/Approved

MI_FR_05

The system stores employee’s details working in the organization

Business Process = “maintenance”

1

6/13/19

Donald Kelly/ Bob Roberts

MI_FR_06

The system allows admin to hold the users detail, authenticate them and provide varying options.

Business Process = “maintenance”

2

6/13/19

Donald Kelly/ John wells

MI_FR_07

Holds the organization’s store details.

Business Process = “maintenance”

2

7/13/16

Donald Kelly/ Bob Roberts

MI_FR_10

Hold the products’ stock in the organizations go down

Business process = “changes depending on the available stock”

3

6/11/19

Donald Kelly/ Bob Roberts

MI_FR_11

Manages the business entries in the organization.

Business Process = “The entries change depending on the amount of entries the organizations make”

1

6/11/19

Donald Kelly/ Bob Roberts

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

Req #

Business Requirement

Status

Comments

PRI

Date Reviewed

SME Reviewed/Approved

MI_FR_03

The system should keep track of the inventories

April 2019

The requirements were deleted since it was not necessary.

Business Process = “The requirements”

1

7/13/019

Donald Kelly/ John wells

MI_FR_03

The system should describe connect with the suppliers

Differed to future consideration during maintenance phase

Business Process = “Handling issues and connecting with suppliers”

3

3/13/19

Donald Kelly/ John wells

6. Requirements Confirmation/Stakeholder Sign-Off

Meeting Date

Attendees (Name and Role)

Comments

7/13/17

Donald Kelly, project manager

Bob Roberts, technical manager

Michael Kennedy, team manger

Harry Kane, Technical Analyst

Ali Hasan, Technical Analyst

Confirmed MI_FR_03 - MI_FR_04

08/15/17

Bob Dylan, Labor Relations SME

Mick Jagger, Labor Relations SME

Ringo Starr, Technical Project Manager

Deferred / Deleted: MI_FR_04, MI_FR_05, MI_FR_06, MI_FR_07, MI_FR_03

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 Science17, 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. Sensors16(3), 367.

Appendix C: Requirements Traceability Matrix

BizReqID

CD01

CD02

CD03

CD04

UI01

UI02

UCT01

UCT02

UCT03

TC01

TC02

TC03

TC04

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.