Table of Contents
1. Non-Functional Requirements
As we know about the Nonfunctional Requirements (NFRs) characterize attributes of the systems, for example, security, usability, performance, reliability, maintainability & scalability. Over the various backlogs of scenarios, they filled in it as the confinements or imperatives on the system design. It’s also known as qualities of the system. NFR is as critical to the system as the business functionalities its features & capabilities. NFR guarantees the convenience & viability of the system. If any of such requirements get missed it result in design that is unable to meet the stakeholders & market needs & will unable to satisfy the compulsory requirements that is implemented by standard or any regulatory organizations.
NFRs are persevering characteristics & imperatives when compared to the functional requirements & can be usually returned to significant aspect of Definition of Done (DoD) for any release of the software, iteration & program Increment (PI). The NFRs do exists in all of the accumulations: Team, program, solution, & portfolio. Whereas the appropriate definition & execution of NFR is the most critical task (Umar & Khan, 2011). Over-specifying them & the solution might be unreasonable to be viable for under-indication or underachievement of them, & the system will be deficient for its expected utilization. An adaptive & incremental way to deal with analyzing, characterizing, & actualizing NFRs is a fundamental expertise for teams of Agile.
One approach to consider each requirement that influence the solution overall condition is the 'FURPS' classification that is Functionality, Usability, Reliability, Performance, & Supportability. In contrast, functional requirements are to a great extent communicated in client stories & highlights &capacities. This is the place a large portion of the work happens. System which are built by teams that convey an incentive to the client, &more often & exertion in the development of a solution is given to that. FURPS is a placeholder for the nonfunctional requirements (NFR, 2016)
All of the major five requirements are organizes inside the FURPS Model that are
F indicates Functional, U indicates Usability, R indicates Reliability, P indicates Performance, S indicates Supportability
Whereas few more categories are added in the model of FURPS+
It includes the assuming level of expertise by the users.
The standards of the user interface are used in it.
How much user friendly your system is?
How much productive the system is?
It includes all of the requirements that lies in the security & safety of the system,
The robustness & reliability of the system.
The exception handling capability of the system.
The tolerance of data failure.
It includes about the load system can be able to support
what kind of response time system gives?
The number of transactions per second supported by the system.
How will system respond in stress condition?
It's an essential NFR of the system, how much secure the system is?
Is your data being safe in the system?
System privacy must be considered while developing it
The data must be stored via encryption in the system for security purpose.
Supportability How to maintain & extend the system is included in this.
Implementation What the platform is?
Interfaces What protocols used & what are the interfaces to existing systems
Operation by whom the running system is operated?
Packaging by whom the system has been installed?
Legal All of the licensing * liability issues will be included in it whereas what kind of Licensing fees or liabilities incurred from using third-party components or algorithms?
Even though they might be somewhat subtler, NFRs are similarly as vital to system achievement. NFRs on the new development can be considered as the constraints, in that each takes out some level of outline opportunity for those building the system. For instance, SAML-based Single Sign-on (SSO) is a necessity for all items in the suite. (SSO is an FR, while SAML is a constraint.) NFRs can cover an extensive variety of business-basic issues that are regularly & ineffectively tended to by FR (NFR, 2018)
As a suggestion to the designer of the systems, an extensive list of such potential NFRs is portrayed in a figure below.
Figure 1: NFR of an extensive system
NFR in Headspace Project:
The project of headspace includes the critical data of the patients so the NFR by any means must be designed & implemented in such a way that it will allow the system to face any such situation that is created in the absence of the NFR. The system must be designed by undermining the usability so each of the users can use it easily, the approach must be performance-oriented & must be able to face a load of users as well as must respond positively while robustness. All of such including the security of the system will be making sure when the NFR will be carefully observed while the development of the system. So NFR must be set on the top priority while testing the Headspace system so their presence will be undermining.
2. Cloud Based Solution:
It has been noticed these days in the modern era that the availability of the wireless connection of the internet is a big blessing for accessing any information on any device where ever you are. With the help of cloud computing, the data is hosted by the internet & can be accessed by any user especially by the medical staff they can access it when & where ever they need it. Using the cloud to implement the health services will improve the quality of service offered to the patients like the government is taking the initiative of the project headspace. The technologies that are involved in this process are the patient's data in electronic format.
Moreover, by combining the cloud computing with the electronic health record but let has introduced the cloud computing concept it's basically like a third company provides the storage of data in its servers so it can be accessed via the internet (Fernández and Torre, 2012). Moreover, this method is also suitable for the emergency medical system in the deployment of Headspace project to improve the coordination between the various healthcare & emergency processes. Some of the examples of a cloud-based solution on the health care services or Headspace project will be discussed below to understand the cloud-based EHR system & the headspace project.
Figure 2: A cloud based solution system architecture diagram.
2.1 Advantages or Benefits:
A lot of benefits come after the adoption of the cloud-based solution. It's effortless to use & also simple to implement & design flexible whereas the most important to back up the data it is most reliable. Implementation of the cloud-based solution doesn't require any specific hardware or software. It can be done without affecting the business routine as in terms of no downtime. It does save the cost as its simple to implement as well. Each of the user using the system have the accessibility that is expanded. If you have a device which holds the internet you can access the system from it. It has been noticed that many cloud-based solution system providers are making their own an application to the ease of access to the data. It has made possible to access it wherever you are especially for holding the medical records that are of most use. If they provide the ease of access they also provide flexibility. Adding a new user in the cloud-based solutions systems is as easy as making a new profile & can be done from anybody with a little technical knowledge.
There isn't any need to install something new or to buy any sort of hardware, a simple registration form is to be filled by the new user on the specific application & you are ready to use your cloud-based system. When we talk about the scalability cloud-based solutions also fulfill the words, storing any data on the cloud will be allowed you to be limitless. When we speak about the headspace project millions of the patient's data can be easily stored on the cloud-based solution system & it also provides its greatest feature which is you also have a built-in backup of your data. The service provider companies will always create a backup of data they hold, so it's simple to restore the lost data. The security is provided in the form of encryption or decryption techniques by the service providers (Fernández and Torre, 2012).
2.2 Disadvantages & Risks:
Where there are Pros there's always be cons with the storage of data cloud-based some of the concerns came up one of the major ones is what about if the internet is down? As no one guarantees with the full-time access of internet, there's always a risk of dis connectivity of the internet that may hold you back from your data what happened if this scenario is faced during an emergency for a patient record accessing from the headspace project. Moreover, in an exceptional case, there are still some cloud-based systems available that offer the running of the system while offline.
As a system is dependent on the supplier here comes a risk what if the service provider of cloud-based solutions system happens to go under? Or what if you want to switch the service provider by yourself? In the case of headspace project, millions of user data are impossible to transfer so here comes the big risk, it will be a high cost with this change both the implicitly & explicitly. This can be avoided with the help of research but one must be aware of such situations while uploading their sensitive data. As there’s always a security risk that comes up one must find out the security level of different service providers to being comfortable to share your data with the particular company. Whereas it has been noticed that many service provider always offers a high-security level & to help mitigate the concerns of customers (Cloud Risk & Benefits, 2018).
2.3 Security & Privacy:
With the revolution of cloud computing-based solution by providing the organizations with the easy resources of deployment, configuration etc. There comes a considerable privacy & security issues which should be taken into consideration otherwise it will result in a significant loss for the company. The critical challenges in cloud-based solutions are the loss of control, multi-tenancy & most crucial trust. One organization must consider the continuous reviewing of the existing deployment in the approaches of privacy-preserving sensitive data such as the threat modeling & enhancing protocols & solutions of the privacy.
At last, while suggesting for the headspace project I will recommend to not to be dependent on any other service provider for the cloud-based solutions system instead of building up a new setup by installing own servers & store the data in it, that will be more reliable secure than any other provider.
It has been kept in mind while the deployment of the cloud-based solution that to deploy the proper solution for each health record of the patient then each of the deep study record data is needed to transfer to the cloud. It will help the different organizations to access the patient's history or data from anywhere so it will also help to save the cost. Whereas one more fact must be taken into account & that is the cloud service provider confidence. The headspace project must need to look forward to the proper cloud service provider which used to offer them the security in terms of their data privacy & assure the secureness of the data to adopt the technology of cloud-based solution.
3. SDLC (Software Development Lifecycle):
The process of SDLC (Software Development Lifecycle) is trailed by the software industry to design, develop & testing the quality of software. The way to deal by software design, development, & testing went for delivering top-notch software that is inside a cost budget & additionally assessed time by following the SDLC approach. SDLC characterizes the project's phases performed at every step of the development lifecycle, from initial phase till the implementation phase. Two approaches or methodologies of SDLC are present that are; predictive & adaptive.
Adaptive SDLC usually considered for most of the part when the current software includes unspecified results. The philosophy of adaptive approach contains dividing the software project into various parts for a specific time for undermining the adaptability in handling the nature of the task. Predictive SDLC sets out a straight, particular software development plan that is organized around some results that are pre-characterized results within a specific time. The waterfall methodology for software development falls in the predictive SDLC (SDLC, 2015)
Figure 3: SDLC Approaches: Predictive VS Adaptive.
3.1 Adaptive SDLC’s Pros:
The adaptive software before the project's kickoff provides an open door development for broad stakeholder, amid & after all the phases of the projects life. Throughout development, the methodology needs a complete interaction of the customer with the team of development since it includes broad cooperation during each phase of lifecycle between the team & the customer. Such interactions allowed the clients to comprehend each phase of project which allows the customer to share about their perspective when needs emerge & to include the requirements as well. Such cooperation’s help the team of development to comprehend vision of customer's (Beyer, 2010). This customer interaction in the task side by side builds up the customers trust in the team of development which empowers the customer’s efforts & their involvement in lifecycle of the project.
3.2 Adaptive SDLC’s Cons:
The broad customer involvement is requested by the adaptive SDLC which takes a good time of the customer & they need to perform a full duty of observation during the projects lifecycle. Whereas customers are mostly engaged only during the testing & reviews phases & disengaged amid any other work like development phase which results in some error & wastage of customer’s time.
Huge evolution & emergence of requirements are included in adaptive SDLC during projects life cycle (Holcombe, 2008). In such way the new requirements results in more time than the scheduled one so the project completion goes more than expected than that of imagined in initial phases of life cycle.
3.3 Predictive SDLC’s Pros:
Predictive SDLC is straightforward & easy to follow. Whereas this methodology has determined stages that are followed from throughout the SDLC from initial to deployment phase. The set down advances & the arrangement of how the go before one another makes it simpler for designers to think of software quality inside a predetermined time allotment & a predefined budget (Srivyshnavi, 2013). The expectations of one phase are utilized as the crude materials for the following phase & henceforth this makes it less demanding for designers to the line & thinks of software quality toward the end.
The predictive SDLC have unmistakably characterized phases which are handled each one in turn. A methodology of productiveness offers the designers an inflexible improvement lifecycle demonstrate which are simple for them to comprehend & to follow (Janka, 2002). Each phase completion is effectively decided since it is characterized by the deliverables time & connotes the kickoff from the following phase.
3.4 Predictive SDLC’s Cons:
In predictive SDLC no working software is created until the late phases of the product development. A working software item is just created at the last phase of the product development process. The testing & reviews are done just in the later phases of the lifecycle phases. As a rule, there is an ID of each requirement that wasn't catered for amid the development, & this attempts the endeavors that put in the entire procedure invalid & squandered since the entire procedure is rehashed to accommodate the requirements.
3.5 Suggested SDLC for Headspace Project:
During the development of the project of Headspace the best approach to adopt & execute is the Adaptive SDLC. Headspace is a project which will be utilized by numerous people, by utilizing the adaptive methodology for its development will be the best as in adaptive SDLC it utilized the involvement of extensive users, side by side of each phase of development before & after.
In the Headspace project a culmination of the requirements of users is essential & it will be only done by implementation of adaptive SDLC as the gathering of requirements is done iteratively from initial phase to the completion & henceforth confirmation of the fulfillment of the considerable number of requirements in final product. The project Headspace includes different components & its object-oriented, & thus prescient procedures can't be connected in the project. The adaptive system is the perfect methodology for project Since headspace lies in complex projects, the perfect methodology to actualize in the design & development would be the adaptive SDLC approach. So applying the adaptive approach from the requirement elicitation phase till the maintenance phase will be beneficial to build an outstanding system.
Umar, M., & Khan, N. A. (2011). Analyzing Non-Functional Requirements (NFRs) for software development. 2011 IEEE 2nd International Conference on Software Engineering and Service Science. doi:10.1109/icsess.2011.5982328 (Umar & Khan, 2011)
Identifying Non-Functional Requirements. (2016). Retrieved October 4, 2018, from http://www.cs.sjsu.edu/~pearce/modules/lectures/ooa/requirements/IdentifyingURPS.htm
Nonfunctional Requirements. (2018, April 19). Retrieved October 3, 2018, from https://www.scaledagileframework.com/nonfunctional-requirements/
Fernández-Cardeñosa, G., Torre-Díez, I. D., López-Coronado, M., & Rodrigues, J. J. (2012, April 11). Analysis of Cloud-Based Solutions on EHRs Systems in Different Scenarios. Retrieved from https://link.springer.com/article/10.1007/s10916-012-9850-2
The Risks and Benefits of Using a Cloud Based Solution. (2018, June 25). Retrieved from https://www.clearspider.com/blog-cloud-based-solution-risks-benefits/
Pros And Cons Of Adaptive And Predictive SDLC. (2015). Retrieved October 3, 2018, from https://myassignmenthelp.com/free-samples/pros-and-cons-of-adaptive-and-predictive-sdlc
Beyer, H. (2010). User-centered agile methods. [San Rafael, Calif.]: Morgan & Claypool Publishers.
Holcombe, W. (2008). Running an agile software development project. Hoboken, N.J.: Wiley.
Janka, R. (2002). Specification and Design Methodology for Real-Time Embedded Systems. Boston, MA: Springer US.
Srivyshnavi, P. (2013). Modeling For Software Quality Assurance. SaarbruÌˆcken: LAP LAMBERT Academic Publishing.