Software engineering -Requirement engineering.pptx

Requirement engineering,
functional requirements
nonfunctional requirement

1. Software engineering REQUIREMENT ENGINEERING Dr.M.KARTHIKA HEAD/DEPARTMENT OF INFORMATION TECHNOLOGY

2. Introduction Requirement Engineering framework emphasizes a structured, disciplined approach to gathering and defining software requirements. Also integrates core concepts of requirement engineering into his broader software engineering process, aiming to ensure software projects meet stakeholder needs effectively

3. definition Requirement engineering refers to the process of discovering, documenting, and managing the requirements for a software system. According to Pressman, it is a critical phase in software engineering, as poor requirements can lead to project failure. Requirement engineering typically addresses two types of requirements: Functional requirements (what the system should do). Non-functional requirements (how the system should perform, such as performance, security, usability).

4. Key Concepts 1. Stakeholder Identification Involves recognizing and engaging with all individuals or groups who have an interest in the project. These stakeholders may include end users, clients, developers, and business analysts. Pressman highlights the importance of understanding their different perspectives and needs. 2. Requirement Elicitation The process of collecting requirements from stakeholders. Pressman outlines several elicitation techniques, such as: Interviews with stakeholders. Workshops for collaborative discussions. Surveys and questionnaires to gather diverse opinions. Observation of current system behavior. Prototyping to give stakeholders a tangible idea of the solution. The challenge here is to overcome the issues of ambiguity, conflicting requirements, and incomplete information.

5. Key Concepts 3. Requirement Analysis and Elaboration Once requirements are collected, they must be analyzed to ensure they are feasible, consistent, and complete. In this phase, Pressman suggests refining initial high-level requirements into detailed specifications. This may involve: Use cases : Capturing functional requirements by describing how users will interact with the system. Scenarios : Story-driven elaborations that help illustrate how the system will behave in different situations. Modeling : Using tools like data flow diagrams (DFDs), entity-relationship diagrams (ERDs), or UML diagrams to model system behavior and data flows. 4. Requirement Negotiation Conflicts and trade-offs between stakeholders are often inevitable. Pressman recommends a negotiation process where stakeholders collaborate to agree on the most important requirements, prioritize them, and resolve discrepancies. The negotiation process includes: Prioritization : Identifying which features are essential and which can be delayed or dropped. Feasibility assessment : Evaluating if the proposed solutions are technically and economically viable. Trade-offs : Balancing competing stakeholder needs against project constraints such as time, budget, and scope.

6. Key Concepts 5 . Requirement Specification The outcome of requirement analysis and negotiation is documented in the form of a Software Requirements Specification (SRS) document. This is a formal representation of the system's expected behavior, including both functional and non-functional requirements. Clarity : The requirements should be expressed in a clear, concise, and unambiguous manner. Consistency : There should be no contradictory requirements. Testability : Every requirement should be verifiable through testing. 6. Requirement Validation Ensuring that the documented requirements align with stakeholder needs and are correct. Pressman advocates for validation techniques such as: Reviews and walkthroughs : Conducting reviews with stakeholders to confirm requirements. Prototyping : Demonstrating an early version of the system to validate user needs. Test cases : Developing test scenarios to verify that the requirements are met. 7. Requirement Management Requirements tend to evolve over time due to changing stakeholder needs, market conditions, or technical constraints. Pressman emphasizes the importance of requirements traceability and configuration management to handle requirement changes effectively. Change control : Implementing formal procedures to manage changes, track their impact, and update requirements accordingly. Traceability matrix : Ensuring that each requirement can be traced from the initial documentation to the final implementation, and vice versa.

7. Inception Goal: Establish a basic understanding of the problem and potential solutions. Activities: Identify stakeholders. Discuss the problem space. Gather high-level requirements. Set up project scope.

8. Elicitation Goal: Extract requirements from stakeholders. Activities: Conduct interviews, surveys, focus groups, and observations. Use techniques like brainstorming, prototyping, and scenarios. Handle challenges like ambiguous, incomplete, or contradictory requirements

9. Elaboration Goal: Refine and expand the requirements gathered during elicitation. Activities: Define use cases, scenarios, and user stories. Detail functional and non-functional requirements. Explore system behavior through models like data flow diagrams (DFDs), entity-relationship diagrams (ERDs), or UML models.

10. Negotiation Goal: Prioritize and resolve conflicts in requirements. Activities: Balance the needs of different stakeholders. Determine feasibility. Handle trade-offs between scope, time, and resources. Document agreed-upon requirements.

11. Specification Goal: Formally document the requirements for the system. Activities: Create a software requirements specification (SRS). Specify functional, non-functional, and interface requirements. Ensure the document is clear, unambiguous, and consistent.

12. Validation Goal: Ensure that the requirements are correct and aligned with stakeholder needs. Activities: Conduct reviews, inspections, or walk-throughs. Perform prototyping and simulation for validation. Make sure the requirements are testable and traceable.

13. Requirements Management Goal: Maintain and control changes to the requirements. Activities: Implement a requirements traceability matrix (RTM). Use configuration management tools. Track changes and ensure the system adheres to the evolving requirements. Monitor the impact of requirement changes on the project timeline and budget.

14. Types of Requirements Functional Requirements : These define specific functionalities or services the system should provide, like processing transactions or generating reports. Non-Functional Requirements : These describe how the system should perform or behave, addressing aspects like performance, reliability, security, and usability. Constraints : Requirements that impose limitations or restrictions on the development process, such as regulatory standards, hardware limitations, or budget constraints.

15. Summary Engage stakeholders actively throughout the process to ensure their needs are well understood and met. Maintain flexibility to adapt to changing requirements. Ensure traceability so that every requirement is mapped to corresponding features, code, and tests. Regularly review and validate requirements to catch errors early.

16. Thank you