1. Requirement engineering & Requirement tasks/Management. 1Prepared By:Jay A.Dave.

2. INTRODUCTION Requirement engineering helps software engineer to better understand the problem they will work to solve which consist of the set of tasks that lead to an understanding of what the business impact of the software will be. what the customer wants and how the end user will interact with the software. 2Prepared By:Jay A.Dave.

3. INTRODUCTION Software engineers sometime refer as system engineer or analyst in the IT world, and this is the duty of him/her. This is most required as designing and building the most elegant program that solves wrong problem serves no one’s needs and that is why it is important to know what customer wants before one begin to design and code computer based systems. 3Prepared By:Jay A.Dave.

4. INTRODUCTION Now it is very much important to know the steps involved in the process so the very first step begins with the inception which is the task that helps the customers to define what is required and there it has to be elaborated where basic requirements are fined and modified As the customer defines the problem. 4Prepared By:Jay A.Dave.

5. Inception software engineers use context-free questions to establish a basic understanding of the problem, the people who want a solution, the nature of the solution, and the effectiveness of the collaboration between customers and developers). How does the software project get started? 5Prepared By:Jay A.Dave.

6. Inception Is there a single event that catalyst for new computer based system or product, or does the need evolve over time? There is no definitive answer for such question. In some cases a casual conversation is all that is needed to participate a major software engineering effort, in general, most projects begin when a business need is identified or a potential new market or service is discovered. 6Prepared By:Jay A.Dave.

7. Inception Stakeholders from the business community define business case for the idea, try to identify the breadth and depth of the market, do a rough feasibility analysis, and identify a working description of the projects scope. All of this information is subject to change. At project inception software engineering ask a set of context-free question. The intent is to establish a basic understanding of the problem, the people who want a solution, the nature of the solution that is desired, and the effectiveness of preliminary communication and collaboration between the customer and developer. 7Prepared By:Jay A.Dave.

8. Elicitation find out from customers what the product objectives are, what is to be done, how the product fits into business needs, and how the product is used on a day to day basis). certainly seems simple enough- ask the customer, the users, and others what the objective for the system or product are, what is to be completed, how the system or product fits in to the needs of business and finally how the system or product is to be used on day-to-day basis. But it isn’t simple enough. There are few important facts about requirement elicitation. 8Prepared By:Jay A.Dave.

9. Elicitation Problem of scope: the boundary of the system is ill-defined or the customers/users specify unnecessary technical details that may confuse, rather than clarify overall system objectives. Problem of understanding: the customer/users are not completely sure of what is needed, have a poor understanding of the capabilities and limitations of their computing environment, do not have full understanding of the problem domain, have trouble communicating needs to system engineer, omit information that is believed to be obvious, specify requirements that conflict with the need of other customers/users, or specify requirements that are unstable or untestable. 9Prepared By:Jay A.Dave.

10. Elicitation Problem of volatility: the requirements changes over the time. 10Prepared By:Jay A.Dave.

11. Elaboration (focuses on developing a refined technical model of software functions, features, and constraints using the information obtained during inception and elicitation). The information is obtained from the customer inception and elicitation is expanded and refined during elaboration. This requirement engineering activity focus on developing a refined technical model of software functions features and constraints. 11Prepared By:Jay A.Dave.

12. Elaboration Elaboration Is an analysis modeling action that is composed of number of modeling and refinement task. Elaboration is driven by the creation and refinement of user scenarios that describes how the end user will interact with the system. 12Prepared By:Jay A.Dave.

13. Elaboration. Each user scenario is parsed to exact analysis classes business domain entries that are visible to end user. The attribute of each analysis classes are defined and services that are required for each classes are identified. The relationships and collaboration between classes are identified and variety of supplementary UML (unified modeling language) diagrams are produced. 13Prepared By:Jay A.Dave.

14. Elaboration The end result of elaboration is an analysis model that defines the informational functional and behavioral domain of the problem. 14Prepared By:Jay A.Dave.

15. Negotiation (requirements are categorized and organized into subsets, relations among requirements identified, requirements reviewed for correctness, requirements prioritized based on customer needs). It is not unusual for customer and user to ask for more than can be achieved, given limited business resources. 15Prepared By:Jay A.Dave.

16. Negotiation. It is also relatively common for different customers or users to propose conflicting requirements, arguing that their version is “essential for our special needs”. The requirement engineer must reconcile these conflicts through a process of negotiation. Customer, users and other stakeholders are asked to rank requirements and then discuss conflicting requirements and then discuss conflicts in priority. 16Prepared By:Jay A.Dave.

17. Negotiation Risk associated with each requirement are identified and analyzed. Rough estimates of development effort are made and used to assess the impact of each requirement on project cost and delivery time. Using an active approach, requirements are eliminated, combined, and/or modified so that each party achieves some measure of satisfaction 17Prepared By:Jay A.Dave.

18. Specificaion written work products produced describing the function, performance, and development constraints for a computer based system. In the contest of computer based system and software the term specification means different things to different people. A specification can be a written document as set of graphical models a formal mathematical model a collection of usage scenarios a prototype or any combination of these. 18Prepared By:Jay A.Dave.

19. Specificaion written work products produced describing the function, performance, and development constraints for a computer based system. In the contest of computer based system and software the term specification means different things to different people. A specification can be a written document as set of graphical models a formal mathematical model a collection of usage scenarios a prototype or any combination of these. 19Prepared By:Jay A.Dave.

20. Specification However it is sometimes necessary to remain flexible when a specification is to be developed. For large systems a written document combining natural language description and graphical models may be the best approach.. However usage scenarios may be all that are required for smaller product or system that resides within very well understood technical environments. 20Prepared By:Jay A.Dave.

21. Specification The specification is the final work product produced by the requirement engineer. It describes the function and performance of computer based system and the constraints that will govern its development. 21Prepared By:Jay A.Dave.

22. Requirements validation formal technical reviews used to examine the specification work products to ensure requirement quality and that all work products conform to agreed upon standards for the process, project, and product. 22Prepared By:Jay A.Dave.

23. Requirements validation The work product produced as a consequence of requirements engineering are assessed for quality during a validation step. Requirement validation examines the specification to ensure that all software requirements have been stated unambiguously, inconsistencies, omissions, errors have been detected and corrected and that work product confirms to the standard established for the process the project and the product. 23Prepared By:Jay A.Dave.

24. Requirements validation The primary requirement validation mechanism is the formal technical. The review team that validates requirements includes software engineers, customers, users and other stockholders who examine the specification looking for errors in content or interpretation areas where classification is required, missing information, and inconsistencies conflicting requirements. 24Prepared By:Jay A.Dave.

25. Requirements management Set of activities that help project team to identify, control, and track requirements and changes as project proceeds Many of these activities are identical to those that make up the software configuration management (SCM) process. Requirements are first identified, tagged with a unique identifier and classified by type (functional, data, behavioral, interface, or output) 25Prepared By:Jay A.Dave.

26. Requirements management Traceability tables (e.g., features, source, dependency, subsystem, interface) are developed and updated any time a requirement is modified) Database systems are invaluable in helping software teams track requirement changes 26Prepared By:Jay A.Dave.

27. Elements of Analysis model 27Prepared By:Jay A.Dave.

28. Use-Case 28Prepared By:Jay A.Dave.

29. Data flow diagram of level - 0 29Prepared By:Jay A.Dave.

30. State Diagram 30Prepared By:Jay A.Dave.

31. Class modelling 31Prepared By:Jay A.Dave.

32. Activity Diagram 32Prepared By:Jay A.Dave.