9/27/20161

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

9/27/20163

4

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.

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

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.

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/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.

9/27/ 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.

9/27/ 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.

9/27/ 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.

9/27/ 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.

9/27/201615

9/27/ 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.

9/27/ 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.

9/27/ 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.

9/27/ 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.

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

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

9/27/ 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.

9/27/201623

9/27/ 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.

9/27/ 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.

9/27/ 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.

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

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

9/27/ 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.

9/27/ 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.

9/27/ WHEN

9/27/ 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.

9/27/201633

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

9/27/ 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.

9/27/ 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.

9/27/ 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.

9/27/ 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.

9/27/ 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.

9/27/ 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.

9/27/ 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.

9/27/ 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.

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

9/27/201644

9/27/201645