1. 9/27/20161

2. 2 Group Members Sehrish YousafBSEF08A032 Huzaima Naheed QureshiBSEF08A033 Tehmina JavedBSEF08A037 Duaa AjmalBSEF08A048

3. 9/27/20163

4. 4

5. 5 WHAT The various levels and types of requirements that need to be defined. The requirements define the “what” of a software product. Requirements must be determined and agreed by the customers, users, and suppliers of a software product before the software can be built.

6. 9/27/20166 Levels and types of requirements 1.Business Level 2.User Level 3.Product Level

7. 9/27/20167 Business Level 1. Business Requirement: Business requirements define the business problems to be solved or the business opportunities to be addressed by the software product. In general, the business requirements define why the software product is being developed.

8. 9/27/20168 Cont… Business Requirements help us in discovering, analyzing, defining, and documenting the requirements that are related to a specific business objective. And by which you clearly and precisely define the scope of the project, so that you can assess the timescales and resources needed to complete it.

9. 9/27/20169 User Level 1. User Requirements: User requirements look at the functionality of the software product from the user’s perspective. They define what the software has to do in order for the users to accomplish their objectives. 2. Business Rules: In terms of SRE Business rules describe the operations, definitions and constraints that apply to a Software.

11. 9/27/201611 3. Quality attributes: Software Quality Attributes are the benchmarks that describe system’s intended behavior within the environment for which it was built. The quality attributes provide the means for measuring the fitness and suitability of a product.

12. 9/27/201612 Product Level 1. Constraints: A limitation of any kind to be considered in planning, programming, scheduling, implementing, or evaluating programs. 2. Functional Requirements: In software engineering, a functional requirement defines a function of a software system or its component. A function is described as a set of inputs, the behavior, and outputs.

13. 9/27/201613 3.Non-Functional Requirements: A non-functional requirement is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviors. This should be contrasted with functional requirement that define specific behavior or functions.

14. 9/27/201614 4.Data Requirements: The data requirements define the specific data items or data structures that must be included as part of the software product. 5.External Interfaces Requirements: Define the requirements for the information flow across shared interfaces to hardware, users, and other software applications outside the boundaries of the software product being developed.

15. 9/27/201615

16. 9/27/201616 When requirements are not well-defined: Eliciting: gather the detailed requirements that completely define the project. Analyzing: requirements are written into well structured statements. Writing good requirements are the most difficult parts of software engineering.

17. 9/27/201617 There are many issues that can have a negative impact on software development projects: Incomplete Requirements: developer can’t make right project that meet customer’s expected requirements. Lack of user Involvement: chances of failure of project. Requirements Churn: affect quality of project. Inaccurate estimates: cost, time, project schedule estimate will be wrong.

18. 9/27/201618 Gold plating in project: Gold plating is a technique that developers use in project to make their customers happy. It is an additional functionality to the software that was not in the requirements.

19. 9/27/201619 Disadvantages of gold plating: User may or may not want the new functionality. If he don’t, the cost of developing it is waste. Wasting resources: Implement additional functionality that’s never actually used. Risk: creates risk that defects in main part of functionality.

20. Quality Requirements: Expected Quality: that the customer explicitly states. Excited Quality: Additional functionalities added by the developer and “the user will just love.” Basic Quality: Requirements that a customer expects the product to have. 9/27/201620

21. Graph Of Relationship Between Customer Satisfaction & Quality Requirements: 9/27/201621

22. 9/27/201622 Scope of the project: Requirements define the scope of the project that is being developed. Without a clear picture of the scope, estimates of the project will be less accurate.

23. 9/27/201623

24. 9/27/201624 Stakeholders Stakeholders are individuals who affect or are affected by the software product. There are three main categories of stakeholders: Acquirers of the software product Suppliers of the software product Other stakeholders.

25. 9/27/201625 Acquirer type Stakeholders: Customers who request, purchase, and/or pay for the software product in order to meet their business objectives. Users also called end-users, who actually use the product directly or use the product indirectly by receiving reports, outputs, or other information generated by the product.

26. 9/27/201626 Supplier type stakeholders: The suppliers of the software product include individuals and teams that are part of the organization that develops the software product or are part of the organizations.

27. 9/27/201627 Supplier of software product include: Requirements analyst Designers Developers Testers Documentation writers Project managers Technical support Product change management.

28. 9/27/201628 Other Stakeholders: Legal or contract management Manufacturing or product release management Sales and marketing Upper management Government or regulatory agencies Society at large

29. 9/27/201629 Identifying and considering the needs of all of the different stakeholders can help prevent software product requirements from being overlooked. Identifying the stakeholders and getting them involved in the requirements engineering process brings different perspectives to the table that can aid in a more complete set of requirements early in the software development life cycle.

30. 9/27/201630 Software practitioners must determine when the stakeholder group needs to participate in the requirements engineering activities. Software practitioners must also determine how they are going to have each stakeholder group participate. The final decision is to establish the priorities of the stakeholder team members based on their relative importance to the success of the software product.

31. 9/27/201631 WHEN

32. 9/27/201632 Requirement Engineering is an Iterative Process. The business requirements are input into the development of the user-level requirements. The business and user-level requirements feed into the definition of the product-level requirements. The product requirements are then input into the software design and development process.

33. 9/27/201633

34. 9/27/201634 Two major Processes of Software Requirements Engineering 1. Requirements Development 2. Requirements Management

35. 9/27/201635 Requirements Development Requirements development is an iterative process. One should not expect to go through the steps in a one-shot, linear fashion. Requirements development encompasses all of the activities involved in: Eliciting Analyzing Specifying Validating the requirements.

36. 9/27/201636 ELICITATION: The elicitation process is the information-gathering step in the requirements development process. Different techniques to elicit requirements are: Stakeholder interviews Focus groups Observations of current work processes, Questionnaires and surveys Analysis of competitor’s products Benchmarking of industry practices.

37. 9/27/201637 ANALYZING: This step includes representing the requirements in various forms including : Prototypes and models. Performing trade-off analysis. Establishing priorities. Analyzing feasibility. Looking for gaps that identify missing requirements.

38. 9/27/201638 SPECIFYING: The requirements are formally documented during the specification step so they can be communicated to the product stakeholders. The requirements specification can take one of many forms: A single Software Requirements Specification (SRS) document. Multiple documents.

39. 9/27/201639 VALIDATION: The last step in the requirements development process is to validate the requirements to ensure that they are well written, complete, and will satisfy the customer needs. One of the primary tools for requirements validation is to conduct formal peer reviews of the requirements specification documents before they are baseline.

40. 9/27/201640 The peer review process should look at the requirements specification as a whole to ensure that it is: Complete. Consistent. Modifiable. Unambiguous. Concise. Finite. Measurable. Feasible. Testable. Traceable.

41. 9/27/201641 Requirements Management Requirements management starts with getting stakeholder buy-in to the baseline requirements. Requirements management encompasses the activities involved in: Requesting changes to the baseline requirements Performing impact analysis for the Requested changes, approving or disapproving those changes Implementing the approved changes.

42. 9/27/201642 Practitioners must understand the different types and levels of requirements to do a good job of requirements engineering. It requires an understanding of the benefits of having good requirements. Doing requirements engineering correctly requires an interdisciplinary approach that considers the needs of multiple stakeholder groups. It also requires expertise in the various skills of requirements engineering including requirements Eliciting, Analyzing, Specifying, Validating.

43. 9/27/201643 Brooks, F. 1995. Mythical man-month: essays on software engineering, 20th anniversary edition. Addison-Wesley Professional. Gause, D., and G. Weinberg. 1989. Exploring requirements, quality before design. New York: Dorset House Publishing. Pyzdek, T. 2000. Quality engineering handbook. New York: Marcel Dekker. Wiegers, K. E. 2003. Software requirements, 2nd Edition. Redmond, Wash.: Microsoft Press. Wiegers, K. E. 2004. In search of excellent requirements. Process Impact Web site. See Document by Linda Westfall. URL: http://www.google.com. URL: http://www.processimpact.com.http://www.processimpact.com

44. 9/27/201644

45. 9/27/201645