Chapter 2 Requirement Engineering Topics Problem recognition Requirement

Chapter 2 Requirement Engineering

Topics �Problem recognition �Requirement Engineering Tasks �Processes �SRS �Use cases and Functional specification �Requirement validation �Requirement Analysis �Modeling and types

Requirement ? �A requirement can range from high level abstract statement of a service or of a system constrain to a detailed mathematical specification. �Req. themeselves are the descriptions of the system services & constraints that are generated during the Req. Eng process

Requirement engineering ? �Is the process of � Establishing the services that the customer requirement from system � The constraints under which it operates and is developed

In Req. Eng. �There is a systematic use of principles, techniques and tools for cost effective analysis, documentation and user needs. �Both the s/w eng. And customer take an active role in req. eng.

Types of Req. 1. User – collection of statement written for customer. 2. System – structured document gives detailed description. Contract between client and contractor. 3. Software specification – software description for design implementation.

Problem Recognition Sys engineering Req analysis Sw design

How is Req. analysis helpful? �Analyst - Help analyst to refine software allocation �Designer - After R. A. design can design for data, component level designs, interface �Developer -using req. spec. & design actual s/w can be developed

What are req. Ana. Efforts? �Problem Recognition - Need of the system �Evaluation �Modeling �Specification - SRS must be built �Review - SRS must be reviewed by project manager

Role of system analyst �What is system analyst ? ? ?

Cont. . �“Is a person who starts requirement gathering and requirement analysis activity by collecting all the information from the customer. ”

cont. . �What is the problem ? �What is the need to solve the problem ? �What could be the solutions to the problem ? �What sort complexities or problem that might arise while solving the problem ? �What kind of input or output would be for the system ?

Requirements Engineering Tasks � Requirement Engineering is the process characterized for 13 achieving following goals- Understanding customer requirements and their needs - Analyzing the feasibility of the requirement - Negotiating the reasonable solutions - Specification of an unambiguous solution - Managing all the requirement - Finally transforming the requirements of the project � Seven distinct tasks �Inception �Elicitation �Elaboration �Negotiation �Specification �Validation �Requirements Management

Inception Elicitation Elaboration Negotiation Specification Validation Requirements Management 14

Inception Task � Inception means specifying the beginning of the software project. � Most of the s/w projects get started due to the business requirement. � There exist several stakeholders who define the business idea. � What is stakeholder? � During inception, the requirements engineer asks a set of questions to establish… 1. A basic understanding of the project 2. Find out all possible solutions and to identify the nature of the solution 15 3. Establish effective communication between the customer and the developer

Inception Elicitation Elaboration Negotiation Specification Validation Requirements Management 16

Elicitation Task �Before the req. can be analyzed and modeled they must undergo through the process of elicitation. �Eliciting requirements is difficult because of �Scope of the Project �Understanding the Problems. �Problems of volatility �Elicitation may be accomplished through two activities �Collaborative requirements gathering �Quality function deployment 17

Inception Elicitation Elaboration Negotiation Specification Validation Requirements Management 21

Elaboration Task � The information about the requirements is expanded 22 and refined � This information is gained during inception and elicitation � Goal: to prepare a technical model of s/w functions, features and constraints � Consists of several modeling and refinement tasks. � It is an analysis modeling task �Use cases are developed �Domain classes are identified along with their attributes and relationships �State machine diagrams are used to capture the life on an object � The end result is an analysis model that defines the functional, informational, and behavioral domains of

Inception Elicitation Elaboration Negotiation Specification Validation Requirements Management 26

Negotiation Task �During negotiation, the software engineer 27 reconciles the conflicts between what the customer wants and what can be achieved given limited business resources �Requirements are ranked (i. e. , prioritized) by the customers, users, and other stakeholders �Risks associated with each requirement are identified analyzed �Rough guesses of development effort are made and used to assess the impact of each requirement on project cost and delivery time �Using an iterative approach, requirements are eliminated, combined and/or modified so that each party achieves some measure of

The Art of Negotiation �Recognize that it is not competition �Map out a strategy �Listen actively �Focus on the other party’s interests �Don’t let it get personal �Be creative �Be ready to commit 28

Inception Elicitation Elaboration Negotiation Specification Validation Requirements Management 29

Specification Task �A specification is the final work product 30 produced by the requirements engineer �It can be written document, mathematical or graphical model, collection of use case scenarios �It is normally in the form of a software requirements specification �It serves as the foundation for subsequent software engineering activities �It describes the function and performance of a computer-based system and the constraints that will govern its development �It formalizes the informational, functional, and behavioral requirements of the proposed

Inception Elicitation Elaboration Negotiation Specification Validation Requirements Management 32

Validation Task � It is an activity in which req. specification is analyzed 33 in order to ensure that the req. are specified unambiguously � During validation, the work products produced as a result of requirements engineering are assessed for quality � The specification is examined to ensure that �all software requirements have been stated unambiguously �inconsistencies, omissions, and errors have been detected and corrected �the work products conform to the standards established for the process, the project, and the product � The formal technical review serves as the primary requirements validation mechanism �Members include software engineers, customers,

Inception Elicitation Elaboration Negotiation Specification Validation Requirements Management 36

Requirements Management Task �It is the process of managing changing requirements during the requirements engineering process and system development. �Why requirements get change? - req. are always incomplete and inconsistent. New req. occur during the process as business needs change and a better understanding of the system is developed - Customers may specify the req. from business perspective that can conflict with end user req. - During the development of the system, its business & the technical environment may get changed 37

Requirement Management Process following things should be planned : Requirement identification Requirements are individually identified Change Management Process plan followed when analyzing a req. change Traceability Policies The amount of information about req. relationship is maintained Case tool Support The tool support which is required to manage req. changes

Requirement Engineering Processes � Is process in which various activities such as discovery, analysis, validation are done. � Begins with feasibility study � Ends with req. validation � Finally a document is prepared � This process is a 3 stage activity, in which activities are arranged in iterative manner � Generic activities: 1. Req. Elicitation 2. Req. Analysis 3. Req. Validation 4. Req. Management

Requirement Engineering Processes Feasibility study Req. Elicitation & Analysis Feasibility Report System Models Req. Specificatio n Req. Validation User & Sys. Req. Doc.

Spiral Model of Req. Eng. Process

Cont. . �It can also be viewed as structured analysis method �Along with creation of system models some additional information

Requirement Specification �S/w Req. Document is the specification of the system �Should include both a definition & a specification of req. �Not a design document �It is the set of what the system should do rather than how it should do �Provide a basis for creating the Software Requirement Specification (SRS)

SRS �Use: - In estimating cost - Planning team activities - Performing tasks - Tracking team progress �s/w designers use IEEE STD 830 -1998 as the basis for S/w Spec.

Software Requirements Specification Who needs the SRS and for what purpose? �Users, customers and marketing personnel �SRS will meet their needs �Software developers �Develop the exact functionality which is specify in SRS document �Test engineers �SRS provide meaningful functionality for making test templates. �User documentation writers �Understand the SRS documents well enough to be able to write user’s manual. �Project managers �Estimate the cost easily and planning

Software Requirements Specification � SRS document should clearly document the following aspects of a system: �Functional requirement �Non functional requirement �Goals of implementation � Functional requirement �High level functional requirements �Sub requirements � Non functional requirement �This include aspects concerning maintainability, portability and usability. �Also include reliability issues, accuracy of results, humancomputer interfaces issues. � Goals of implementation �Give some general suggestions regarding development.

Characteristics of a good SRS documents �Concise �The SRS document is to the point at the same time unambiguous, consistent and complete. Irrelevant description reduce reliability and increase error in srs. �Structured �The SRS document should be well structured. �Black-box view �The SRS should specify the externally visible behavior of the system. �Conceptual integrity �The SRS document should exhibit conceptual integrity so that the reader can easily understand the contents. �Verifiable �Whether or not requirements have been met in an implementation.

Organization of the SRS document �Depends on system analysist �Depends on Project type �Depends on company polices and rules �So SRS document is always differ organization to organization.

Software Requirements Specification Format 1. Introduction 1. 1 Purpose 1. 2 Scope 1. 3 Definitions, Acronyms and Abbreviations 1. 4 References 2. Overall Description 2. 1 Product Perspective 2. 2 Product Features 2. 3 User classes 2. 4 operating environment 2. 5 Design and Implementations constraints 2. 6 Assumptions and dependencies

Cont. . 3. System Features 3. 1 System feature 1 3. 2 System Feature 2 (and so on) 4. External Interface Requirements 4. 1 User Interface 4. 2 H/w interface 4. 3 s/w interface 4. 4 Communication Interface 5. Other Nonfunctional Requirements 5. 1 Performance Requirements 5. 2 Safety Requirements 5. 3 Security Requirements 5. 4 SQA 6. Other Requirements

Introduction. �The following subsections of the Software Requirements Specifications (SRS) document should provide an overview of the entire SRS. The thing to keep in mind as you write this document is that you are telling what the system must do – so that designers can ultimately build it. Do not use this document for design!!!

Purpose �Identify the purpose of this SRS and its intended audience. In this subsection, describe the purpose of the particular SRS and specify the intended audience for the SRS.

Scope �In this subsection: � Identify the software product(s) to be produced by name � Explain what the software product(s) will, and, if necessary, will not do � Describe the application of the software being specified, including relevant benefits, objectives, and goals � Be consistent with similar statements in higherlevel specifications if they exist �This should be an executive-level summary. Do

Definitions, Acronyms, and Abbreviations. �Provide the definitions of all terms, acronyms, and abbreviations required to properly interpret the SRS. This information may be provided by reference to one or more appendices in the SRS or by reference to documents. This information may be provided by reference to an Appendix.

References �In this subsection: �(1) Provide a complete list of all documents referenced elsewhere in the SRS �(2) Identify each document by title, report number (if applicable), date, and publishing organization �Specify the sources from which the references can be obtained.

SRS Example

Library Management System �In word document

Hospital management system

1. Introduction � The SRS is produced at the culmination of the analysis task. The function and performance allocated to software as part of the system engineering and refined by establishing a complete information description, a detailed functional description, a representation of system behavior, indication of performance requirements and design constrains, appropriate validation criteria and the other information related to requirements.

�The SRS is technical specification of requirement of Hospital Management system. This specification describes what the proposed system should do without describing how it will do it. It also describes complete external behavior of proposed system.

1. 1. Purpose: �The main purpose of our system is to make hospital task easy and is to develop software that replaces the manual hospital system into automated hospital management system. This document serves as the unambiguous guide for the developers of this software system.

1. 2. Scope: �The document only covers the requirement specification for the hospital management system. This document does not provide any references to the other component of the hospital management system. All the external interfaces and the dependencies are also identified in this document.

1. 3. Feasibility Study: �The overall scope of the feasibility study was to provide sufficient information to allow a decision to be made as to whether the hospital management system project should proceed and so, its relative priority in the context of the other existing hospital management system.

� The feasibility study of this project had undergone through various steps which as describe as under: �Identify the origin of the information at different level. �Identify the expectation of user from computerized system. �Analyze the drawback of existing system.

1. 4. Definition, Acronyms, Abbreviations: � CFD: - Context Flow Diagram DFD: - Data Flow Diagram � IDE: - Integrated Development Environment �Java: Platform. Independent, Object_orientedprogrammi ng language � SQL: - Structured Query Language � SRS: - Software Requirement Specification. �

1. 5. Reference: � 1) An integrated approach to software engineering, Third edition by Pankaj jalote � 2) Java – Balaguruswamy � 3) SQL server 2005 – Joseph. L Jordan

1. 6. Overview: �Hospital Management System is a process of implementing all the activities of the hospital in a computerized automated way to fasten the performance. � This project is to maintain the patient details, lab reports and to calculate the bill of the patient. You can also manually edit any patient details and issue bill receipt to

2. OVERALL DESCRIPTION 2. 1. Product perspectives: �This project gives the procedural approach how a patient gets treatment, details about date of treatment and finally depending on different criteria like room allocated, lab reports, treatment and medicine taken…. . etc, how billing is calculated. During billing health card facility is also considered.

2. 2. Product Function: �The data represented in hospital management application will perform the following major function: �Patient Details: - It includes inpatient and outpatient details. �Lab reports �Billing Details �This software will help to calculate the bill much quicker and simpler way. This enables the organization to keep the information in efficient and systematic way.

2. 3. User Characteristics: �This software is developed such that total appearance of the product to make it more user friendly. The operator will be provided with loginid and password. General users with basic computer skills can use this software.

2. 4. General Constraints: �Any update regarding the patients information from the hospital are to be recorded to have updated and correct values.

2. 5. Assumption and Dependencies: �All the data entered will be correct and up_to_date. This software package is developed using java as front end which is supported by sun micro system, MS SQL server 2005 as the back end which is supported by Microsoft windows xp.

3. SPECIFIC REQUIREMENTS �It describes all the details that the software developer need to know for designing and developing the system. This is typically the largest and most important part of the document.

3. 1. External Interface Requirements: 3. 1. 1. User Interface: �User interface is designed in a user friendly manner and the user, in another end he has to give the order, for that he will interface with keyboard and mouse.

3. 1. 2. Hardware Interface: � 1) OS – windows XP � 2) Hard disk – 80 GB � 3) RAM – 1 GB � 4) Keyboard – Standard QWERTY keyboard for interface � 5) Mouse – Standard mouse with 2 buttons

3. 1. 3. Software Interface: � 1) Front end – Java language � 2) OS – Net Beans IDE 6. 9. 1 � 3) Back end – SQL Server 2005

3. 1. 4. Communication Interface: �Windows �Linux

3. 2. Functional Requirements: 3. 2. 1. Administration module: �This module enables the user to insert, update, view and delete the patient information.

3. 2. 2. Patient module: �Patient. Id, Name, Age, Sex, Address, Phone Number, Weight � This module has following 2 sub modules: -

3. 2. 2. 1. Inpatient module: � This sub module is used to store information about patients who were admitted in the hospital on doctors advice. �Patient. Id, Dept depending on disease, Doctor, Room no, Date of admitted, Advance, Date of discharge. �Updation like deletion and modification is done.

3. 2. 2. 2. Outpatient module: �Patient. Id, New_Case, Old_Case, Date, Dept dependingon disease, Doctor. �Updation like deletion and modification is done

3. 2. 3. Lab module: �This module used to store or produce the laboratory reports. �Patient. Id, Weight, Category, Doctor, Inpatient/Outpatient, Date. �Updation like deletion and modification is done.

3. 2. 4. Billing module: 3. 2. 4. 1. Inpatient module: �Patient. Id, doctors charge, health card amount, room bill, medicine bill, total amount, No of days, Service charge, Operation theatre, Nursing care, Lab bill.

3. 3. Performance Requirements: �The capability of the computer depends on the performance of the software. The software can take any number of input provided the database size is large enough. This would depend on the available memory space.

3. 4. Design Constraints: �This will help the doctors or users to view the records of the patients immediately whenever necessary. They can also calculate the bill of the particular patients. This software also has the ability to add, update and delete the record whenever needed. This project will help to smoother the process of the hospital activites.

Requirement Validation �It is a process in which it is checked that whether the gathered requirements represent the same system that customer really wants �In this the req. errors are fixed �Req. Error cost are high so validation is very important. �Fixing a req. error after delivery may cost upto 100 times the cost of fixing an implementation errors.

Cont. . �Req. checking can be done in following manner – 1. validity: does the system provide the function which best support the customer’s needs? 2. Consistency: are there any req. conflicts? 3. Completeness: Are all functions required by the customer? 4. Realism: can the requirements be implemented according to budget and technology?

Req. validation Techniques 1. Requirements Reviews: is a systematic manual - - analysis of the requirements. The req. review should be taken only after formulation of req. definition. And both the customer and contactor staff should be involved in reviews Reviews may be formal (with completed documents) or informal Good communications should take place between developers, customers and users Such a healthy communication helps to resolve problems at an early stage

Cont. . Requireme nts reviews Test Case generati on Requireme nts Validation technique Prototypin g

Cont… 2. Prototyping - The req. can be checked using executable model of system 3. Test case generation - In this technique, the various tests are developed for requirement. - The requirement check can be carried out with: 1. Verifiability : is the req. realistically testable? 2. Comprehensibility: is the req. properly understood? 3. Traceability: is the origin of the req. clearly tested?

Requirement Analysis �After req. elicitation, the req. analysis is done �Following are some principles that must be used while using analysis methods 1. It is necessary to understand the information domain of the problem because of which goals and objectives of the system can be well understood. 2. Various functions that can be performed by the software must be defined 3. Behavior of the s/w must be represented 4. The data, functions and behavioral models should depict the information in layered manner, so that all the necessary information can be systematically exploited 5. the analysis method should proceed in such a way that necessary information can be easily

Modeling �It is used to represent the actual entity so that its functionality can be understood properly �Any s/w model must be capable of representing information of the s/w that gets transformed within it, functions & behavior.

Types of modeling �Based on req. analysis 2 types of models are there: 1. Functional model 2. Behavioral model

1. Functional model �Used to represent the flow of information in any computer based system �Used to represent 3 generic functionalities: input, process, output �When functional model is prepared the s/w engineer focuses on problem specific functions �The basic model is prepared and over the series of iterations more and more functional details are provided. �In structured analysis approach the

2. Behavioral Model �Used to describe the overall behavior of a system �The state transition diagram are used �The state transition diagram: - Basically a collection of states and events - The events cause the system to change its state - What actions are to be taken on occurrence of particular event