Unit 2.1 Requiement Enginnering.pdf

Unit 2.1 Requirement Engineering Requirement Analysis & Specification © LPU :: CAP437: SOFTWARE ENGINEERING PRACTICES : Ashwani Kumar Tewari Requirement Engineeri eering Requirements ents describe...

Unit 2.1 Requirement Engineering Requirement Analysis & Specification © LPU :: CAP437: SOFTWARE ENGINEERING PRACTICES : Ashwani Kumar Tewari Requirement Engineeri eering Requirements ents describe What not How Produces one large document nt written in natural language contains a description of what hat the system will do without describing how it will do it Crucial process steps Quality of product Process that creates it Without well written document -- Developers do not ot know what to build -- Customers do not know what to expect -- What to validate 2 © LPU :: CAP437: SOFTWARE ENGINEERING PRACTICES : Ashwani Kumar Tewari  neering Requirement Engin Requirement Engineering is the displined application of proven principles, methods, tools and notations to describe a proposed system’s intended behavior and is associated constraints. Requirements engineering is a process of gathering and defining of what the services should be provided by the system. SRS may act as a contract betw ween developerand customer o uncover Requirements are difficult to Requirements change Over reliance on CASE Tools Tight project Schedule Communication barriers Market driven software developm ment Lack of resources © LPU :: CAP437: SOFTWARE ENGINEERING PRACTICES : Ashwani Kumar Tewari Requirement Engineeri eering Problem Statement Requiremments Elicitatio on Requirements Requirement Analysis Engineering Requirements Documentation Requirement Review SRS Crucial Process Steps of requirement en ngineering © LPU :: CAP437: SOFTWARE ENGINEERING PRACTICES : Ashwani Kumar Tewari Requirement Enginee eering  Tasks and techniques that lead to an understanding of requirements is called requireme ment engineering.  Requirement engineering provid des the appropriate mechanism for understanding What customer wants Analyzing needs Assessing feasibility Negotiating a reasonable solutiion Specifying solution unambiguoously Validating the specification Managing requirements © LPU :: CAP437: SOFTWARE ENGINEERING PRACTICES : Ashwani Kumar Tewari Types of Requiremeents Types of Require equirements Known Unkno own Undreamed Requirements Requirem ments Requirements Stakeholder: Anyone who should hould have h some direct or indirect influence on the system requirem ements --- User --- Afffected persons Requireme ments Functional Non-Functional 6 © LPU :: CAP437: SOFTWARE ENGINEERING PRACTICES : Ashwani Kumar Tewari Functional & Non-Funnctional requirements  Requirements generally fall into two types: 1. Functional requirements Functional 2. Non-Functional requirements requirements l Non- Functional requirements Don't put what you want to doo - before how you need to do it © LPU :: CAP437: SOFTWARE ENGINEERING PRACTICES : Ashwani Kumar Tewari  Functional requirem ments Any requirement which specifiees what the system should do. A functional requirement will deescribe a particular behaviour of function of the system when certain c conditions are met, for example: “Send email when a new w customer signs up” or “Open a new account”. Typical functional requirements incclude: Business Rules Audit Tracking Transaction corrections, External Interfaces adjustments and cancellations Reporting Requirements Administrative functions Historical Data Authentication Legal or Regulatory Authorization levels Requirements Functional requirements descriibe what the software has to do © LPU :: CAP437: SOFTWARE ENGINEERING PRACTICES : Ashwani Kumar Tewari  Non-Functional reqquirements Any requirement which specifiees how the system performs a certain function. f A non-functional requirement wil ill describe how a system should behave and what limits theere are on its functionality. Typical Non-Functional requiremen nts include: Response time Availabili ility Regulatory Throughput Reliability y Manageability Utilization Recoverab bility Environmental Static volumetric Maintainaability Data Integrity Scalability Serviceabbility Usability Capacity Security Interoperability non-functional requirements ts are mostly quality requirement that specifies how well the software does what it is supposed to do. © LPU :: CAP437: SOFTWARE ENGINEERING PRACTICES : Ashwani Kumar Tewari Library Managemennt System Function Requirements Add Article: New entries must be enteered in database Update Article: Any changes in articlles should be updated in case of update Delete Article: Wrong entry must be removed re from system Inquiry Members: Inquiry all current enrolled members to view their details Inquiry Issuance: Inquiry all database articles Check out Article: To issue any articlee must be checked out Check In article: After receiving any article a system will reenter article by Checking Inquiry waiting for approvals: Librarian ian will generates all newly application which is in waiting list Reserve Article: This use case is used d to reserve any book with the name of librarian, it can be pledged Set user Permission: From this user case c Librarian can give permission categorically, alsoenabling/disabling of o user permission can be set through this use case © LPU :: CAP437: SOFTWARE ENGINEERING PRACTICES : Ashwani Kumar Tewari  nt System Library Managemen Non-Function Requirements Safety Requirements: The database may get crashed at any certain time due to virus or operating system failurre. Therefore, it is required to take the database backup Security Requirements: We are goinng to develop a secured database for the university. There are different cateegories of users namely teaching staff, administrator, library staff ,students etc., Depending upon the category of user the access rights are decided. It means if the user is an administrator then he can be able to modify the data, d delete, append etc., all other users other than library staff only have thee rights to retrieve the information about database. Software Constraints: The developme ment of the system will be constrained by the availability of required software such as database and development tools. © LPU :: CAP437: SOFTWARE ENGINEERING PRACTICES : Ashwani Kumar Tewari Requirements Enginneering Tasks 1 Inception Roughly definne scope A basic unnderstanding of a problem, people who want a solution, the nature of solution desired At project inception, you establish a basic understanding of the problem, the people who want a solution, the nature of the solution that is desired, and the effective-- ness of preliminary communication and collaboration between the other stakeholders and the software team. Feasibility Study is a crucial phase in software development © LPU :: CAP437: SOFTWARE ENGINEERING PRACTICES : Ashwani Kumar Tewari  Requirements Enginneering Tasks 2 Elicitation (Requirement Ga athering) Define requirements The practice of collecting the requirements of a system from users, customers and other stakeholders In requirements engineering, requirements elicitation is the practice of researching and discovering the requirements of a system from users, customers, and other stakeholders. The practice is also sometimes referred to as "requirement gathering". © LPU :: CAP437: SOFTWARE ENGINEERING PRACTICES : Ashwani Kumar Tewari Requirements Engiineering Tasks cont. 3 Elaboration Further define d requirements Expand and refine requirements obtained from inceeption & elicitation Creationn of User scenarios, extract analysis class andd business domain entities 4 Negotiation Reconcileile conflicts Agree on o a deliverable system that is realistic for f developers and customers © LPU :: CAP437: SOFTWARE ENGINEERING PRACTICES : Ashwani Kumar Tewari Requirements Engiineering Tasks cont. 5 Specification Creaate analysis model It may m be written document, set of grapphical models, formal math hematical model, collection of userr scenarios, prototype or collection of th hese SRS S (Software Requirement Speccification) is a document that is creaated when a detailed description of all aspects as of software to build must be specified s before starting of project © LPU :: CAP437: SOFTWARE ENGINEERING PRACTICES : Ashwani Kumar Tewari Requirements Engiineering Tasks cont. 6 Validation Ensure quality of requirements Review the requirements specification for errors, ambiguities, omissions (absence) and confflicts 7 Requirements Management It is a seet of activities to identify, control & trace requirements & changes to requirem ments (Umbrella Activities) at any time as the project proceeds. Umbrella Activities- Risk mgmt, Measurement & Metrics, Re-usability, Documentation, Soft. Configuration, Soft. Quality Assurance, Formal Technical reviews, Soft Project tracking & control © LPU :: CAP437: SOFTWARE ENGINEERING PRACTICES : Ashwani Kumar Tewari