Home Secretary Application: SRS Overview

Software Requirement Specifications

The main purpose of developing the Home Secretary application intends to address the issue of scheduling for the Beecham’s family. The application would be in a capacity to inform the family on the upcoming events and activities thereby making it easier for the Beecham family to monitor their plans (Bhatia et al. 2020). The software can easily be updated through the mobile app known to have integrated the family activities into common features. With such a capacity of reminding the family members of the routine, the application stands a better chance of handling such situations like the one noted in the Beecham’s case study. In the case study, it could be noted that Ms Beecham had a range of items to be purchased from one of the favorite shop. However, Ms Beecham realized that John was headed home and would instead have made the purchase if she had the list of items shared.

Overview

From the case study, it could be noted that Beecham family had a challenge with organization of the activities. The idea of developing software application was meant to support the family in running errands, schedule activities and manage time at the same time. The software app enhances the efficiency of the end-user systems.

Product Scope and Domain

The software under development is the Home Secretary application, and would essentially play the fundamental role of maintaining records of the necessary activities and events. The events under consideration are deemed to be taken care of within the acceptable timelines and available resources. The home secretary software will be operated based on the hierarchy of the priorities determined by Mr. and Mrs. Beecham. The two are served with the role of posting as well as updating the events on the app that would be accessed by children. However, it should be noted that the application will be restricted to six members who will have the login details.

Assumption and Dependencies

In this context, the family members would be presumed to be the end users especially when the testing the product. Making use of the application is believed to lessen the chunk of tasks subjected to the end users as far as the daily schedules are put into consideration. The notable assumption is that the software product would be tested for one week before its launch for the purposes of determining the weaknesses. Another assumption is that the servers would be configured before the product launch with tests expected to be conducted by the family. Notable expectations are that the product will be compatible with all the phones the family member’s uses in the house as the six members use different phones. It is also assumed that John will bear this in mind the necessary requirements of the home-based tasks, events and activities while building up this application. Again, the budget of developing the application is expected to be lower or affordable considering the fact that the family would be one funding the process from the beginning to the end. A manual provided by John would be regarded as the guiding material that would help the family learn and operate the application in a more effective way (Song and Chen 2017).

Functional Requirements

A technical criteria manual is engaged in the specification of features that denote the intended customers, the program design and the device to be used in establishing the connection to the server (Eckhardt et al. 2016). Sampled functional requirements may cover a range of the options served to the end users while searching for events, dates and the time. Other options given to the family members include reporting any problem they encounter to the administrator through an integrated mail, according to different rights assigned to the users, and having a downloadable button where one can download any list given through the system.

User Requirements

It is worth noting that user requirements are the essential parts of any software or hardware hybrid system (Eckhardt et al. 2016). The software will be widely accepted by the users if it responds quickly, if it easy to operate, if it can provide a simple and easy user interface as well as have the capacity of handling system errors effectively. The approval by users, as it is with the case of Beecham’s family, depends primarily on how the program will be utilized. An appealing, simple, reliable and sensitive user interface must also be given for a successful output of the software system. The program is successful to the use if it offers means of productive operation. The user requires the product to be easy to navigate, simple interface, Feedback mechanism, default settings, purposeful layout, and responsive at the same time.

System Requirements

The project finds it necessary to describe the necessary parameters that would be attached to the devices and the server. Notably, the I/O port would operate with the peripheral unit (Bahill and Madni 2017). A separate operating system is needed for the smartphone or a specific program. It should be noted that Beecham family members have different devices that have different operating systems like Windows and IOS. Therefore, the design software needs to be installed and run across every device regardless of the type of operating system. Designing the application can, however, be time consuming and still be demanding in terms of the resources.

Non-Functional Requirements

The project also calls for the inclusion of the non-functional requirements, which highlights the characteristics produced from the user perspective (Khan et al. 2016). Some of the requirements that would attract attention include disaster recovery, logging, security, flexibility, performance and accessibility among others. First, security features are important and therefore play a fundamental role in terms of protecting the app from any planned or external attacks that are likely to ruin the privacy of the family. Most of the user relations would be grounded on the system security and the entire functionality of the software (Khan et al. 2016). The storage capacity and the costs are regarded as critical features that cannot be avoided. The family members should equally be engaged while making the most fundamental decisions regarding the non-functional requirements. In this context, the MoSCoW principle would be applied. The principle carries with it four fundamental elements, which include Could-Have, Must-Have, Should-Have and Won’t Have.

The Must-Have element defines the necessary features that would make sure that the app and the data of the family members are secure. Significant data is linked to the family identities and privacy. Under this element, storage equally remains a fundamental element given the essence of storing the family data. The end-users need to have the necessary login requirements as far as the control of functionalities is put into consideration. On the other hand, the Should-Have element requires that the system should have a steady as well as reliable performance, which is something that makes it easier to use. Good performance linked to the software also makes it user-friendly. The Could-Have elements denote the essence of disaster recovery attached to the Home secretary application software. Since this will be operated just among the family members, managing it will be much easier. The Won’t-Have element points at the costs, which are not regarded as determinant and does not map to any objective as this product will be homemade. Hence it will not be sold out to the public or put in app store apart from meeting the purpose for the Beecham’s family.

Security Requirements

Some of the most basic security requirements that need to be put into consideration are not limited to authentication and password management, network and data security as well as third party component analysis of the system (Oh and Kim 2017). Other requirements include audit logging analysis, and management authorization. Implementing some of these security requirements features factors such as confidentiality, availability, accountability, and integrity should be put in place to archive the results of security requirements.

Compatibility Requirements

Notably, software compatibility is one of the key features that need to be established across the systems or the software components. This feature is necessary in determining the level of satisfaction across the devices that are linked together (Gaynutdinov and Chermoshencev 2018). Most of the Beecham’s family members would use a range of the devices that have different operating system, the memory and use. For the home secretary application to remain relevant, it has to be compatible to windows, android or even both as far as the usage of phones is put into consideration.

Usability Requirements

It is important to provide an app that is easy to use and quick to remember. The above refers in particular to tools which are not widely employed. Just like using, Blender, Bank ATMs and any web page that anybody can access, the app should be simple to use without guidance for the first time. From the perspective of its primary users, the usability requirements for an interface design should be as follows. First, the design focuses on the usage efficiency, which points at the goals that can be quickly achieved without or without user errors. Secondly, the design should be Intuitive, which means that it should be simple to know and use the interface. Notably, keys, headings and notifications to help or error notifications should be quick to grasp. Lastly, attention is given to low perceived workload, which points at the essence of making the code simple to use instead of intimidating, difficult and stressful. When workload is low, it becomes easier for the family members to quickly adapt to the updates, changes and even the upgrades that would be provided to them by developers.

Ethical consideration

Ethics is the analysis or definition good, wrong, right, poor, ought, and applied to group norms and rules actions (Grant, 2019). The centre of digital option, like operating systems storage and exploitation of data/information, exposure to data and 'alternatives' Creation and collection require the ethical attention. In this application, ethical consideration will be addressed on privacy matters, software complicity and accuracy, authorship, accessibility and quality of life. This means that a patent for the home secretary application is in order for the purposes of ensuring that the software does not fall into the wrong hands. Patents, despite being legal, carry with them the moral value which ensures that end-users feel more secure while using the app, and equally trust the response from developers especially when there are technical hitches.

References

Bahill, A. T., & Madni, A. M. (2017). Discovering system requirements. In Tradeoff Decisions in System Design (pp. 373-457). Springer, Cham.

Bhatia, M. P. S., Kumar, A., Beniwal, R., & Malik, T. (2020). Ontology driven software development for automatic detection and updation of software requirement specifications. Journal of Discrete Mathematical Sciences and Cryptography, 23(1), 197-208.

Eckhardt, J., Vogelsang, A., & Fernández, D. M. (2016, May). Are" non-functional" requirements really non-functional? an investigation of non-functional requirements in practice. In Proceedings of the 38th International Conference on Software Engineering (pp. 832-842).

Gaynutdinov, R., & Chermoshencev, S. (2018, September). Virtual Testing of Electronic Systems Susceptibility by Electromagnetic Compatibility Requirements. In 2018 International Russian Automation Conference (RusAutoCon) (pp. 1-5). IEEE.

Grant, E. S. (2019, December). Principles of Ethical Consideration in Safety Critical Software Systems Development. In 2019 4th Technology Innovation Management and Engineering Science International Conference (TIMES-iCON) (pp. 1-5). IEEE.

Khan, F., Jan, S. R., Tahir, M., Khan, S., & Ullah, F. (2016). Survey: dealing non-functional requirements at architecture level. VFAST Transactions on Software Engineering, 9(2), 7-13.

Oh, S. R., & Kim, Y. G. (2017, February). Security requirements analysis for the IoT. In 2017 International Conference on Platform Technology and Service (PlatCon) (pp. 1-6). IEEE.

Song, S., & Chen, L. (2017). Response to “Differential Dependencies Revisited”. ACM Transactions on Database Systems (TODS), 42(1), 1-3.