Chapter 3 Requirements Engineering PDF

Chap3 Requirements Engineering 3.1 Introduction Requirements engineering is one of the most vital steps in the software development life cycle. It is the discipline that involves creating and documenting requirements. The various activities associated with it are elicitation, specification, analysis...

Chap3 Requirements Engineering 3.1 Introduction Requirements engineering is one of the most vital steps in the software development life cycle. It is the discipline that involves creating and documenting requirements. The various activities associated with it are elicitation, specification, analysis, verification and validation, and management. The requirements engineering process is critical since it emphasizes determining whether the system is beneficial to the organization, determining requirements, translating those requirements into a standardized format, and ensuring that they reflect the system that the client desires. Requirements engineering provide the appropriate mechanism to understand what the customer desires, analyzing the need, and assessing feasibility, negotiating a reasonable solution, specifying the solution clearly, validating the specifications and managing the requirements as they are transformed into a working system. Thus, requirement engineering is the disciplined application of proven principles, methods, tools, and notation to describe a proposed system's intended behavior and its associated constraints. 3.2 Classifications of Software Requirements System requirements are clearly articulated statements of what a system must be able to do in order to meet the needs and requirements of stakeholders and are derived from business requirements and user requirements. The requirements can be obvious or hidden, known or unknown, expected or unexpected from client’s point of view. Software requirements are mainly classified into three types: ▪ Functional requirements ▪ Non-functional requirements ▪ Domain requirements Fig. 1: Types of Software Requirements ▪ Functional Requirements Definition: Functional requirements describe what the software should do. They define the functions or features that the system must have. Examples: User Authentication: The system must allow users to log in using a username and password.  Search Functionality: The software should enable users to search for products by name or category. Report Generation: The system should be able to generate sales reports for a specified date range. ▪ Non-functional Requirements Definition: Non-functional requirements describe how the software performs a task rather than what it should do. They define the quality attributes, performance criteria, and constraints. Examples: Performance: The system should process 1,000 transactions per second. Usability: The software should be easy to use and have a user-friendly interface. Reliability: The system must have 99.9% uptime. Security: Data must be encrypted during transmission and storage. ▪ Domain Requirements Definition: Domain requirements are specific to the domain or industry in which the software operates. They include terminology, rules, and standards relevant to that particular domain. Examples: Healthcare: The software must comply with HIPAA regulations for handling patient data. Finance: The system should adhere to GAAP standards for financial reporting. E-commerce: The software should support various payment gateways like PayPal, Stripe, and credit cards. Other common classifications of software requirements can be: ▪ User requirements: These requirements describe what the end-user wants from the software system. User requirements are usually expressed in natural language and are typically gathered through interviews, surveys, or user feedback. ▪ System requirements: These requirements specify the technical characteristics of the software system, such as its architecture, hardware requirements, software components, and interfaces. System requirements are typically expressed in technical terms and are often used as a basis for system design. ▪ Business requirements: These requirements describe the business goals and objectives that the software system is expected to achieve. Business requirements are usually expressed in terms of revenue, market share, customer satisfaction, or other business metrics. ▪ Regulatory requirements: These requirements specify the legal or regulatory standards that the software system must meet. Regulatory requirements may include data privacy, security, accessibility, or other legal compliance requirements. ▪ Interface requirements: These requirements specify the interactions between the software system and external systems or components, such as databases, web services, or other software applications. ▪ Design requirements: These requirements describe the technical design of the software system. They include information about the software architecture, data structures, algorithms, and other technical aspects of the software. 3.3 Software Requirements Specifications [ Below are the software requirements specifications: Clear Correct Consistent Coherent  Comprehensible Modifiable Verifiable Unambiguous Traceable Credible source 3.4 Advantages of Classifying Software Requirements Advantages of classifying software requirements include: ▪ Better organization: Classifying software requirements helps organize them into groups that are easier to manage, prioritize, and track throughout the development process. ▪ Improved communication: Clear classification of requirements makes it easier to communicate them to stakeholders, developers, and other team members. ▪ Increased quality: By classifying requirements, potential conflicts or gaps can be identified early in the development process. ▪ Improved traceability: Classifying requirements helps establish traceability, which is essential for demonstrating compliance with regulatory or quality standards. 3.5 Disadvantages of Classifying Software Requirements Disadvantages of classifying software requirements include: ▪ Complexity: Classifying software requirements can be complex, especially if there are many stakeholders with different needs or requirements. ▪ Rigid structure: A rigid classification structure may limit the ability to accommodate changes or evolving needs during the development process. ▪ Misclassification: Misclassifying requirements can lead to errors or misunderstandings that can be costly to correct later in the development process. 3.6 Requirements Engineering (RE) RE is the process of identifying, eliciting, analyzing, specifying, validating, and managing the needs and expectations of stakeholders for a software system. Effective requirements engineering is crucial to the success of software development projects. It helps ensure that the software system meets the needs of all stakeholders and is delivered on time, within budget, and to the required quality standards. 3.7 Stages of Requirements Engineering Process The requirements engineering process consists of the following stages: 1. Elicitation: In this stage, the requirements are gathered from various stakeholders such as customers, users, and domain experts. The aim is to identify the features and functionalities that the software system should provide. 2. Analysis: In this stage, the requirements are analyzed to determine their feasibility, consistency, and completeness. The aim is to identify any conflicts or contradictions in the requirements and resolve them. Requirement analysis is significant and essential activity after elicitation. The various steps of requirements analysis are shown in the following figure: Fig. 2: Steps of Requirements Analysis Draw the Context Diagram: The context diagram is a simple model that defines the boundaries and interfaces of the proposed systems with the external world. It identifies the entities outside the proposed system that interact with the system. The context diagram of student result management system is given below: Development of a Prototype (optional): One effective way to find out what the customer wants is to construct a prototype, something that looks and preferably acts as part of the system they say they want.We can use their feedback to modify the prototype until the customer is satisfied continuously. Hence, the prototype helps the client to visualize the proposed system and increase the understanding of the requirements. When developers and users are not sure about some of the elements, a prototype may help both the parties to take a final decision. Model the Requirements: This process usually consists of various graphical representations of the functions, data entities, external entities, and the relationships between them. The graphical view may help to find incorrect, inconsistent, missing, and superfluous requirements. Such models include the Data Flow diagram, Entity-Relationship diagram, Data Dictionaries, State-transition diagrams, etc. Finalize the Requirements: After modeling the requirements, we will have a better understanding of the system behavior. The inconsistencies and ambiguities have been identified and corrected. The flow of data amongst various modules has been analyzed. 3. Specification: In this stage, the requirements are documented in a clear, concise, and unambiguous manner. The aim is to provide a detailed description of the requirements that can be understood by all stakeholders. Fig. 4: Users of the requirements document and how they use it The output of this stage is the Software Requirements Specifications (SRS) which is also called a requirements document. Characteristics of a good SRS: The following are the features of a good SRS document: Correctness: SRS is said to be perfect if it covers all the needs that are truly expected from the system. Completeness: The SRS is complete if, and only if, it includes the following elements: − All essential requirements, whether relating to functionality, performance, design, constraints, attributes, or external interfaces. − Definition of the software responses to all realizable classes of input data in all available categories of situations. − Full labels and references to all figures, tables, and diagrams in the SRS and definitions of all terms and units of measure. Consistency: The SRS is consistent if, and only if, no subset of individual requirements described in its conflict. Unambiguousness: SRS is unambiguous when every fixed requirement has only one interpretation. This suggests that each element is uniquely interpreted. Ranking for importance and stability: The SRS is ranked for importance and stability if each requirement in it has an identifier to indicate either the significance or stability of that particular requirement. Modifiability: SRS should be made as modifiable as likely and should be capable of quickly obtaining changes to the system to some extent. Verifiability: SRS is correct when the specified requirements can be verified with a cost-effective system to check whether the final software meets those requirements. Traceability: The SRS is traceable if the origin of each of the requirements is clear and if it facilitates the referencing of each condition in future development or enhancement documentation. Design Independence: There should be an option to select from multiple design alternatives for the final system. More specifically, the SRS should not contain any implementation details. Testability: An SRS should be written in such a method that it is simple to generate test cases and test plans from the report. Understandable by the customer: An end user may be an expert in his/her explicit domain but might not be trained in computer science. Hence, the purpose of formal notations and symbols should be avoided to as much extent as possible. The language should be kept simple and clear. Step 2: Define What the Purpose of Your Software is Answering the following question will help you to write the purpose: ✓ What problems does your product solve? ✓ Who are the intended users? ✓ Why is your product important? Step 3: Give an Overview Describe all features and functions and define how they will fit the user’s needs. Also, mention whether the product is new or a replacement for the old one, is it a stand-alone app or an add-on to an existing system? and don’t forget to mention what makes your product special or different from others. Step 4: Describe Functional and Non-functional Requirements Whether you write it internally or with the help of external experts, you should detail all the requirements associated with your app. Step 5: Add Supplemental Details If you have something else to add, any alternative ideas or proposals, references, or any other additional information that could help developers finish the job, write them down in this section of the software requirements specification. Step 6: Get Approval Now it’s time to have stakeholders review the SRS report carefully and leave comments or additions if there are any. 4. Validation: In this stage, the requirements are reviewed and validated to ensure that they meet the needs of all stakeholders. The aim is to ensure that the requirements are accurate, complete, and consistent. In the requirements validation process, we perform a different type of tests, these checks include: o Completeness checks o Consistency checks o Validity checks o Realism checks o Ambiguity checks o Variability The output of requirements validation is the list of problems and agreed-on actions of detected problems. Requirement Validation Techniques: There are several techniques that are used either individually or in conjunction with other techniques to check entire or part of the system: 1. Test Case Generation 2. Prototyping 3. Requirements Reviews 4. Automated Consistency Analysis 5. Simulation 6. Checklists for Validation 1. Test Case Generation The requirement mentioned in the SRS document should be testable, the conducted tests reveal the error present in the requirement. 2. Prototyping In this validation technique, the prototype of the system is presented to the end user or customer to check if it meets his needs. 3. Requirements Reviews In this approach, the SRS is carefully reviewed by a group of people including people from both the contractor organizations and the client side, the reviewer systematically analyses the document to check for errors and ambiguity. 4. Automated Consistency Analysis This approach is used for the automatic detection of an error, such as non-determinism, missing cases, a type error, and circular definitions, in requirements specifications. First, the requirement is structured in formal notation then the CASE tool is used to check the inconsistency of the system. The report of all inconsistencies is identified, and corrective actions are taken. 5. Simulation Simulating system behavior in order to verify requirements is known as simulation. This method works especially well for complicated systems when it is possible to replicate real-world settings and make sure the criteria fulfil the desired goals. 6. Checklists for Validation It employs pre-made checklists to methodically confirm that every prerequisite satisfies predetermined standards. Aspects like completeness, clarity and viability can all be covered by checklists. 5. Management: Requirements management is the process of managing the requirements throughout the software development life cycle, including tracking and controlling changes, and ensuring that the requirements are still valid and relevant. The goal of requirements management is to ensure that the software system being developed meets the needs and expectations of the stakeholders and that it is developed on time, within budget, and to the required quality. Several key activities are involved in requirements management, including: ▪ Tracking and controlling changes: This involves monitoring and controlling changes to the requirements throughout the development process, including identifying the source of the change, assessing the impact of the change, and approving or rejecting the change. ▪ Version control: This involves keeping track of different versions of the requirements document and other related artifacts. ▪ Traceability: This involves linking the requirements to other elements of the development process, such as design, testing, and validation. ▪ Communication: This involves ensuring that the requirements are communicated effectively to all stakeholders and that any changes or issues are addressed promptly. ▪ Monitoring and reporting: This involves monitoring the progress of the development process and reporting on the status of the requirements.