Home > Subjects > IT/Technology > Non-Functional Requirements in Headspace Project

Non-Functional Requirements in Headspace Project

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+

Usability

  • 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?

Reliability

  • 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.

Performance​​ 

  • 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?

Security

  • 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.

Cloud-based solution for a Primary Care Centers Network.