1. Unit-III Requirements Engineering
Requirements Engineering Tasks
Initiating the process
Eliciting Requirements
Developing Use-Cases
Building Analysis Model:
Requirements Analysis
Data Modeling Concepts
Object-Oriented Analysis
Scenario-Based Analysis
Flow-Oriented Modeling
Class-Based Modeling
Creating a Behavioral Model
Prof.Deshmukh Santosh S. (MCA SIT)

2. Prof.Deshmukh Santosh S. (MCA SIT)
Requirements engineering provides the appropriate mechanism for understanding what the customer wants, analyzing need, assessing feasibility, negotiating a reasonable solution, specifying the solution unambiguously, validating the specification, and managing the requirements as they are transformed into an operational system.
The requirements engineering process can be described in five distinct steps…..
Requirements Elicitation
Requirements Analysis And Negotiation
Requirements Specification
System Modeling
Requirements Validation
Requirements Management
Prof.Deshmukh Santosh S. (MCA SIT)

3. Prof.Deshmukh Santosh S. (MCA SIT)
Requirements Elicitation :
To ask the customer, the users, and others
what the objectives for the system or product are ?
what is to be accomplished ?
how the system or product fits into the needs of the business ?
To identify a number of problems that help us understand why requirements elicitation is difficult:
Why is it so difficult to gain a clear understanding of what the customer wants?
Problems of scope:
The boundary of the system is ill-defined or the customers/
users specify unnecessary technical detail that may confuse, rather than clarify, overall system objectives.
Prof.Deshmukh Santosh S. (MCA SIT)

4. Prof.Deshmukh Santosh S. (MCA SIT)
Problems of understanding:
The customers/users are not completely sure of what is needed, have a poor understanding of the capabilities and limitations of their computing environment, don’t have a full understanding of the problem domain
Problems of volatility :
The requirements change over time.
To help overcome these problems, system engineers must approach the requirements gathering activity in an organized manner.
Assess the business and technical feasibility for the proposed system.
Identify the people who will help specify requirements and understand their organizational bias.
Prof.Deshmukh Santosh S. (MCA SIT)

5. Prof.Deshmukh Santosh S. (MCA SIT)
Define the technical environment (e.g., computing architecture, operating system, telecommunications needs) into which the system or product will be placed.
Prof.Deshmukh Santosh S. (MCA SIT)

6. Prof.Deshmukh Santosh S. (MCA SIT)
Software requirements engineering is a process of discovery, refinement, modeling, and specification.
The system requirements and role allocated to software—initially established by the system engineer—are refined in detail.
Models of the required data, information and control flow, and operational behavior are created.
Requirements engineering is the systematic use of proven principles, techniques, languages, and tools for the cost effective analysis, documentation, and on-going evolution of user needs and the specification of the external behavior of a system to satisfy those user needs.
software engineer and customer take an active role in software requirements engineering—a set of activities that is often referred to as analysis
Prof.Deshmukh Santosh S. (MCA SIT)

7. Prof.Deshmukh Santosh S. (MCA SIT)
Requirements analysis is a software engineering task that bridges the gap between system level requirements engineering and software design.
Software requirements analysis may be divided into five areas of effort:
(1) Problem Recognition,
(2) Evaluation And Synthesis,
(3) Modeling,
(4) Specification,
(5) Review.
System Engineering
System
Requirement
Analysis.
System
design
Prof.Deshmukh Santosh S. (MCA SIT)

8. Prof.Deshmukh Santosh S. (MCA SIT)
Requirements Elicitation :
Before requirements can be analyzed, modeled, or specified they must be gathered through an elicitation process.
A customer has a problem that may be agreeable to a computer-based solution.
Initiating the Process :
The most commonly used requirements elicitation technique is to conduct a meeting or interview.
The first meeting between a software engineer (the analyst) and the customer can be likened to the embarrassment of a first date between two teenagers.
communication must be initiated.
A set of questions that will lead to a basic understanding of the problem, the people who want a solution, the nature of the solution that is desired, and the effectiveness of the first encounter itself.
Prof.Deshmukh Santosh S. (MCA SIT)

9. Prof.Deshmukh Santosh S. (MCA SIT)
The requirements gathering that is applied during early stages of analysis and specification called Facilitated Application Specification Techniques (FAST).
This approach encourages the creation of a joint team of customers and developers who work together to identify the problem, propose elements of the solution, negotiate different approaches and specify a preliminary set of solution requirements.
Many different approaches to FAST have been proposed
A meeting is conducted at a neutral site and attended by both software engineers and customers.
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“ controls the meeting.
Prof.Deshmukh Santosh S. (MCA SIT)

10. Prof.Deshmukh Santosh S. (MCA SIT)
Quality Function Deployment :
Quality function deployment (QFD) is a quality management technique that translates the needs of the customer into technical requirements for software.
QFD highlights an understanding of what is valuable to the customer and then deploys these values throughout the engineering process.
QFD identifies three types of requirements.
Normal requirements
The objectives and goals that are stated for a product or system during meetings with the customer.
If these requirements are present, the customer is satisfied.
Expected requirements:
These requirements are implicit to the product or system and may be so fundamental that the customer does not explicitly state them.
Prof.Deshmukh Santosh S. (MCA SIT)

11. Prof.Deshmukh Santosh S. (MCA SIT)
Exciting requirements:
These features go beyond the customer’s expectations and prove to be very satisfying when present.
In meetings with the customer, function deployment is used to determine the value of each function that is required for the system.
Information deployment identifies both the data objects and events that the system must consume and produce.
Task deployment examines the behavior of the system or product within the context of its environment.
QFD uses customer interviews and observation, surveys, and examination of historical data (e.g., problem reports) as raw data for the requirements gathering activity.
Prof.Deshmukh Santosh S. (MCA SIT)

12. Prof.Deshmukh Santosh S. (MCA SIT)
Developing Use-Cases :
As requirements are gathered as part of informal meetings, FAST, or QFD, the software engineer (analyst) can create a set of scenarios that identify a thread of usage for the system to be constructed.
To create a use-case, the analyst must first identify the different types of people (or devices) that use the system or product.
These actors actually represent roles that people (or devices) play as the system operates.
An actor is anything that communicates with the system or product and that is external to the system itself.
It is important to note that an actor and a user are not the same thing.
A typical user may play a number of different roles when using a system, whereas an actor represents a class of external entities (often, but not always, people) that play just one role.
Prof.Deshmukh Santosh S. (MCA SIT)

13. Prof.Deshmukh Santosh S. (MCA SIT)
In general, a use-case is simply a written story that describes the role of an actor as interaction with the system occurs.
Each use-case provides an unambiguous scenario of interaction between an actor and the software.
Use-cases describe scenarios that will be supposed differently by different actors.
Prof.Deshmukh Santosh S. (MCA SIT)

14. Prof.Deshmukh Santosh S. (MCA SIT)
Building Analysis Model :
Requirements analysis is the first technical step in the software process.
It is at this point that a general statement of software scope is refined into a concrete specification that becomes the foundation for all software engineering activities that follow.
Analysis must focus on the information, functional, and behavioral domains of a problem.
To better understand what is required, models are created, the problem is Software Requirements.
A large number of analysis modeling methods have been developed.
Prof.Deshmukh Santosh S. (MCA SIT)

15. Prof.Deshmukh Santosh S. (MCA SIT)
Data Modeling Concepts :
Structured analysis, a widely used method of requirements modeling, relies on data modeling and flow modeling to create the basis for a comprehensive analysis model.
Using entity-relationship diagrams, the software engineer creates a representation of all data objects that are important for the system.
Data and control flow diagrams are used as a basis for representing the transformation of data and control.
Data design creates a model of data and/or information that is represented at a high level of abstraction.
This data model is then refined into progressively more implementation-specific representations that can be processed by the computer-based system
Prof.Deshmukh Santosh S. (MCA SIT)

16. Prof.Deshmukh Santosh S. (MCA SIT)
Object-Oriented Analysis :
The objective of object-oriented analysis is to develop a model that describes computer software as it works to satisfy a set of customer-defined requirements.
To perform object-oriented analysis, a software engineer should perform the following generic steps:
1. Elicit customer requirements for the system.
2. Identify scenarios or use-cases.
3. Select classes and objects using basic requirements as a guide.
4. Identify attributes and operations for each system object.
5. Define structures and hierarchies that organize classes.
6. Build an object-relationship model.
7. Build an object-behavior model.
8. Review the OO analysis model against use-cases or scenarios.
Prof.Deshmukh Santosh S. (MCA SIT)

17. Prof.Deshmukh Santosh S. (MCA SIT)
The Object-oriented (OO) methodology consists of Object-oriented Analysis (OOA) and Object-oriented Design (OOD).
In OOA, object-modeling techniques are applied to analyze the functional requirements of a system.
In OOD, the analysis models are elaborated to produce implementation specifications.
OOA focuses on 'what the system does', whereas OOD focuses on 'how the system does it'.
Object-oriented analysis (OOA) is a Software Engineering approach that models a system as a group of interacting objects.
Each object represents some entity of interest in the system being modeled, and is characterized by its class, its state (data elements), and its behavior.
Various models can be created to show the static structure, dynamic behavior, and run-time deployment of these collaborating objects.
Prof.Deshmukh Santosh S. (MCA SIT)

18. Prof.Deshmukh Santosh S. (MCA SIT)
Object-oriented analysis methods enable a software engineer to model a problem by representing both static and dynamic characteristics of classes and their relationships as the primary modeling components.
OO analysis methods, the Unified Modeling Language builds an analysis model that has the following characteristics:
Representation of classes and class hierarchies
Creation of object relationship models, and
Derivation of object-behavior models.
Analysis for object-oriented systems occurs at many different levels of abstraction.
Prof.Deshmukh Santosh S. (MCA SIT)

19. Prof.Deshmukh Santosh S. (MCA SIT)
Object-oriented analysis (OOA) is the process of analyzing a task to develop a conceptual model that can then be used to complete the task.
A typical OOA model would describe computer software that could be used to satisfy a set of customer-defined requirements.
During the analysis phase of problem-solving, the analyst might consider a written requirements statement, a formal vision document.
Prof.Deshmukh Santosh S. (MCA SIT)

20. Prof.Deshmukh Santosh S. (MCA SIT)
Scenario-Based Analysis :
Scenarios are important tools for exercising an architecture in order to gain information about a system’s fitness with respect to a set of desired quality attributes.
A structured method for scenario-based architectural analysis is presented, using scenarios to analyze architectures with respect to achieving quality attributes.
Scenarios are brief narratives of expected or anticipated use of a system from both development and end-user viewpoints.
A structured method employing scenarios to analyze architectures is the Software Architecture Analysis Method (SAAM).
Scenarios have been widely used and documented as a technique during requirements elicitation, especially
with respect to the operator of the system.
Prof.Deshmukh Santosh S. (MCA SIT)

21. Prof.Deshmukh Santosh S. (MCA SIT)
Flow-Oriented Modeling
Prof.Deshmukh Santosh S. (MCA SIT)

22. Prof.Deshmukh Santosh S. (MCA SIT)
Self Learning
What are the factors considered while performing system modeling?
Explain with a suitable example how systems simulation is useful aspect while designing the system.
Explain the following elements of analysis model : Scenario-based elements Behavioral elements.
Describe the primary differences between the structured analysis and object oriented analysis.
Write down on class based modeling?
Explain the process used for creating Behavioral Modeling?
What are the goals of Requirement Engineering? What are the tasks performed in requirement engineering?
Prof.Deshmukh Santosh S. (MCA SIT)

23. Prof.Deshmukh Santosh S. (MCA SIT)
Self Learning
Explain the need of Requirement prioritization? How the requirements are prioritized?
What is the major difference between requirements analysis and requirements validation?
What are the factors considered while performing system modeling? Explain with a suitable example how systems simulation is useful aspect while designing the system. [9]
b) Explain the following elements of analysis model : [8]
i) Scenario-based elements.
ii) Behavioral elements.
Prof.Deshmukh Santosh S. (MCA SIT)