Requirement Engineering

A. Requirement Engineering

Requirement engineering is a fundamental aspect of the software development process, focusing on understanding and documenting what needs to be built. It encompasses several critical phases, particularly emphasizing the definition phase, where system services and constraints are established.

Requirement engineering has four phases namely;

• Vision: This phase deals with the key issue of why the system is required to be developed. The first step involves development of business objectives, and the second step involves having an appreciation of the environment in which the software is going to run.
• Definition: This phase explains what should be constructed to address the system and again revolves around the specification of the system requirements without reference to implementation considerations. It states about the expected service, features, and constraint of the software.
• Development: Here, the design of the system and the integration of the resultant model to generate the final system take place.
• Maintenance: After deployment, this phase involve controlling updates and change for that purpose of ensuring the software is still effective in performing the needed tasks it was developed for as the time progresses.

Focus on Definition Phase

This is important because it addresses the matter of what needs to be built during the build-process but it does not address how this comes about. This phase involves:

• Establishing System Services: Determining a list of functions which the developed software should serve as.
• Defining Constraints: Stating any restriction that has to be faced while developing, or riding a certain program.

There are many different definitions of software requirements, although many of them stress such aspects of a system as Services, Constraints, Features, and Behaviors. These requirements for objects of credit and other financial securities can be explained by other influential works inclusive of Jones, Alan Davis, Ian Sommerville and IEEE frameworks.

SRS document plays an important role in the software development phase.

The Software Requirements Document (SRS) plays a pivotal role throughout the development lifecycle:

• Project Planning and Feasibility: This type of artifact is also known as the SRS, which is a document that must be provided during the planning stage of a project since it helps to identify aims and expected results in a project.
• Design and Coding: Thus, it is clear and easily comprehensible as specifications for the developers in the phase of design and coding compliance to user needs.
• Documentation and Testing: Complementing it is the SRS that provides the point of reference for testing activities, particularly where developed features conform to documented specifications.

Working with the SRS is frequently described as the process of using a living document since the document is very dynamic and continuously undergoes updates with changes in requirements during the project. This flexibility helps to keep most stakeholders on track and it is easier for everyone to have a clear vision and goal for the project.

Consequently, requirement engineering is a significant step towards developing software to user satisfaction and organizational objectives. The advantages of enhanced SRS focus on clear requirements definition within the context of structured phases, improved communication with other development phases and decreased problems connected with misunderstandings to provide high quality of the final software solution.

B. Levels of Software Requirements

Software requirements are characterized in terms of the degree of elaboration and level of definition. These different levels of details he stressed serve different purpose. In the following sections, we will briefly describe these levels and will provide further explanation of the differences between them with the help of examples.

1. Business Requirements

• Business requirements express the goals of an organization or a customer for a business system or a product. They focus on:
• High-Level Goals: Clearing on what goals the organization expects to accomplish with the new system: productivity, customer satisfaction, and the likes.
• Main Features: Describing key aspects of systems without going into specific details of determining their technical specifications. These are as encapsulated in a project vision and scope statement, which give an overall direction of the project.

2. User Requirements

• Users’ requirements are all the specifics that are needed in the whole development process and are formulated by the future consumers of the result. They include:
• User-Centric Focus: Explaining activities that the users need to perform to satisfy the business goals defined in the business specifications.
• Requirement Definition Document: The requirement definitions of a particular user are expressed in the requirement definition documents to avoid ambiguity concerning the needs of the users.

3. Functional Requirements

• Functional requirements describe a set of tasks and services that a system has to accomplish in order to fulfill user requirements and organizational objectives. They specify:
• System Functionality: Lists of activities, activities, and functioning that the system will have to accomplish. This concerns input, transformation, output, as well any user interfaces.
• System Perspective: These requirements are called from the system point of view, and they are a ready-made guide for developers that describe what has to be included in the system to fulfill user’s tasks.

Examples of functional requirements might include:

• The system shall also enable users to formulate accounts.
• The application must also give an email confirmation after registration.

4. Non-Functional Requirements

• There are constraints that the system should possess produced by non-functional requirements. They cover:
• Performance Attributes: Standard setting standards as to the quality of execution of the system functions envisaging aspects such as speed and reliability of the system and its potential for expansion.
• Operational Constraints: Constraints that come from interacting with other organizations, the design requirements and legal and industry requirements that have to be adhered to.

For instance, a non-functional requirement could stipulate that "the system must operate on Sun Solaris," impacting both architecture and design choices.

Importance of Non-Functional Requirements

Non-functional requirements are therefore very important in any system development since they jiggle the general frameworks of the systems developed.

Because non-functional requirements define the standards every user aims to achieve in software usability, these requirements play a significant role in software development. If these requirements are overlooked or poorly defined, it can lead to significant issues post-deployment, such as:

System failures resulting from nonachievement of performance objectives.

Post implementation acrimony if usability standards, which are part and parcel of the usability standards documents, are not met.

Conclusion

To sum up, it is crucial to define and describe four types of requirements: business, user, functional, and non-functional for the efficient software development. They progress from one to another in sequence, which makes certain that all aspects of what has to be constructed (and how) is well specified. This structured approach ensures that during the development there is no misunderstanding and when the product is complete it meets the user needs and the goal of business.

Stakeholders

The actors involved in the software development process have an important role of impacting the project results. Otherwise, it will be very difficult to meet all their requirements and capture all these needs to deliver a successful project implementation. Here a brief description of stakeholders and their impact if they are not considered in a business.

Importance of Stakeholders

• Diverse Perspectives: Stakeholders may be end usrs, managers, developers and customers or any other legal body that has an interest in the business. Every participant is prospective to contribute his/her demands and necessities, and that may result in a paradigm shift in the project.123

• User-Centric Development: Still, strong as the management usually is within a particular project, it is the actual user who will work with the system. Especially, their attitude towards the product either accepting it of rejecting it is very important. Failing to meet the needs of the users is a potential business system failure, and this can be proved by research work which shows that no or little user involvement is one of the reasons for project failure24.

• Conflicting Requirements: As much as the interest of different stakeholders are at heart, it is possible to arrive at a conflict in that different individuals will have different interests. Requirement engineers must consider these differences in order to make a functional requirements set that meets these competing needs13.

• Influence of Internal Politics: Another way that requirements can be defined at the stakeholder level is through the organization's internal processes. This might make requirement gathering process to be complicated since politics may incline towards giving some features priority as opposed to others.

The Role of Stakeholders in Requirement Engineering

• Requirement Specification: Some stakeholders pose their requirements in very general or probably vague terms, which makes it difficult in requirement engineering. Stakeholders have to interact with requirement engineers to better define and correlate such requirements into tangible requirements specifications12.

• Engagement Throughout Development: To obtain the basic and most extensive information stakeholders must be involved at the right stage of the development process. Their involvement should be maintained throughout PDCA cycle, from the planning to the checking stage.34

• Dynamic Roles: Stakeholders are not easy; they are dynamic in nature in terms of work in progress; their work may change during the course of the project. For example, while the end users are indirect influencers during the requirements phase they can be direct participants during the testing phases25. It is now important to identify these shifts in order to carry out collaboration properly.

Consequences of Neglecting Stakeholder Input

• Incomplete Requirements: Proper elicitation means gathering all the requirements, but if stakeholders are not heard properly during the process, it will lead to features insufficient to meet either user needs or business goals23.

• User Resistance: The enhanced system may provide no value for users if its design does not meet their expectations; in fact, it can trigger users’ negative attitudes and make them reject the new system, despite the extent to which technical specifications have been improved.45

• Increased Costs and Delays: Correcting missed requirements after the development phase can be costly and time-consuming because implementing change means teams have to scramble to identify shorts that should have been easily seen earlier

Conclusion

Consequently, stakeholders are key players in software development project endeavors. It always has a huge impact on the definition of the overall requirements that have reference to business motives and users’ expectations. For that reason, risks related to the reliance on incomplete or conflicted requirements may be managed if stakeholders are engaged and their information is consistently and accurately communicated; this can enhance the overall success of the developed software product.

C. Requirement Statement and Requirement Specification

SRS documents are written in different documents depending on the level of detail specified with software requirements. The two leading documents produced when implementing this phase are the Requirement Statement and the Requirement Specification. Also known as the Requirement Definition and the Functional Specification, these create documents for recording of user requirements and functional requirements, respectively.

Requirement Statement Characteristics

• Complete: Each requirement must thoroughly describe the functionality to be delivered.
• Correct: Every requirement should accurately represent the functionality to be built.
• Feasible: Each requirement must be achievable within the system's known capabilities and limitations.
• Necessary: Each requirement should reflect something the customer genuinely needs or is required for compliance with an external system requirement or standard.
• Prioritized: Each requirement, feature, or use case must have an assigned priority to indicate its importance for a specific product release.
• Unambiguous: All readers of a requirement should interpret it in the same, consistent way.
• Verifiable: It must be possible to create tests or use other verification methods, like inspection or demonstration, to confirm if the requirement has been correctly implemented.

Requirement Specification Characteristics

• Complete: No requirement or essential information should be omitted.
• Consistent: Requirements should not conflict with other software, higher-level system, or business requirements.
• Modifiable: The Software Requirement Specification should be easily revisable, with a record of changes maintained for each requirement.
• Traceable: Each requirement should be traceable to its source, as well as to the design elements, source code, and test cases that implement and verify it.

D. Relationship of Several components of Software Requirements

Assumptions

Assumptions are those conditions considered true while formulating and implementing a project. Some of them have to be documented so as to keep all the stakeholders informed on the belief systems that are being embraced in the project preparation and implementation processes. For example:

• Management Assumptions: When the chemical tracking system is developed, the management may think that it would be integrated to the current chemical stockroom inventory system and the purchasing department applications. In general, such assumptions can affect the planning and carrying out of projects.

Need for Archiving Assumptions

• Clarity: Any assumption made in a process must be presented in a clear and very specific method so that all the people involved in the project understand what is expected from everyone in order to avoid confusion.
• Risk Management: Realizing assumption helps teams to check the risks that may come during development in case the assumption turns out to be wrong.
• Change Management: When making an assumption, be sure that the change may affect a project scope, budget, or time line.

Dependencies

Dependence is therefore a relation between two tasks or else two components of a project. Dependencies are one of the critical factors when it comes to scheduling of the project and the resources deployed. For example:

• Task Dependencies: Some activities require accomplishment of other activities before they can be undertaken. In software development, coding may well depend on the finished design specifications.
• Resource Dependencies: It may be possible that available resources such as human and materials influence duration of a project.

Why Dependency Should Be Considered

• Scheduling: This paper identified dependencies and its importance in developing accurate schedules and time frames for project delivery.
• Resource Allocation: In view of this, when MPIs identify dependencies, they can effectively plan for the resources required throughout the various phases of the project.

Scope

The scope of this project entails the description of the proposed solution’s idea and the degree of its implementation, in outline, what should be included or excluded. Most importantly it helps in setting up proper organizational standards and framework to guide the behavior of stakeholders.

Key Elements of Project Scope

1. Goals and Objectives: StateBeSpecific about what the project seeks to accomplish.
2. Deliverables: State what measurable deliverables will be created.
3. Limitations and Exclusions: With the intention to minimize the risk of scope creep, avoid listing capabilities that will not be part of the project.
4. Quality Characteristics: Explain characteristics of quality that will enable it to provide the intended benefits in users.

Managing Scope Creep

Kamau asks: Scope creep is when new activities are introduced to the project without a change in the project’s cost or time plan. To manage this effectively:

• Document Requirements: Document every documented and proposed requirement as well as reasons for not implementing it.
• Change Control Process: Adopt a procedure that will need to be followed in the case of a change of some idea to consider it suitable for the project and the restrictive factors.

Scope and Initial Release

If considering an initial public release, it’s important to use bullet points to highlight the key features that are to be offered. This involves:

• Prioritization of Requirements: Define which should be considered as important in the first iteration of the product, which could be useful in later versions.
• Release Schedule: Construct the following timeline, then correlate the features to the overall amplitude of the project:

E. The Context Diagram

A context diagram of a system is an initial simplified diagram that gives an indication of where the system is situated and is identified by the following attributes: It is the initial method of systems analysis, used by stakeholders to define this system’s range of influence and how it processes information and data without focusing on deep interconnections. Listed below are specifications of what it is, what it is comprised of, and what it provides.

Purpose of a Context Diagram

• Define System Boundaries: Such as context diagrams that lends an insight into what is in and out of the boundaries of the system so that anyone involved in the project has the same perspective of what is included or excluded.
• Facilitate Requirement Gathering: Focusing on how the system to be developed works in cooperation with the environment also contributes to defining both user and non-user needs.
• Enhance Communication: Ensuring that context diagrams help in mediating communication between technical teams and necessary stakeholders, the figures facilitate communication and make it easier to talk about the systems requirements among other benefits.
• Risk Identification: Through identifying external contacts context diagrams help to identify risks that may be linked with reliance on actors outside the system boundary.

Tasks of the context diagram

• System/Product: The central sphere of the diagram on which lies the main emphasis of the analyst or designer of the corresponding software system. It is usually still represented by what may be a single circular or rectangular symbol at the center.
• External Entities: They are those users, other systems or processes that are outside the boundaries of the system under consideration. In the above-presented schemes, they are depicted as different geometric forms located around the central system.
• Data Flow: Arrows point at how the system interacts with these external entities transferring in and out different types of data. It is recommended to write above each arrow what kind of data is transferred.

How to Draw a Context Diagram

• Define the System: It is important to describe or define which system is being under consideration for analysis or designing.
• Identify External Entities: You should identify all actors involved in utilizing the system.
• Map Data Flows: Define the interaction between the system and secondary entities and describe data inputs and outputs’ types.
• Sketch the Diagram: Draw a circle representing the system and then draw a series of circles around the main circle where you illustrate which way the data flows.
• Label Components: For goal clarity make sure all the elements in the diagram have labels.
• Review and Verify: Involve the stakeholders and ensure the information is accurate and comprehensive.

Advantages of using the Context Diagram

• Clarity: Offers a basic understanding of how the system communicates with the outside world and hence is understood by both the technical and non technical audience.
• Early Issue Identification: Enables organizations to foresee issues touching on the external environment before they escalate to become serious development concerns.
• Collaboration Facilitation: Makes it easy for all stakeholders to visualize the interactions and also offer their opinions and ideas towards the teamwork.

F. Use Case Model Components

A use case model consists of two main elements: use cases and actors. The complete structure of the system defines the system’s scope of operation in terms of the functions it controls. This means that each use case details a single interaction; comprised at its simplest when an actor begins an interaction and an iteration of use ends when a specific function is performed by the functions of that use case. An actor, it could be a human being, a device or system, participate in the given system.

The use case model gives a view of how the different components will be used in the system, considering the system as a box where the only conveyable observation is the input and output. From the end-users’ perspective defining functional requirements, the specification can provide a clear and unambiguous description of how this can be achieved for developers. The model is used and elaborated during development to provide the references for the testers as the basis for the system tests and to allow the tracing of the functional requirements to the actual system parts in order to reveal the gaps.

Example

In a library management system, the use case diagram shows four actors: Book Borrower, Librarian, Browser, and Journal Borrower. Seven use cases are depicted as ovals inside of the rectangle, which denotes the system boundary. It means that any use case should bring benefit to the actor at any case.

Elaborated Use Cases
Once the use case model is created, each use case is expanded by detailing the interaction between the user and the system. An elaborated use case includes the following components:

• Use Case Name: The title of the use case.
• Implementation Priority: The relative priority of the use case for implementation.
• Actors: The names of the actors involved in the use case.
• Summary: A brief description of the use case.
• Precondition: The condition that must be fulfilled before the use case can be initiated.
• Post-Condition: The state of the system after the use case is completed.
• Extend: Any use case it extends, if applicable.
• Uses: Any use case it incorporates or uses, if applicable.
• Normal Course of Events: The sequence of actions during normal operation.
• Alternative Path: Variations or deviations from the normal course of events.
• Exception: Actions to take in case of an exceptional condition.
• Assumptions: All assumptions considered for this use case.

Reference:

https://asana.com/resources/software-requirement-document-template

https://agilemodeling.com/essays/stakeholders.htm

https://rikkeisoft.com/blog/software-development-requirements/

https://www.wrike.com/project-management-guide/faq/what-are-constraints-in-project-management/

https://business.adobe.com/blog/basics/project-scope-definition-best-practices-examples-and-more

https://online.visual-paradigm.com/knowledge/system-context-diagram/what-is-system-context-diagram/

https://miro.com/blog/context-diagram/

https://www.geeksforgeeks.org/context-diagrams/