Requirement Engineering Chapter 2. Topics Problem recognition Requirement Engineering Tasks...
Preview:
Citation preview
- Slide 1
- Requirement Engineering Chapter 2
- Slide 2
- Topics Problem recognition Requirement Engineering Tasks
Processes SRS Use cases and Functional specification Requirement
validation Requirement Analysis Modeling and types
- Slide 3
- 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
- Slide 4
- Requirement engineering ? Is the process of Establishing the
services that the customer requirement from system The constraints
under which it operates and is developed
- Slide 5
- 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.
- Slide 6
- 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.
- Slide 7
- Problem Recognition Sys engineeringReq analysisSw design
- Slide 8
- 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
- Slide 9
- 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
- Slide 10
- Role of system analyst What is system analyst ???
- Slide 11
- Cont.. Is a person who starts requirement gathering and
requirement analysis activity by collecting all the information
from the customer.
- Slide 12
- 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 ?
- Slide 13
- 13 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
- Slide 14
- 14 Requirements Management Validation Inception Elicitation
Elaboration Negotiation Specification
- Slide 15
- 15 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
- Slide 16
- 16 Requirements Management Validation Inception Elicitation
Elaboration Negotiation Specification
- Slide 17
- 17 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
- Slide 18
- 18 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
- Slide 19
- 19 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
- Slide 20
- 20 Elicitation Work Products 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 The work
products will vary depending on the system, but should include one
or more of the following items
- Slide 21
- 21 Requirements Management Validation Inception Elicitation
Elaboration Negotiation Specification
- Slide 22
- 22 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
- Slide 23
- 23 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)
- Slide 24
- 24 Questions Commonly Answered by a Use Case Who is the primary
actor(s), the secondary actor(s)? What are the actors 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 actors 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?
- Slide 25
- 25 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
- Slide 26
- 26 Requirements Management Validation Inception Elicitation
Elaboration Negotiation Specification
- Slide 27
- 27 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
- Slide 28
- 28 The Art of Negotiation Recognize that it is not competition
Map out a strategy Listen actively Focus on the other partys
interests Dont let it get personal Be creative Be ready to
commit
- Slide 29
- 29 Requirements Management Validation Inception Elicitation
Elaboration Negotiation Specification
- Slide 30
- 30 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
- Slide 31
- 31 Typical Contents of a Software Requirements Specification
Requirements 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
- Slide 32
- 32 Requirements Management Validation Inception Elicitation
Elaboration Negotiation Specification
- Slide 33
- 33 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
- Slide 34
- 34 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)
- Slide 35
- 35 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?
- Slide 36
- 36 Requirements Management Validation Inception Elicitation
Elaboration Negotiation Specification
- Slide 37
- 37 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
- Slide 38
- Requirement Management Process following things should be
planned : Requirement 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
- Slide 39
- 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
- Slide 40
- Requirement Engineering Processes Feasibility study Req.
Elicitation & Analysis Req. Validation Req. Specification
Feasibility Report System Models User & Sys. Req. Req.
Doc.
- Slide 41
- Spiral Model of Req. Eng. Process
- Slide 42
- Cont.. It can also be viewed as structured analysis method
Along with creation of system models some additional
information
- Slide 43
- 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)
- Slide 44
- 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.
- Slide 45
- 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 users manual. Project managers Estimate the cost
easily and planning Maintenance engineers Understand the
functionality, design and coding.
- Slide 46
- 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, human-computer interfaces
issues. Goals of implementation Give some general suggestions
regarding development.
- Slide 47
- 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.
- Slide 48
- 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.
- Slide 49
- 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
- Slide 50
- 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
- Slide 51
- 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!!!
- Slide 52
- 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.
- Slide 53
- 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.
- Slide 54
- 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.
- Slide 55
- 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.
- Slide 56
- SRS Example
- Slide 57
- Library Management System In word document
- Slide 58
- Hospital management system
- Slide 59
- 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.
- Slide 60
- 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.
- Slide 61
- 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.
- Slide 62
- 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.
- Slide 63
- 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.
- Slide 64
- 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.
- Slide 65
- 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.
- Slide 66
- 1.5. Reference:- 1) An integrated approach to software
engineering, Third edition by Pankaj jalote 2) Java Balaguruswamy
3) SQL server 2005 JosephL Jordan
- Slide 67
- 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.
- Slide 68
- 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.
- Slide 69
- 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.
- Slide 70
- 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.
- Slide 71
- 2.4. General Constraints:- Any update regarding the patients
information from the hospital are to be recorded to have updated
and correct values.
- Slide 72
- 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.
- Slide 73
- 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.
- Slide 74
- 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.
- Slide 75
- 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
- Slide 76
- 3.1.3. Software Interface:- 1) Front end Java language 2) OS
Net Beans IDE 6.9.1 3) Back end SQL Server 2005
- Slide 77
- 3.1.4. Communication Interface:- Windows Linux
- Slide 78
- 3.2. Functional Requirements:- 3.2.1. Administration module:-
This module enables the user to insert, update, view and delete the
patient information.
- Slide 79
- 3.2.2. Patient module:- PatientId,Name,Age,Sex,Address,Phone
Number,Weight This module has following 2 sub modules:-
- Slide 80
- 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. PatientId, Dept depending on disease, Doctor, Room
no, Date of admitted, Advance, Date of discharge. Updation like
deletion and modification is done.
- Slide 81
- 3.2.2.2. Outpatient module:-
PatientId,New_Case,Old_Case,Date,Deptdependin gon disease,Doctor.
Updation like deletion and modification is done
- Slide 82
- 3.2.3. 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.
- Slide 83
- 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.
- Slide 84
- 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.
- Slide 85
- 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.
- Slide 86
- 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.
- Slide 87
- Cont.. Req. checking can be done in following manner 1.
validity: does the system provide the function which best support
the customers 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? 5. Verifiability: can the requirements be
checked?
- Slide 88
- 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
- Slide 89
- Cont.. Test Case generation Requirements Validation technique
Requirements reviews Prototyping
- Slide 90
- 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? 4. Adaptability: can the req. be changed without a large
impact on their req.?
- Slide 91
- 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 transformed into implementation
- Slide 92
- 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.
- Slide 93
- Types of modeling Based on req. analysis 2 types of models are
there: 1. Functional model 2. Behavioral model
- Slide 94
- 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
- Slide 95
- 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