Chapter 2

1. Chapter 2 Requirement Engineering

2. Topics • Problem recognition • Requirement Engineering Tasks • Processes • SRS • Use cases and Functional specification • Requirement validation • Requirement Analysis • Modeling and types

3. Requirement ? • A requirement can range from high level abstract statement of a service or of a system constrain to a detailed mathematical specification. • Req. themeselves are the descriptions of the system services & constraints that are generated during the Req. Eng process

4. Requirement engineering ? • Is the process of •  Establishing the services that the customer requirement from system •  The constraints under which it operates and is developed

5. In Req. Eng. • There is a systematic use of principles, techniques and tools for cost effective analysis, documentation and user needs. • Both the s/w eng. And customer take an active role in req. eng.

6. Types of Req. • User – collection of statement written for customer. • System – structured document gives detailed description. Contract between client and contractor. • Software specification – software description for design implementation.

7. Problem Recognition Sys engineering Req analysis Sw design

8. How is Req. analysis helpful? • Analyst - Help analyst to refine software allocation • Designer - After R.A. design can design for data, component level designs, interface • Developer -using req. spec. & design actual s/w can be developed

9. What are req. Ana. Efforts? • Problem Recognition - Need of the system • Evaluation • Modeling • Specification - SRS must be built • Review - SRS must be reviewed by project manager

10. Role of system analyst • What is system analyst ???

11. Cont.. • “Is a person who starts requirement gathering and requirement analysis activity by collecting all the information from the customer.”

12. cont.. • What is the problem ? • What is the need to solve the problem ? • What could be the solutions to the problem ? • What sort complexities or problem that might arise while solving the problem ? • What kind of input or output would be for the system ?

13. Requirements Engineering Tasks • Requirement Engineering is the process characterized for achieving following goals- • Understanding customer requirements and their needs • Analyzing the feasibility of the requirement • Negotiating the reasonable solutions • Specification of an unambiguous solution • Managing all the requirement • Finally transforming the requirements of the project • Seven distinct tasks • Inception • Elicitation • Elaboration • Negotiation • Specification • Validation • Requirements Management

14. Inception Elicitation Elaboration Negotiation Specification Validation Requirements Management

15. Inception Task • Inception means specifying the beginning of the software project. • Most of the s/w projects get started due to the business requirement. • There exist several stakeholders who define the business idea. • What is stakeholder? • During inception, the requirements engineer asks a set of questions to establish… 1. A basic understanding of the project 2.Find out all possible solutions and to identify the nature of the solution 3. Establish effectivecommunication between the customer and the developer

16. Inception Elicitation Elaboration Negotiation Specification Validation Requirements Management

17. Elicitation Task • Before the req. can be analyzed and modeled they must undergo through the process of elicitation. • Eliciting requirements is difficult because of • Scope of the Project • Understanding the Problems. • Problems of volatility • Elicitation may be accomplished through two activities • Collaborative requirements gathering • Quality function deployment

18. Inception Elicitation Elaboration Negotiation Specification Validation Requirements Management

19. Elaboration Task • The information about the requirements is expanded and refined • This information is gained during inception and elicitation • Goal: to prepare a technical model of s/w functions, features and constraints • Consists of several modeling and refinement tasks. • It is an analysis modeling task • Use cases are developed • Domain classes are identified along with their attributes and relationships • State machine diagrams are used to capture the life on an object • The end result is an analysis model that defines the functional, informational, and behavioral domains of the problem

20. Inception Elicitation Elaboration Negotiation Specification Validation Requirements Management

21. Negotiation Task • During negotiation, the software engineer reconciles the conflicts between what the customer wants and what can be achieved given limited business resources • Requirements are ranked (i.e., prioritized) by the customers, users, and other stakeholders • Risks associated with each requirement are identified and analyzed • Rough guesses of development effort are made and used to assess the impact of each requirement on project cost and delivery time • Using an iterative approach, requirements are eliminated, combined and/or modified so that each party achieves some measure of satisfaction

22. The Art of Negotiation • Recognize that it is not competition • Map out a strategy • Listen actively • Focus on the other party’s interests • Don’t let it get personal • Be creative • Be ready to commit

23. Inception Elicitation Elaboration Negotiation Specification Validation Requirements Management

24. Specification Task • A specification is the final work product produced by the requirements engineer • It can be written document, mathematical or graphical model, collection of use case scenarios • It is normally in the form of a software requirements specification • It serves as the foundation for subsequent software engineering activities • It describes the function and performance of a computer-based system and the constraints that will govern its development • It formalizes the informational, functional, and behavioral requirements of the proposed software in both a graphical and textual format

25. Inception Elicitation Elaboration Negotiation Specification Validation Requirements Management

26. Validation Task • It is an activity in which req. specification is analyzed in order to ensure that the req. are specified unambiguously • During validation, the work products produced as a result of requirements engineering are assessed for quality • The specification is examined to ensure that • all software requirements have been stated unambiguously • inconsistencies, omissions, and errors have been detected and corrected • the work products conform to the standards established for the process, the project, and the product • The formal technical review serves as the primary requirements validation mechanism • Members include software engineers, customers, users, and other stakeholders

27. Inception Elicitation Elaboration Negotiation Specification Validation Requirements Management

28. Requirements Management Task • It is the process of managing changing requirements during the requirements engineering process and system development. • Why requirements get change? • req. are always incomplete and inconsistent. New req. occur during the process as business needs change and a better understanding of the system is developed • Customers may specify the req. from business perspective that can conflict with end user req. • During the development of the system, its business & the technical environment may get changed

29. Requirement Management Processfollowing things should be planned :

30. Requirement Engineering Processes • Is process in which various activities such as discovery, analysis, validation are done. • Begins with feasibility study • Ends with req. validation • Finally a document is prepared • This process is a 3 stage activity, in which activities are arranged in iterative manner • Generic activities: • Req. Elicitation • Req. Analysis • Req. Validation • Req. Management

31. Requirement Engineering Processes Req. Elicitation & Analysis Feasibilitystudy Feasibility Report Req. Specification Req. Validation System Models User & Sys. Req. Req. Doc.

32. Spiral Model of Req. Eng. Process

33. Cont.. • It can also be viewed as structured analysis method • Along with creation of system models some additional information

34. Requirement Specification • S/w Req. Document is the specification of the system • Should include both a definition & a specification of req. • Not a design document • It is the set of what the system should do rather than how it should do • Provide a basis for creating the Software Requirement Specification (SRS)

35. SRS • Use: • In estimating cost • Planning team activities • Performing tasks • Tracking team progress • s/w designers use IEEE STD 830-1998 as the basis for S/w Spec.

36. Software Requirements Specification Who needs the SRS and for what purpose? • Users, customers and marketing personnel • SRS will meet their needs • Software developers • Develop the exact functionality which is specify in SRS document • Test engineers • SRS provide meaningful functionality for making test templates. • User documentation writers • Understand the SRS documents well enough to be able to write user’s manual. • Project managers • Estimate the cost easily and planning • Maintenance engineers • Understand the functionality, design and coding.

37. Software Requirements Specification • SRS document should clearly document the following aspects of a system: • Functional requirement • Non functional requirement • Goals of implementation • Functional requirement • High level functional requirements • Sub requirements • Non functional requirement • This include aspects concerning maintainability, portability and usability. • Also include reliability issues, accuracy of results, human-computer interfaces issues. • Goals of implementation • Give some general suggestions regarding development.

38. Characteristics of a good SRS documents • Concise • The SRS document is to the point at the same time unambiguous, consistent and complete. Irrelevant description reduce reliability and increase error in srs. • Structured • The SRS document should be well structured. • Black-box view • The SRS should specify the externally visible behavior of the system. • Conceptual integrity • The SRS document should exhibit conceptual integrity so that the reader can easily understand the contents. • Verifiable • Whether or not requirements have been met in an implementation.

39. Organization of the SRS document • Depends on system analysist • Depends on Project type • Depends on company polices and rules • So SRS document is always differ organization to organization.

40. Software Requirements Specification Format 1. Introduction 1.1 Purpose 1.2 Scope 1.3 Definitions, Acronyms and Abbreviations 1.4 References 2. Overall Description 2.1 Product Perspective 2.2 Product Features 2.3 User classes 2.4 operating environment 2.5 Design and Implementations constraints 2.6 Assumptions and dependencies

41. Cont.. 3. System Features 3.1 System feature 1 3.2 System Feature 2 (and so on) 4. External Interface Requirements 4.1 User Interface 4.2 H/w interface 4.3 s/w interface 4.4 Communication Interface 5. Other Nonfunctional Requirements 5.1 Performance Requirements 5.2 Safety Requirements 5.3 Security Requirements 5.4 SQA 6. Other Requirements

42. Introduction. • The following subsections of the Software Requirements Specifications (SRS) document should provide an overview of the entire SRS. The thing to keep in mind as you write this document is that you are telling what the system must do – so that designers can ultimately build it. Do not use this document for design!!!

43. Purpose • Identify the purpose of this SRS and its intended audience. In this subsection, describe the purpose of the particular SRS and specify the intended audience for the SRS.

44. Scope • In this subsection: • Identify the software product(s) to be produced by name • Explain what the software product(s) will, and, if necessary, will not do • Describe the application of the software being specified, including relevant benefits, objectives, and goals • Be consistent with similar statements in higher-level specifications if they exist • This should be an executive-level summary. Do not enumerate the whole requirements list here.

45. Definitions, Acronyms, and Abbreviations. • Provide the definitions of all terms, acronyms, and abbreviations required to properly interpret the SRS. This information may be provided by reference to one or more appendices in the SRS or by reference to documents. This information may be provided by reference to an Appendix.

46. References • In this subsection: • (1) Provide a complete list of all documents referenced elsewhere in the SRS • (2) Identify each document by title, report number (if applicable), date, and publishing organization • Specify the sources from which the references can be obtained.

47. SRS Example

48. Library Management System • In word document

49. Hospital management system

50. 1. Introduction • The SRS is produced at the culmination of the analysis task. The function and performance allocated to software as part of the system engineering and refined by establishing a complete information description, a detailed functional description, a representation of system behavior, indication of performance requirements and design constrains, appropriate validation criteria and the other information related to requirements.