MIS604 – REQUIREMENT ENGINEERING Assignment 1

Table of Contents

Introduction 3

Requirements documentation 3

Requirements scope 3

Two business goals and objectives to be achieved 3

A swim lane diagram of the payment process 4

Two business requirements 5

Two actors within the organization 6

Five functional requirements 6

Five non-functional requirements 7

Requirements Life Cycle Management 8

Significance of managing the requirements lifecycle 8

Implications of not managing requirements life cycle 9

Requirements Lifecycle stages 10

Phase 1; Trace Requirement 10

Phase 2; Maintain Requirement 10

Phase 3; Prioritize Requirement 10

Phase 4; Assess Requirement 11

Phase 5; Approve Requirement 11

Requirements Traceability Matrix to manage the requirements through each stage of the requirements lifecycle 11

Conclusion 13

References 14

Introduction

Requirements engineering is a crucial process in defining, documenting, and maintaining engineering design requirements (Ribeiro, 1996, p. 75). The process is very much critical in engineering and software engineering systems. The student start-up company is building a web and also a mobile application combination to enable the organizations which require short-term assistance to register online for the service (Inayat et al., 2015, p. 8). The report argues on the following aspects concerning the engineering design process; requirements documentation, requirements scope, two business goals to achieve, mapped swim lane diagram of the vital process, business requirements, system actors, functional requirements, and non-functional requirements. Further, the report will outline Life Cycle Management requirements, including its importance and implications of not managing it, Requirements Lifecycle, i.e., trace, maintain, prioritize and approve. Description of every stage, process objectives, main activities, and outputs of each step. Finally, the report will discuss a Requirements Traceability Matrix.

Requirements documentation

Requirements scope

A business requirement scope is a report which contains the formal details associated with the project that a business organization focuses on (Paul et al., 2014, p. 205). The scope details may include; the technical pathway detailing what the organization requires to meet its goal, expected outcome, and more. The significance of the requirements engineering scope in the Students Gigz Pty Ltd is to ensure that the stated problem is plain, clear, and complete and thus the solution is correct, functional, and practical. The scope summarizes the available requirements Students Gigz Pty Ltd will utilize while building a web and a mobile application combination (Harrin, 2013, p. 13). This includes requirements engineering approach methodologies, majorly the principles to improve a real problem into a digital solution (Dick et al., 2017, p. 135).

Two business goals and objectives to be achieved

The business goals are objectives the business focuses on solving and completing within a given period. Business goals outline an organizational main purpose and work, thus establishing its end goal for the workers and other company stakeholders to achieve (Souag et al., 2016, p. 15). Students Gigz Pty Ltd focuses on the key objective of building a web and a mobile application combination. The application combination is expected to allow other organizations requiring short-term assistance to register the service online, thus sourcing students with the necessary, appropriate skills. The student start-up company also focuses on ensuring organizations can call on students within short notice to fulfil their short-term vacancies with the relevant skills.

A swim lane diagram of the payment process

A swimlane is used to process flow charts to differentiate task and responsibility sharing by sub-processes in an organizational business process (Rajaraman, 2016, p. 28). The swimlanes can be either horizontally or vertically represented. The following figure illustrates a swimlane for the payment process in the Student Gigz Pty Ltd.

Two business requirements

Business requirements are the critical practices of an organization that should be focused on to achieve the organizational goals. Business requirements outline a business solution for the project, including customer needs and expectations documentation (Jarzębowicz & Połocka, 2017, p. 1190). Business requirement intends to introduce new software. Therefore, the business requires;

A business requirement documentation (BRD) outlines the business project’s organizational solution, such as customer details about their needs and expectations. This is to gain agreement between the organizational stakeholders, offer input to the next phase of the project, and describe how the solution will meet students’ needs. Also, the BRD will provide the Students Gigz Pty Ltd to communicate to the technology service provider about what to do to satisfy the student and business needs.

Two actors within the organization

Actors are model elements in an organization that operates the system process. The model element can be either a person or any other external system. An actor also exists in the business organization administration, as is a requirement in the engineering process design and the workflows. Actors are usually outside the organizational system process, thus directly interacting in either receiving outputs or offering inputs to the system process (Elallaoui et al., 2018, p. 47). Therefore in the Students Gigz Pty Ltd, actors are used in requirements management. In the student start-up company, the actors include; students, organizations, and more.

• Student- the students play a vital role in the system process. The mobile application is designed as a primary student interface. Students can create a profile where they will select their skills from a pre-existing list and the locations where they can work.
• Organizations will sign all the contracts and undertakings and post listings for their short-term employment needs. The organizations can send job alerts to students with the required appropriate skills in their listing who can work in their location via a message broadcast. Via the web system, the organizations can also review students’ profiles and share targeted messages to the students with experience in a specific area.

Five functional requirements

A Functional Requirement (FR) is also a functional specification that describes the software process’s service. It outlines the software system and its components (Becker et al., 2019, p. 154). The function in the software system includes; its behavior, inputs, outputs, and more. It can be a business process, calculation, user interaction, data manipulation or any system functionality (Young, 2004, p. 4). As in requirements engineering, functional specifications define specific outcomes of the system. In requirement engineering, Functional Requirements range from either a higher abstract statement or senders requirement to the applicable requirement mathematical specifications. Therefore functional software engineering helps the organization to access the required behavior of the system. The following is the requirements engineering Functional Requirements (FR);

• User registration- the students will be able to create a profile by registering their biodata to the web system, where they will be able to select their skills from a pre-existing list and the location suitable for them to work from.
• Posting/ sharing temporary jobs- the organizations can send job alerts to the students with appropriate skills in their listing, who can work in their location via a message broadcast.
• Rating and reviewing- the organizations can review student’s profiles and send targeted messages to students with experiences in a particular area. The organizations will also rate the student’s job offerings based on their profiles.
• Signing online contracts/ undertakings- the organizations will use the web portal to sign all contracts and undertakings and post listings for their short-term employment needs.
• Online payment- the organization will securely make payment for the students upon job completion through the app.

Five non-functional requirements

In a Requirement Engineering system, a non-functional requirement defines the process used to evaluate the system operation besides the particular behaviors. The system functionality can be speed, security, reliability, and more. The NFRs function as the constraints on the development process of a system across various backlogs, thus ensuring system usability and the effectiveness and efficiency of the whole system. NFRs may substantially affect the solution designing and testing; therefore, the system designers have to apply caution while outlining them (Asadi et al., 2014, p. 4). The following are non-functional requirements;

• Availability- in the Requirements engineering, availability is a state in which the system process is in a particular operable degree as the mission begins. The probability in which a system will operate effectively at a specified time under specific conditions within an ideal environment. It excludes waiting administrative and preventive maintenance logistics time.
• Compliance- compliance is all about confirming a rule such as specification, standard, and more. The organization uses regulatory compliance to outline its objectives which it aims at achieving to ensure that the system process steps comply with its rules, including standards, specifications and laws.
• Deployment- in Requirements Engineering, software deployment refers to all activities that ensure a software system process is operational. The organization utilizes the deployment process to determine the required resources needed for the system process to be functional. With software deployment, the system should operate effectively and efficiently, planning for the deployment process’s subsequent tasks.
• Operability- this is the ability to ensure that a system or the entire organizational installation is kept under safe and secure operating conditions. In the Requirement Engineering, this may include system ability, products and the corporate business processes to accomplish the goal target.
• Testability- in Requirement Engineering, software testability is the extent to which a software system supports testing in a specified test context. The organization uses regulatory testability to ensure that the system process suits any organization’s specified activity.

Requirements Life Cycle Management

Significance of managing the requirements lifecycle

In Requirement Engineering, requirements management refers to a process through which an organization documents, analyzes, traces, agrees, and prioritizes the system requirements controlling the changes, and therefore communicates them to the relevant stakeholder within the organization. Requirements engineering is a constant process throughout the project and a capability that project products and services conform to (Kärkkäinen et al., 2014, p. 673). The following are the importance of managing a requirements lifecycle;

• A better quality, compliance and speed- an organization should integrate its system processes and tools sharing with every team, thus enhancing the organizational communication and operational speed when reinforcing the quality of system software. Therefore an organization with effectively defined and appropriately integrated tools ensures that it delivers the end-user requirements of quality standards.
• Decision-making- in the Requirements Engineering, in the process of the system application development, operations, and development, the required tools ensure that better-suited methodologies have an effective business outcome. Managing a requirement lifecycle integrates the system users and processes for an efficient outcome, thus helping in organizational decision making. It also prioritizes the organizational set goals by determining the resources, methodologies, and skills, thus enabling the organization to enhance its business operations.
• Team productivity- it’s a fundamental aspect while managing a requirements lifecycle. The business employees, work productivity, and business progress should be highly monitored. An organization needs to employ transparency in each step and recognize every user’s input and the participating tools in a system process. This ensures that an organization attains and mitigates its deployment task on time and with no quality loss.
• Testing and resolving- developing either software or an app requires effective intercommunication to build and test. This imposes timely and easy recognition of any disruption, thus finding an effective solution for the same. While developing software, it’s essential to have an automated and standby build for multiple daily testing. This reduces integration challenges, thus enabling the system developers to consolidate their tasks with no setbacks.
• Employee backup and client satisfaction- in Requirements Engineering, management and support play an integral part in the solution. With the clients changing business requirements, the management integrates and supports the correct applications. Therefore, requirement lifecycle management helps in quickly releasing and delivering client satisfaction, thus balancing the user requirements and the organizational business goals.

Implications of not managing requirements life cycle

While there are signs of an organization employing quality requirements during its system development, there are impacts of creating poor conditions. These impacts include; architecture, design, implementation and also testing. Creating poor quality requirements can lead to the unrealistic cost of resources, colossal system development, and maintenance costs and also causes schedule overruns. Also, irrelevant conditions can result in an organizational project’s failure, resulting in scope creep (Kumar et al., 2013, p. 218). Poor requirements can also result in poor project functionality, implementation of unexpected things, poor system development, poor system processes, unrealistic project deadlines, poor documentation quality, and more.

Requirements Lifecycle stages

A requirements lifecycle involves various processes. The process depends on the software development methodology selected. It deals with project documentation such as a proposal, management plan, scope, and a business case. The standard requirement lifecycle phases are: trace, maintain, prioritize, assess and approve requirements.

Phase 1; Trace Requirement

Trace requirements that the system requirements and design are aligned at various levels to each other and regulate the impact of change in a particular group on another need. Traceability ensures enhanced relations to the different requirements, recognizing unrealistic gaps within the requirements, realistic insights within the scope with the complexity of change, the solutions based on the needs, and requirement traceability recognize and records every requirement lineage backward and the forward traceability.

Phase 2; Maintain Requirements

In Requirements Engineering, maintenance of the requirements ensures requirement accuracy by keeping them current. The significance of maintaining conditions is to maintain the states’ accuracy and their consistency during the whole requirement lifecycle. Also, maintaining the requirements supports the use of the conditions in other solutions. Maintaining requirements ensures re-usability, thus keeping track of the changing attributes. Maintaining requirements include requirements and designs that are kept current through maintenance throughout the projects live cycle.

Phase 3; Prioritize Requirement

Prioritizing requirement is significant in ranking the requirements based on their relevant importance. The objectives of prioritizing requirements are because the organizations experience constraints, and therefore, it is vital to take severe those vita requirements supporting the stakeholder satisfaction. Various elements should be put into consideration during the prioritization of the needs. These elements include; the basis of prioritization challenges faced during prioritization, continual prioritization, and more. The outputs of the maintenance requirement are requirements and design.

Phase 4; Assess Requirements

The assessment requirement monitors the implications of the proposed requirements and design changes. The changes that are considered include; the entire strategy alignment, effect value offered to the business and experienced by the organization’s stakeholders, the impact of the required resources to provide the value on time, and, finally, constraints involved throughout the initiative. The outputs of the assessment requirement are not other than the requirement and design assessment changes.

Phase 5; Approve Requirement

The approved requirement obtains the agreement and adopts the requirements and designs for the analyzed organizational work. Requirements and design approval can either be formal or informal. Approve requirement predictive approaches usually approve the conditions upon building and implementing the solution achievement, and that’s only when the requirement can begin. To complement the assessment, one must understand the organizational stakeholders’ roles, approval procedure, construct consensus, and track approvals. In most cases, this may call upon conflict resolution for the stakeholder to buy in. The approved requirement output includes the agreed requirements and design.

Requirements Traceability Matrix to manage the requirements through each stage of the requirements lifecycle

A traceability Matrix (RTM) is a document used by organizations to co-relate two forms that need many relationships to confirm the relationship completeness. Its main significance in an organization is to validate every requirement evaluated by the test cases such that each functionality is established during the software test (Lai & Ali, 2013, p. 41).

ID	Ass. ID	Requirements Description	Business Need, Justifications	Project Objectives	Requested By	Departments	WBS Element	Specifications	Design	Test Cases
1	1.1	User registration	For login purposes	Require project features	Students Gigz technical team	Content	3	Finished	In progress	4.1
1	1.2	Posting and sharing temporary jobs	For the skilled students to select	Require project features	Students Gigz technical team	Content	3.1	Finished	Finished	4.3
1	1.3	Rating and reviewing	To consider job allocation	Require project features	Students Gigz technical team	Content	3.2	Not started	In progress	4.4
1	1.4	Signing online contracts	To access initial information	Require project features	Students Gigz technical team	Content	3.3	Finished	On progress	4.7
1	1.5	Online payment	Payment for the complete tasks	Require project features	Students Gigz technical team	Content	3.4	Not started	Not started	4.9

Conclusion

It was concluded that in Requirement Engineering, the focus involves both functional requirements and non-functional requirements where the applicable requirements are interface associations. The non-functional requirements include the products and the project constraints. It was noted that it is vital to realize that nothing can be focused on independently in requirements engineering. Therefore, every focus and perspectives are essential in constructing an effective product. Further, while linking various focuses with views, it was concluded that it requires the association of requirements that unit each of the exciting squares. This builds a plus association requirements for the system developers. In system engineering, association requirements are made for both software and hardware to function together.

References

Asadi, M., Soltani, S., Gasevic, D., Hatala, M., & Bagheri, E. (2014). Toward automated feature model configuration with optimizing non-functional requirements. Information and Software Technology, 56(9), 1-45.

Becker, P., Tebes, G., Peppino, D., & Olsina, L. (2019). Applying an Improving Strategy that embeds Functional and Non-Functional Requirements Concepts. Journal of Computer Science and Technology, 19(2), e15-e15.

Dick, J., Hull, E., & Jackson, K. (2017). Requirements engineering (4th ed. ed.). Springer.

Elallaoui, M., Nafil, K., & Touahni, R. (2018). Automatic transformation of user stories into UML use case diagrams using NLP techniques. Procedia computer science, 130, 42-49.

Harrin, E. (2013). Managing Project Scope : Shortcuts to success. BCS Learning & Development Limited.

Inayat, I., Salim, S. S., Marczak, S., Daneva, M., & Shamshirband, S. (2015). A systematic literature review on agile requirements engineering practices and challenges. Computers in human behavior, 51, 1-15.

Jarzębowicz, A., & Połocka, K. (2017). Selecting requirements documentation techniques for software projects: a survey study. 2017 Federated Conference on Computer Science and Information Systems (FedCSIS),

Kärkkäinen, H., Myllärniemi, J., Okkonen, J., & Silventoinen, A. (2014). Assessing maturity requirements for implementing and using product lifecycle management. Int. J. Electr. Bus, 11(2), 669-678.

Kumar, N., Zadgaonkar, A., & Shukla, A. (2013). Evolving a new software development life cycle model SDLC-2013 with client satisfaction. International Journal of Soft Computing and Engineering (IJSCE), 3(1), 216-221.

Lai, R., & Ali, N. (2013). A requirements management method for global software development. AIS: Advances in Information Sciences, 1(1), 38-58.

Paul, D., Cadle, J., & Yeates, D. (2014). Business analysis (3rd ed. ed.). BCS Learning & Development Limited.

Rajaraman, V. (2016). Big data analytics. Resonance, 21(8), 695-716.

Ribeiro, R. A. (1996). Engineering contracts. Butterworth-Heinemann.

Souag, A., Mazo, R., Salinesi, C., & Comyn-Wattiau, I. (2016). Reusable knowledge in security requirements engineering: a systematic mapping study. Requirements Engineering, 21(2), 1-32.

Young, R. R. (2004). The requirements engineering handbook. Artech House.