Non Functional Requirements for an SMS customer relation service - Essay Example

Non-Functional Requirements Affiliation Non-Functional Requirements It is imperative that any relation service system should have non-functional requirements together with their testing. The first non-functional key that all users must have is the availability. The availability of the system, also known as the uptime refers to the actual amount of time that a system is available or in use by the users. Knowing the time a system is available is important because some systems have distinctive designs with an expected downtime for activities such as database upgrade together with backups.

The hours of operation must take into consideration the weekends, all maintenance schedules as well as public holidays. Availability also ensures that the system has a relevant location of operation that meets the relevant connection requirements. Besides, the availability component denotes the percentage of time in which the system is up and must be running correctly (Bochmann, 2009). Performance is another imperative non-functional key that every user should be acquainted with, in any system.

The performance constraint must specify all the timing characteristics incorporated in the software. Some features and task are more time sensitive compared to others. Therefore, the non-functional requirement must be able to identify the software functions that contain any constraints on their performance. Performance also entails the response times which takes into account the loading time as well as the time the screen takes to open and the refresh durations. Other facets of performance include processing time, which entails imports, calculations, and exports.

Lastly, the query together with the reporting times that take into consideration the initial and subsequent loads forms another important aspect of performance (Griffiths, 2009).Another essential facet to note is usability. It incorporates the ease of use necessity. It addresses the features that establish the capacity of any software to be easily learned, understood and used by the intended users (Stellman, 2010). Additionally, the usability component takes into account the look and feel standards that integrate screen element, density, keyboard shortcuts, flow and layout, UI metaphors and colors.

Similarly, internationalization or localization requirements form an important feature of usability. Usability also takes into account paper sizes, keyboards, languages and spellings.The last non-functional key is security. It is very important to ensure that only trusted users can gain access to a system. The login requirements must maintain an access and CRUD level that ensure that non-authorized persons do not gain access to the system. When setting passwords, it is necessary to ensure that passwords have as many characters as possible so that any third party accessing them cannot memorize them within a glimpse.

Additionally, all passwords must have special characters to enhance complexity. On the same note, passwords must regularly be changed before they reach their expiry dates. Customers must also ensure that the password are not recycled as well as ensuring that when logged into a system, inactivity timeouts are activated. The timeouts enable the system to log automatically off; hence limiting third party actions on the system should they forget to log out after use (Stellman & Greene, 2005).ReferencesBochmann, V.G. (2009).

Non- Functional Requirements – Qualities SEG3101-ch3-4 –. Retrieved from May 30, 2015 http://www.site.uottawa.ca/~bochmann/SEG3101/Notes/SEG3101-ch3-4%20-%20Non-Functional%20Requirements%20-%20Qualities.pdfGriffiths, M. (2009). Non-Functional Requirements - Minimal Checklist - TypePad. Retrieved May 30, 2015 from http://leadinganswers.typepad.com/leading_answers/2009/03/nonfunctional-requirements-minimal-checklist.htmlStellman, A. (2010). Understanding nonfunctional requirements - OReilly Broadcast.

Retrieved May 30, 2015 from http://broadcast.oreilly.com/2010/02/nonfunctional-requirements-how.htmlStellman, A., & Greene, J. (2005). Applied software project management. Sebastopol, Calif: OReilly.