Functional And Non-Functional Requirements Of Laptop And Web Rental Check-out System

1) Determine the functional and non-functional requirements of your proposed system.

2) Justify the system development approach (Adaptive or Predictive) 

Laptop Rental Check-out System

The report focuses on evaluating the modeling and development of laptop rental check-out system (CRCS) and web rental check-out system (WRCS). CRCS and WRCS are systems that allow a company to store details on laptop rentals. CRCS is staff-oriented whole WRCS is customer-oriented. In CRCS, the staff is involved in recording, updating, and managing detail associated with laptop rentals. On the other hand, customers will be heavily involved in the checkout process in WRCS, and the role of the staff is reduced in this system.

The aims of this project are:

• To define functional and non-functional requirements of WRCS and CRCS
• To create work breakdown structure for the two systems
• To identify and explain the development model that can be applied
• To discuss the assumptions made on modeling system user sections

The report is divided into several sections providing varying content related to the two systems. The content covered in this report includes: system functional and non-functional requirements, work breakdown structure, use case diagram, system sequence diagram, assumptions, system development approach, recommendations, and conclusions. A reference section is included to provide a list of references used in this report. Some content in the report such as Microsoft project and system diagrams will be imported from other programs. 

Laptop Rental Check out System

Functional requirements

System provides data entry features including data validation tools

System produces error or success messages to show the status of a process

System has an access control and authentication feature that authorize users who can use the system

System analyzes data entered to produce reports

System provides an access log for monitoring user activities

Non-functional requirements

The non-functional requirements for CRCS include:

• A clear and detailed documentation on system use
• System compliant with industry security standards such as PCI-DSS
• System should have security and defense mechanisms to safeguard data from various security threats such as malware, intrusion, and unauthorized access
• System should have fast response time to reduce data entry time
• System should have the capacity of handling simultaneous operations
• System should have recovery mechanisms to support disaster recovery in cases of unexpected events
• System should have an intuitive interface that is easy to understand and use
• System should run in different windows platform including older versions of Windows such as Windows Vista

Functional requirements

System validates data entered by users and produces errors to indicate data issues

Users have to log in with the correct details to access their accounts and enter data

System has admin portal and customer portal

Admin portal manages user accounts

System connected to CRCS database to allow data management

System produces product reports to show sales and conditions of the laptops

The system meets applicable regulatory requirements

The non-functional requirements for WCRS include:

• The system has to be accessible via various devices including tablets, smartphones, and laptops.
• System should support many users and simultaneous operations
• System should comply with responsive web design standards
• System should have a detailed documentation providing information on various system modules
• System should be extensible to support integration of additional modules
• System should be fault tolerant to user input
• The system should incorporate robust security features that minimize the threat of Denial of Service attacks, intrusion, and malware.
• System should have a stable framework that is not vulnerable to issues associated with updates
• Website pages should load fast to maintain efficiency 

Various assumptions are made in the project and attempts will be made to verify them during the software development lifecycle. The following assumptions were made in modeling the requirements of CRCS and WRCS:

• Users will know the meaning of icons used in the software hence tooltips for the icons will not be included in the user interface.
• Users are willing to change business operations to leverage the functionality offered by CRCS and WRCS
• Management will ensure that users are available as needed complete the training program and learn how to use the two systems
• The management and staff members will participate in execution of project plan including attending meeting as required and approving changes
• Failure to identify and integrate changes in the project scope within the time specified in the project schedule will cause project delays and affect the project timeline
• Staff members will play a proactive role in testing and reviewing the modules of CRCS and WCRS at the testing page and after completion before deployment
• Project team members will adhere to the code of conduct policy
• Project team members will be actively engaged throughout the project and adhere to the communication plan established
• Project sponsor will support the project goals and objectives as well as approve changes recommended by project team members
• The management will ensure existence of a testing environment that can facilitate testing of CRCS and WCRS before deployment
• Project sponsor has a technological infrastructure that can support deployment of CRCS and WCRS
• Project stakeholders will abide by the guidelines developed by the project manager
• Change management process will incorporate all project stakeholders, and the opinions of all participants will be considered before a decision on change can be made
• The project schedule may change as new requirements and issues are identified and incorporated into the project schedule.
• Project scope is well-defined but will accommodate changes that may arise during project execution
• Project team will be held accountable for the value delivered within the project schedule given
• All resources will be allocated to the project tasks identified. Over-allocated tasks will provide resources needed by tasks that have insufficient resources
• Project team members will work together to ensure that each project phase is completed before the next phase is started
• The project will have no dependencies, and all the project aspects are under the project team control
• Project sponsor and managers are capable of defining the requirements for the project. They will be available throughout the project and are willing to engage in dialog with the project team members to express their needs and opinions to ensure the project scope meets their expectations
• A sufficient project description with detailed functional and non-functional requirements have been developed
• The project team has identified the in-scope deliverables of the project and the out-of-scope deliverables and have defined the boundaries of the scope
• Integration of changes in the project requirements and scope will not be a problem, and the changes will be specifically addressed to ensure they are incorporated into the project schedule
• The project team members have developed a detailed work breakdown structure for the two systems indicating the durations for each project task
• A scope of work based on the work breakdown structure has been developed and suitable time and cost estimates have been made
• The project manager will determine and establish the level of project management that suits the size, complexity, and risk level of the project
• The quality of CRCS and WRCS has been established
• Steps have been implemented to ensure a quality process is maintained throughout the project
• The resources required for the project including materials and equipment will be delivered on schedule
• Staff members will be available when their input is required in the project
• Project deliverables will be reviewed and approved within the specified time in the project schedule
• There is sufficient information to accurately estimate the costs of the project for each project phase
• Various risks associated with project constraints have been identified and addressed
• The project team members are competent and have the expertise required to complete the project tasks and produce quality outcomes

Data flow model (DFM) is used as the main system model for the CRCS and WRCS. The data flow model shows the key subsystems in the main system (Sbirlea, 2012). The DFM for CRCS shows check in, checkout, laptop purchase, and reports as the main subsystems of the system. The DFM of WRCS shows login module and customer portal as the subsystems of the system. The data flow models of the two systems show the data flow between the users and how they interact with the subsystems (Jones, 2008). The models show the data inputs to the system and play an instrumental in representing the behavior of the two systems.

In CRSC, the data flow model indicates that the activities performed or are associated with employee include laptop checkout, receiving/returning laptop, check-out receipt, laptop check-in, check-in receipt, and statement. Data input/activities involving IT staff include recording checkout, laptop handling, check-out receipt, recording check-in, and laptop purchase. The activities that involve the supervisor laptop purchase, receiving packing slip, and report. The data flow model provides a perceptive way of illustrating how data in the CRCS is processed in the accessible system (Janneck, 2008).

Functional Requirements

The data flow model for WRCS shows the employee as the main user of the system. Employee interacts with the system to complete a transaction related to the checkout process. As the user, the employee submits login details which are processed to determine whether they are valid before authenticating the employees. Once logged in, the employee submits laptop details which are used to query the database. The employee selects the laptop and submits return date which is stored in the database. Data flow models show the data in WRCS is processed by the system (Bhattacharya, 2012). At the analysis level, the DFM models the way in which users interacts with subsystem and the flow of the data (Harvan, 2009). As an intrinsic structural method, DFM represents the functional processing of the data in CRCS, data storage, movement of data between systems and the functions performed by the system (Andienko, 2007).

Dataflow models for CRCS and WRCS show the data flows via a set of steps involved in processing the data (Janssen, 2011). For example, recording checkout is a processing step used to create records in the database. Data is changed in each step before it reaches the database or users. These processing steps represent the software functions that can be used to document the design for CRCS and WRCS. Dataflow models are essential in documenting how data associated with various processes in the systems moves between the subsystems (Zhou, 2008).

Agile development methodology is the appropriate development approach for CRCS and WRCS. The methodology focuses on utilizing a creative process that anticipates flexibility in system development and applies a level of realism in delivering a quality finished product (Dingsøyr, 2012). It places emphasis on regular tests, delivering functional prototypes of the system, and simplifying the code. The goal of the approach is to build on approved system parts as the project progresses instead of delivering one application at the end of the schedule (Dyba, 2009). The agile method eliminates the challenges and limitation of other development approaches. It has become an industry development standard that is used by many software developers (Shore, 2007).  This method is effective for development of CRCS and WRCS as it provides a light framework for assisting the project team to focus on rapid delivery which is instrumental in reducing overall risks associated with the project (Begel, 2007).

The agile method ensures the project team members focus on optimizing the value during the project (Cao, 2009). Use of iterative planning and feedback implies that the team members will be in contact with managers and will continuously improve the systems to align the delivered product with the needs of stakeholders (West, 2010). With this methodology, the members can adapt to changes made during the project by evaluating project status (Vijayasarathy, 2008). This evaluation allows visibility of each project phase.

Stakeholders in development of CRCS and WRCS will leverage Scrum method to improve team coordination as well as individual work. In this development method, the team members will work together to create a project plan and break to focus on performing their tasks (Larman, 2008). Although the team members will work cohesively, each team members will execute his own tasks. In cases issues such as project delays are noted, the team members will come back together to discuss what actions should be taken and the changes that should be made.

Non-functional Requirements

The project team will maintain constant communication at each phase of the project. With agile, the members will collaborate and remain self-organized, in that there is no project manager as the members work together to decide on how to handle various issues encountered (Abrahamsson, 2009). The client will be actively engaged in the project and will offer guidance to the project team. Check-ins which are part of the scrum process are essential in showing the project progress to the project owner and keep the project team members updated (Ferreira, 2007).

It is critical for the project team to adopt an architectural runway to manage the complexity that may arise in the project. Critical project requirements increase project risk and complexity. Complexity emerges when activities takes longer than a single project iteration and cannot be broken down or allocated to different team members to develop part of the solution. It is essential for the team to adopt approaches to managing the complexity. Some of the approaches include pre-defined software architecture features.

The agile model for predefining architectural features that can be adopted by the project team is architectural runway. Architectural Runway aims at providing a high level of stability to support iterations in system development (Burchmann, 2012).  Stability is essential to facilitate the successful collaboration of the team. The team has to determine quality attribute requirements that are significant to CRCS and WRCS. These requirements are critical to development of architectural features. This allows system development team to iteratively develop user-desired system features that are based on the runway and are enhanced by quality attributes (Schintter, 2014).

With a well-define architectural runway, the project team can easily determine technical risks early in the project hence assist in managing technical complexity and eliminate risks in the integration phase (Leffingwell, 2008). The team can determine quality attribute concerns such as performance, security, or availability which can influence rework and schedule delay. Delivering the functionality of CRCS and WRCS can be more predictable since the team members have infrastructure that allows the team to focus on the requirements that architecturally segment to the project.

Conclusion

As discussed, requirements of CRCS and WRCS are modeled using data flow models to illustrate the data flow between the subsystems. The two systems have a set of requirements which are visible in the data flow model. Data flow model not only depicts the subsystems but also functions that process the data. These processing functions transform data before it moves to the next phase. Typically, the data will move between the database and the interface. A user may request data from the database which is processed by various functions before it is rendered on the interface.

Agile methodology is considered to be the best development methodology for CRCS and WRCS. The methodology is appropriate for the project as it improves user engagement which ensures the end product meets the client needs. In the agile method, the client plays a proactive role in interacting with the project team as well as evaluating and approving system prototypes presented. With the agile method, the team can effectively incorporate changes without affecting the project schedule or increasing costs. It is recommendable for the project team to incorporate architectural runway in the project to enhance its focus on key requirements that define the quality of the system. 

References

Abrahamsson, P., Conboy, K., & Wang, X. (2009). 'Lots done, more to do': the current state of agile systems development research. European Journal of Information Systems, 18(4), 281.

Andrienko, G., Andrienko, N., & Wrobel, S. (2007). Visual analytics tools for analysis of movement data. ACM SIGKDD Explorations Newsletter, 9(2), 38-46.

Begel, A., & Nagappan, N. (2007, September). Usage and perceptions of agile software development in an industrial context: An exploratory study. In Empirical Software Engineering and Measurement, 2007. ESEM 2007. First International Symposium on (pp. 255-264). IEEE.

Bhattacharyya, S. S., Murthy, P. K., & Lee, E. A. (2012). Software synthesis from dataflow graphs (Vol. 360). Springer Science & Business Media.

Buchmann, F., Nord, R. L., & Ozakaya, I. (2012). Architectural Tactics to support rapid and agile stability. Carnegie-Mellon Univ Pittsburgh PA Software Engineering Inst.

Cao, L., Mohan, K., Xu, P., & Ramesh, B. (2009). A framework for adapting agile development methodologies. European Journal of Information Systems, 18(4), 332-343.

Dingsøyr, T., Nerur, S., Balijepally, V., & Moe, N. B. (2012). A decade of agile methodologies: Towards explaining agile software development.

Dyba, T., & Dingsoyr, T. (2009). What do we know about agile software development?. IEEE software, 26(5), 6-9.

Ferreira, J., Noble, J., & Biddle, R. (2007, August). Agile development iterations and UI design. In Agile Conference (AGILE), 2007 (pp. 50-58). IEEE.

Harvan, M., & Pretschner, A. (2009, October). State-based usage control enforcement with data flow tracking using system call interposition. In Network and System Security, 2009. NSS'09. Third International Conference on (pp. 373-380). IEEE.

Janneck, J. W., Miller, I. D., Parlour, D. B., Roquier, G., Wipliez, M., & Raulet, M. (2008, October). Synthesizing hardware from dataflow programs: An MPEG-4 simple profile decoder case study. In Signal Processing Systems, 2008. SiPS 2008. IEEE Workshop on (pp. 287-292). IEEE.

Janssen, P., & Chen, K. W. (2011). Visual Dataflow Modelling. In Proceedings of CAAD Futures (pp. 801-816).

Larman, C. (2008). Scaling lean & agile development: thinking and organizational tools for large-scale Scrum. Pearson Education India.

Leffingwell, D., Martens, R., & Zamora, M. (2008). Principles of Agile Architecture. Leffingwell, LLC. & Rally Software Development Corp.

N.L. Jones, & G. Strassberg. (2008). The Arc Hydro MODFLOW Data Model. Water Resources IMPACT, 10(1), 17-19. Retrieved from https://www.jstor.org/stable/wateresoimpa.10.1.0017

Sbîrlea, A., Zou, Y., Budimlíc, Z., Cong, J., & Sarkar, V. (2012, June). Mapping a data-flow programming model onto heterogeneous platforms. In ACM SIGPLAN Notices (Vol. 47, No. 5, pp. 61-70). ACM.

Shore, J. (2007). The art of agile development. " O'Reilly Media, Inc.".

Schnitter, J., & Geppert, J. (2014). Agile Software Development: What is Left to Do?. In Future Business Software (pp. 93-104). Springer International Publishing.

Vijayasarathy, L. E. O. R., & Turk, D. (2008). Agile software development: A survey of early adopters. Journal of Information Technology Management, 19(2), 1-8.

West, D., Grant, T., Gerush, M., & D’silva, D. (2010). Agile development: Mainstream adoption has changed agility. Forrester Research, 2(1), 41.

Zhou, B., Arabo, A., Drew, O., Llewellyn-Jones, D., Merabti, M., Shi, Q., ... & Yau, A. (2008, June). Data flow security analysis for system-of-systems in a public security incident. In The 3rd Conference on Advances in Computer Security and Forensics (ACSF 2008).