Requirements Engineering Fundamentals: Elicitation to Analysis

1. UNIT-II Requirements Engineering - Prof. Prasad Mahale

2. Syllabus • ELICITING REQUIREMENTS • BUILDING THE REQUIREMENTS MODEL • NEGOTIATING REQUIREMENTS • VALIDATING REQUIREMENTS • REQUIREMENTS ANALYSIS • SCENARIO-BASED MODELING • REQUIREMENTS MODELING STRATEGIES • FLOW-ORIENTED MODELING • DATA MODELING CONCEPTS • CLASS BASED MODELING • SRS.

3. ELICITING REQUIREMENTS(also called requirements gathering) • Collaborative Requirements Gathering Basic guidelines: • Meetings are conducted and attended by both software engineers and other stakeholders. • Rules for preparation and participation are established. • An agenda is suggested that is formal enough to cover all important points but informal enough to encourage the free flow of ideas. • A “facilitator” (can be a customer, a developer, or an outsider) controls the meeting. • A “definition mechanism” (can be work sheets, flip charts, or wall stickers or an electronic bulletin board, chat room, or virtual forum) is used. For Example- Safe Home Security Software

7. Quality Function Deployment QFD identifies three types of requirements • Normal requirements (graphical displays, specific system function, level of performance) • Expected requirements(ease of interaction, operational correctness, s/w installation) • Exciting requirements(multi touch screen, visual voice mail) • Usage Scenarios (use cases) • Elicitation Work Products

8. BUILDING THE REQUIREMENTS MODEL • Elements of the Requirements Model • Scenario-based elements • Class-based elements • Behavioral elements • Flow-oriented elements • Analysis patterns

10. NEGOTIATING REQUIREMENTS Boehm defines a set of negotiation activities are defined: • Identification of the system or subsystem’s key stakeholders. • Determination of the stakeholders’ “win conditions.” • Negotiation of the stakeholders’ win conditions to reconcile them into a set of win-win conditions for all concerned (including the software team).

11. VALIDATING REQUIREMENTS

12. VALIDATING REQUIREMENTS • A review of the requirements model addresses the following questions: • Is each requirement consistent with the overall objectives for the system/product? • Have all requirements been specified at the proper level of abstraction? That is, do some requirements provide a level of technical detail that is inappropriate at this stage? • Is the requirement really necessary or does it represent an add-on feature that maynot be essential to the objective of the system?

13. VALIDATING REQUIREMENTS • Does each requirement have attribution? That is a source (generally, a specific individual) noted for each requirement? • Do any requirements conflict with other requirements? • Is each requirement achievable in the technical environment that will house the system or product? • Is each requirement testable, once implemented? • Does the requirements model properly reflect the information, function, and behavior of the system to be built?

14. Is each requirement bounded and unambiguous? • Has the requirements model been “partitioned” in a way that exposes progressively more detailed information about the system? • Have requirements patterns been used to simplify the requirements model? Have all patterns been properly validated? Are all patterns consistent with customer requirements?

15. REQUIREMENTS ANALYSISRequirements Modeling: Scenarios, Information, and Analysis Classes • Overall Objectives and Philosophy

16. Requirements Analysis • Requirements analysis • specifies software’s operational characteristics • indicates software's interface with other system elements • establishes constraints that software must meet • Requirements analysis allows the software engineer (called an analyst or modeler in this role) to: • elaborate on basic requirements established during earlier requirement engineering tasks • build models that depict user scenarios, functional activities, problem classes and their relationships, system and class behavior, and the flow of data as it is transformed.

17. REQUIREMENTS ANALYSIS 2. Analysis Rules of Thumb • The model should focus on requirements that are visible within the problem or business domain. The level of abstraction should be relatively high. “ • Each element of the requirements model should add to an overall understanding of software requirements and provide insight into the information domain, function, and behavior of the system. • Delay consideration of infrastructure and other nonfunctional models until design. • Minimize coupling throughout the system. • Be certain that the requirements model provides value to all stakeholders. • Keep the model as simple as it can be.

18. REQUIREMENTS ANALYSIS 3. Domain Analysis

19. 3. Domain Analysis • Define the domain to be investigated. • Collect a representative sample of applications in the domain. • Analyze each application in the sample. • Develop an analysis model for the objects.

20. 4. Requirements Modeling Approaches

21. SCENARIO-BASED MODELING • Creating a Preliminary Use Case • What to write about? • Refining a Preliminary Use Case • Can the actor take some other action at this point? • Is it possible that the actor will encounter some error condition at this point? • Is it possible that the actor will encounter some other behavior at this point (e.g., behavior that is invoked by some event outside the actor’s control)? • Writing a Formal Use Case

26. REQUIREMENTS MODELING STRATEGIES

27. Data Flow Diagram • DFD is a graphical representation of the “flow” of data through as information system. • DFD’s can also be used for the visualizing and data processing. • It views a system as a function that transform the input into desired output. • The DFD is one of the methods that system analysts use to collect information necessary to determine information system requirements.

28. DFD Symbols and Definitions • Process - performs some action on data, such as creates, modifies, stores, delete, etc. Can be manual or supported by computer. • Data store - information that is kept and accessed. May be in paper file folder or a database. • External entity - is the origin or destination of data. Entities are external to the system. • Data flow - the flow of data into or out of a process, datastore or entity Process Data store External Entity Data flow

29. DFD: Numbering Levels • In a DFD with many levels it’s easy to forget which level you are on. • That’s why each level has different numbering for the processes on the diagram. • The ‘level’ corresponds to the number of decimal places required to define a process in it. Here’s how it works: • Context Diagram Process labeled “0” • Level 0 Processes labeled 1.0, 2.0, 3.0, . • Level 1 Processes labeled 1.1, 1.2, 1.3, . • Level 2 Processes labeled 1.11, 1.12,...

30. Level 0 DFD/ Context Level

31. Level 1 DFD

32. Level 2 DFD

33. Top (0) Process Level

34. Level 1: Membership

35. Level 2: Membership

36. FLOW-ORIENTED MODELING • Creating a Data Flow Model

37. FLOW-ORIENTED MODELING

38. FLOW-ORIENTED MODELING

39. FLOW-ORIENTED MODELING • Creating a Control Flow Model • The Control Specification

40. The Process Specification

41. DATA MODELING CONCEPTS • Data Objects • Data Attributes • Relationships

42. CLASS-BASED MODELING • Identifying Analysis Classes • Specifying Attributes • Defining Operations • Class-Responsibility-Collaborator (CRC) Modeling • Classes • Responsibilities • Collaborations • Associations and Dependencies

45. Software Requirement Specification • The Software Requirements Specification is produced at the conclusion of the analysis task. • Other information pertinent to requirements • States the goals and objectives of the software • Detailed description of the problem that the software must solve • Solve the problem is presented in the Functional Description • Validation Criteria is probably the most important and ironically • The specification includes a Bibliography and Appendix