Requirement Engineering

Requirement Engineering
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. User – collection of statement written for customer.
System – structured document gives detailed description. Contract between client and contractor. 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 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

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 3. Establish effective communication between the customer and the developer

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

Basic Guidelines of Collaborative Requirements Gathering
Meetings are conducted and attended by both software engineers, customers, and other interested stakeholders Rules for preparation and participation are established An agenda is suggested that is formal enough to cover all important points but informal enough to encourage the free flow of ideas A "facilitator" (customer, developer, or outsider) controls the meeting A "definition mechanism" is used such as work sheets, flip charts, wall stickers, electronic bulletin board, chat room, or some other virtual forum The goal is to identify the problem, propose elements of the solution, negotiate different approaches, and specify a preliminary set of solution requirements

Quality Function Deployment
This is a technique that translates the needs of the customer into technical requirements for software It emphasizes an understanding of what is valuable to the customer and then deploys these values throughout the engineering process through functions, information, and tasks It identifies three types of requirements Normal requirements: These requirements are the objectives and goals stated for a product or system during meetings with the customer Expected requirements: These requirements are implicit to the product or system and may be so fundamental that the customer does not explicitly state them Exciting requirements: These requirements are for features that go beyond the customer's expectations and prove to be very satisfying when present

Elicitation Work Products
The work products will vary depending on the system, but should include one or more of the following items A statement of need and feasibility A bounded statement of scope for the system or product A list of customers, users, and other stakeholders who participated in requirements elicitation A description of the system's technical environment A list of requirements (organized by function) and the domain constraints that apply to each A set of preliminary usage scenarios (in the form of use cases) that provide insight into the use of the system or product under different operating conditions Any prototypes developed to better define requirements

Elaboration Task The information about the requirements is expanded 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 the problem

Developing Use Cases Step One – Define the set of actors that will be involved in the story Actors are people, devices, or other systems that use the system or product within the context of the function and behavior that is to be described Actors are anything that communicate with the system or product and that are external to the system itself Step Two – Develop use cases, where each one answers a set of questions (More on next slide)

Questions Commonly Answered by a Use Case
Who is the primary actor(s), the secondary actor(s)? What are the actor’s goals? What preconditions should exist before the scenario begins? What main tasks or functions are performed by the actor? What exceptions might be considered as the scenario is described? What variations in the actor’s interaction are possible? What system information will the actor acquire, produce, or change? Will the actor have to inform the system about changes in the external environment? What information does the actor desire from the system? Does the actor wish to be informed about unexpected changes?

Elements of the Analysis Model
Scenario-based elements Describe the system from the user's point of view using scenarios that are depicted in use cases and activity diagrams Class-based elements Identify the domain classes for the objects manipulated by the actors, the attributes of these classes, and how they interact with one another; they utilize class diagrams to do this Behavioral elements Use state diagrams to represent the state of the system, the events that cause the system to change state, and the actions that are taken as a result of a particular event; can also be applied to each class in the system Flow-oriented elements Use data flow diagrams to show the input data that comes into a system, what functions are applied to that data to do transformations, and what resulting output data are produced

Negotiation Task During negotiation, the software engineer 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 and 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 satisfaction

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

Specification Task A specification is the final work product 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 software in both a graphical and textual format

Typical Contents of a Software Requirements Specification
Required states and modes Software requirements grouped by capabilities (i.e., functions, objects) Software external interface requirements Software internal interface requirements Software internal data requirements Other software requirements (safety, security, privacy, environment, hardware, software, communications, quality, personnel, training, logistics, etc.) Design and implementation constraints Qualification provisions to ensure each requirement has been met Demonstration, test, analysis, inspection, etc. Requirements traceability Trace back to the system or subsystem where each requirement applies

Validation Task It is an activity in which req. specification is analyzed 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, users, and other stakeholders

Questions to ask when Validating Requirements
Is each requirement consistent with the overall objective for the system/product? Have all requirements been specified at the proper level of abstraction? That is, do some requirements provide a level of technical detail that is inappropriate at this stage? Is the requirement really necessary or does it represent an add-on feature that may not be essential to the objective of the system? Is each requirement bounded and unambiguous? Does each requirement have attribution? That is, is a source (generally, a specific individual) noted for each requirement? (more on next slide)

Questions to ask when Validating Requirements (continued)
Do any requirements conflict with other requirements? Is each requirement achievable in the technical environment that will house the system or product? Is each requirement testable, once implemented? Approaches: Demonstration, actual test, analysis, or inspection Does the requirements model properly reflect the information, function, and behavior of the system to be built? Has the requirements model been “partitioned” in a way that exposes progressively more detailed information about the system?

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

Requirement Management Process following things should be planned :
identification Requirements are individually identified Change Management Process 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: Req. Elicitation Req. Analysis Req. Validation Req. Management

Requirement Engineering Processes
Req. Elicitation & Analysis Feasibility study Feasibility Report Req. Specification Req. Validation System Models User & Sys. Req. 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 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 Maintenance engineers Understand the functionality, design and coding.

Software Requirements Specification
SRS document should clearly document the following aspects of a system: Functional requirement Non functional requirement Goals of implementation High level functional requirements Sub requirements This include aspects concerning maintainability, portability and usability. Also include reliability issues, accuracy of results, human-computer interfaces issues. 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 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 higher-level specifications if they exist This should be an executive-level summary. Do not enumerate the whole requirements list here.

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:-PlatformIndependent,Object_orientedprogramming 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 – JosephL 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 patient within few seconds.

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.

Patient module:- PatientId,Name,Age,Sex,Address,Phone Number,Weight This module has following 2 sub modules:-

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

Outpatient module:- PatientId,New_Case,Old_Case,Date,Deptdependin gon disease,Doctor . Updation like deletion and modification is done

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

3.2.4. Billing module:- 3.2.4.1. Inpatient module:-
PatientId, 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 –
validity: does the system provide the function which best support the customer’s needs? Consistency: are there any req. conflicts? Completeness: Are all functions required by the customer? Realism: can the requirements be implemented according to budget and technology? Verifiability: can the requirements be checked?

Req. validation Techniques
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.. Requirements reviews Requirements Test Validation Case
technique Test Case generation Prototyping

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: Verifiability : is the req. realistically testable? Comprehensibility: is the req. properly understood? Traceability: is the origin of the req. clearly tested? Adaptability: can the req. be changed without a large impact on their req.?

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

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:
Functional model 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 functional modeling is done by using the data flow diagrams

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

Requirement Engineering

Similar presentations

Presentation on theme: "Requirement Engineering"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Requirement Engineering

Similar presentations

Presentation on theme: "Requirement Engineering"— Presentation transcript:

Similar presentations

About project

Feedback