- Slides: 31
Requirements Engineering: • User and system requirements, • Functional and non-functional requirements, • Types & Metrics, • A spiral view of the requirements engineering process.
• Software Requirements Specification (SRS): • The software requirements Specification document, • The structure of SRS, • Ways of writing a SRS, • structured & tabular SRS for an insulin pump case study
• • Requirements elicitation & Analysis: Process, Requirements validation, Requirements management. • • Case Studies: The information system. Case study – Mental health care patient management system (MHC-PMS).
• RE is a process of - establishing the services - that the customer requires from a system - & - the constraints, under which it operates & is developed.
• RE is a process of - identifying - what customer requires from a system & - how it can be fulfilled, - with available resources - (manpower, time, cost, hardware and software resources etc. )
• Requirement can range from - a high level abstract statement - of a service or of a system constraint - to a detailed mathematical functional specification.
Types of Requirements • User requirements – - collection of statements in natural language - description of services, that system provides. - written for customers. • System requirements – - structured document, of detailed requirements - & services provides by the system. - contract between client & contractor. • Software specification – - detailed software description. - that can serve as a basis for design or implementation. - written for software developers.
Requirements Engineering Tasks 1. 2. 3. 4. 5. 6. 7. Inception Elicitation Elaboration Negotiation Specification Validation Requirements Management
1. Inception • Specifying the beginning of the software project - (for what purpose the software is required? ) • Stakeholders – - do rough feasibility study & - identify scope of the project. • The purpose of inception is to - Establish the basic understanding of the project - Find out all possible solutions - Establish – effective communication between developer & customer.
2. Elicitation • Requirement Discovery • Sometimes - It is difficult to understand the customer needs, because – 1. Customer may not specify sufficient requirements or may specify too many requirements 2. Sometimes – - customer find it difficult to communicate - with system engineer, about their needs. 3. Customer may give – - ambiguous & confusing requirements – - intentionally or unintentionally
3. Elaboration • Information about – Requirements – - is expanded & refined. • Technical model of – - software functions, features & constraints - Is prepared.
• Modeling & refinement of requirements is done - user scenarios are created & refined. - each user scenario is parsed & various classes are identified. - then, the attributes & services (functions) of these classes are defined. - relationships among these classes is identified. - thus various UML diagrams are developed during this task - finally, analysis model get developed.
4. Negotiation • Sometimes – customer - demand For more than - that is achieved • To handle this, - Requirements engineer must - convince the customer - by solving various conflicts • By - ranking the requirements, - Setting priorities of the requirements - Eliminating, combining or modifying the requirements, using iterative approach.
5. Specification • Specification can be a written document, mathematical or graphical model, collection of use case scenarios • In a standard specification – Requirements are presented in consistent & understandable manner • Specification – is the final work product of requirement engineering process. • It describes – the functions, constraints and performance of computer based system
6. Validation • During this phase – Requirement specification is analyzed for finding – any inconsistencies, omissions & errors. to correct or modify. • A mechanism for validating requirements – • Formal technical review (FTR) In FTR, review team validates the software requirements - Review team consists of – requirement engineers, customers, end users & so on. - this team – identifies – conflicting requirements, inconsistencies or unrealistic requirements.
7. Requirements Management • Process of – manage, track & Change the requirements • Each requirement is assigned a unique id • After finalization of requirements – • Traceability table is developed • Which represents • dependencies of requirements on one another
• Case tool support is required for – 1. 2. 3. Requirement storage Change management Traceability information is - typically represented by - a data structure – traceability matrix
• If one requirement is dependent upon another requirement • Then • In that row-column cell, “D” is mentioned. • & if, there is a weak relationship between the requirements, • Then, • Corresponding entry can be denoted by “R”
For Mentioning The Traceability Of Small Systems, Usually The Traceability Matrix Is Maintained. • For example – Requirem ent ID A A B C D D B F R D C R D D R E F E R D
• Traceability – is concerned with - relationship between requirements their sources and the system design
Various types of – Traceability – are – • Source traceability These are – the links – from requirement to stakeholders, who propose • Requirements traceability – these are the links between dependent requirements • Design traceability – these are the links from requirements to design
• Requirement Management Process • Following things should be planned • during requirement management process • Fig – planning in the requirement management process Requirement Identification Requirements Are Individually Identified Change Management Process Plan Followed When Analyzing A Requirement Change Traceability Policies Case Tool Support The Amount Of Information About Requirement Relationships Is Maintained The Tool Support Which Is Required To Manage Requirement Change
Initiating Requirements Engineering Process
1. 2. 3. 4. Identification of Stakeholders Recognizing Multiple View Points Working Towards The Collaboration Questioning
1. Identification Of Stakeholders • Anyone who get benefited from the system directly or indirectly • • Customer, Software Developers, Product Engineers, Consultants, Marketing People, End Users, Support & Maintenance Engineers
2. Recognizing Multiple View Points • End user – • system should be easy to learn & use. • Marketing people – • system should be unique from others, to sell it easily. • Business managers – • system should meet the needs, within the budget. • Software developers – • requirements must be unambiguous & complete. • Support engineers – system should be easily maintained.
• All these stakeholders contribute a lot in RE process. • The information gathered • using different viewpoints • can be conflicting or may be inconsistent. • Hence, the RE categorize • all stakeholders information • in a systematic manner • So that decision makers can choose, • proper set of requirements.
3. Working Towards The Collaboration • For building a successful system, - the collaboration among - stakeholders & software engineers is must. • The job of requirements engineers is – - to identify - commonality, inconsistencies & conflicts. • Commonality – denotes, - the requirements on which, all stakeholders agree.
• These identified requirements are then categorized • During collaboration process, - different stakeholders - can present their own viewpoint • But business manager or senior technical person makes the final decision - about the requirements - which should be eliminated.
4. Questioning • During the project inception phase, • variety of – context free questions are asked. • For example – - Who will use the system? what will be exact output of the system? • And many more…. • These questions are useful - to initiate the communication and - are essential for successful elicitation.