Professional Documents
Culture Documents
Chapter 3
Requirement Engineering Process
Chapter 4
Requirements Elicitation and Analysis
Objectives
Use Case
Model
Cont.
Expressed in
terms of
Expressed in Structured
terms of by
Implemented by
Expressed in Structured Realized by
terms of by
class...
class...
class...
Use Case Application Solution
Domain Sub- Source
Model Domain
Objects systems Code
Objects
Cont.
Implemented by
Expressed in Structured Realized by Verified
terms of by
By
class...
class... ?
class... ?
class....
Use Case Application Solution
Domain Sub- Source Test
Model Domain
Objects systems Code Cases
Objects
Cont.
Implemented
Expressed in By
Structured By Realized By
Terms Of Verified
By
class...
class...
class... ?
class.... ?
Use Case Application Solution
Domain Subsystems Source Test
Model Domain
Objects Code Cases
Objects
Components of requirements elicitation
• Application domain understanding :
• Application domain knowledge is
knowledge
Problem
Business of
Stakeholder
Application
to the
Domain
be solved
context
Needs and constraints
general area
where the system is applied.
• Example 1 : understand the
requirements for a cataloguing
system, you must have a general
knowledge of libraries and how
libraries work.
• Example 2 : understand the
requirements for a railway
signaling system, you must have
a background knowledge about
the operation of railways and the
physical characteristics of trains.
Components of requirements elicitation
• Problem understanding:
• The details of the specific customer
problem where
Stakeholder
Application
Problem
Business the system will be
to context
Domain
be solved
Needs and constraints
applied must be understood.
• Example 1 : for a cataloguing
system, you must understand how
a particular library categorizes its
collection.
• Example 2 : for a railway signaling
system, you must know the way in
which speed limits are applied to
particular track segments.
• During problem understanding, you
specialize and extend general
domain knowledge.
Components of requirements elicitation
• Business understanding: You
must understand how systems
interactProblemand
Stakeholder
Application
Businessto context
Domain contribute to
be solved
overallNeeds and constraints
business goals.
• Understanding the needs and
constraints of system
stakeholders:
• You must understand, in detail,
the specific needs of people who
require system support in their
work.
1.The good requirements elicitation process-Elicitation stages
• Necessity checking:
• Sometimes requirements don’t contribute to the business goals of the
organization or to the specific problem to be addressed by the system.
• Consistency and completeness checking:
• Cross-checking for consistency and completeness (no contradictions, no
services or constraints are missed out).
• Feasibility checking:
• the context of the budget and schedule.
Requirements negotiation
• Requirements discussion:
• Requirements highlighted as problematical are discussed.
• The stakeholders involved present their views about the requirements.
• Requirements prioritization:
• Identification of critical requirements.
• Requirements agreement:
• A compromised set of requirements are agreed.
• A changes to some of the requirements.
2. Elicitation techniques
• Specific techniques which may be used to collect knowledge
about system requirements.
• This knowledge must be structured:
• Partitioning - aggregating related knowledge.
• Abstraction - recognizing generalities.
• Projection - organizing according to perspective.
• Elicitation problems:
• Not enough time for elicitation.
• Insufficient preparation by engineers.
• Stakeholders are unconvinced of the need for a new
system.
Specific elicitation techniques
1. Review of Literature
• All documentation on data carriers (forms, records, report, manuals
etc.) are organized and evaluated as and when available.
• Regarding the existing forms, the analyst needs to find out
• How they are filled out
• How useful they are to the user
• What changes need to be made
• How easy they are to read.
• Up to-date manuals saves information gathering time
• Search the literature through
• Professional reference & procedures , Manuals, books, Company
• studies, Government publications etc.
• Procedures, manuals and forms are useful sources for the analyst. They
describe the format and functions of the present system.
• For example
• A S/W Eng.. has to analyze the grade report and he has to find out how the
grades were calculated, similarly an analyst has to find out rules, policies
and procedures related to grade report.
2. Onsite observations / Direct observation
• It requires going to user area & may cause adverse reactions by the user staff
if not handled properly.
• It is time- consuming
• OBJECTIVE of on site observation is to get as close as possible to the real
system being studied, movement of people & work flow.
Alternative observation methods are
1. Natural : It occurs in the employee’s place of work.
2. Obtrusive : This observation takes place when the user knows that he is
being observed
3. Direct : Takes place when the analyst actually observes the subject or system
at work.
4. Structural :Here the observer looks for & records a specific action.
5. Contrived :It is set up by the observer in a place as laboratory.
6. Unobtrusive :This observation takes place secretly as behind one way mirror.
7. Indirect :Here the analyst uses mechanical devices such as cameras and
video tapes to capture information
3. Questionnaire
• What is a Questionnaire?
• A set of Questions designed to generate the statistical
information from a specific demographic needed to
accomplish the research objectives
The Major Decisions in Questionnaire Design
• Content - What should be asked?
• Wording - How should each question be phrased?
• Sequence - In what order should the questions be
presented?
• Layout - What layout will best serve the research objectives
• FILTER question: that screens out respondents who are not qualified
to answer a second question.
• PIVOT question: a type of filter question that is used to determine
what version of a second question to ask.
• The most difficult step is specifying exactly what
information is to be collected from each respondent
Types of Questionnaires
• 1. Close ended questionnaires
• 2. Open Ended Questionnaires
• Closed Ended Questionnaire
• Here responses/ answers are presented as a set of alternatives.
• Users must select / fill the appropriate alterative & the answer must be
selected from amongst exactly.
• Scoring takes less time when compared.
• There are five major varieties of closed questions. They
are.
• Fill in the Blanks
• Dichotomous (Yes / No type)
• Ranking Scale
• Multiple-Choice
• Rating Scale
Types of Questionnaires…
• Open Ended Questionnaire
• It requires no response direction or specific response
• Users can respond in their own words
• The answer is written in the space provided
• Scoring takes more time to analyze.
• These Questions are ideal in explanatory situations where the new
ideas and relationships are needed An open question is likely to
receive a long answer
• Example:
• If u had a choice, how would you have designed the present
information center?
• ____________________________________________________
____________________________________________________
______________________________________________
Types of Questionnaires…
3. interview
• The requirements engineer or analyst discusses the
system with different stakeholders and builds up an
understanding of their requirements.
• Two Types of interview:
• Closed interviews: The requirements engineer looks
for answers to a pre-defined set of questions.
• Open interviews: There is no predefined agenda and
the requirements engineer discusses, in an open-
ended way, what stakeholders want from the system.
Contd..
• Structured (closed) interviews
• Stakeholders answer a predefined set of questions
• Easy to analyze (+)
• Well-formed questions generate well-formed answers (you have
to know your goals) (+)
• Knowledge about what and how to ask (-)
• Non-structured (open) interviews
• No predefined agenda
• Generating new ideas (experimental, brain storming) (+)
• sometimes hard to handle (dynamics of discussion) (-)
• In practice: mixed interview types are normal
Interviews: Written vs. oral interviews, group vs. single
• Oral interviews:
• possibility to discussion (+)
• interviewer may influence interviewee (-)
• Written interviews
• problems in understanding (-)
• already transcribed, thus easy to analyze (+)
• Interviewing a single person:
• individual opinions (+)
• Interviewing a group of people: -
• Involvement of many perspectives
• Developer need experience to moderate (-)
• Sometimes single or silent opinions are not noticed (-)
• Independent Moderator can mediate between group
Interviewing Tips
• Interviewers should be open-minded, willing to listen to stakeholders and
should not have pre-conceived ideas about the requirements.
• During the interview
• behave professionally, you will receive the same attitude from your
interviewee.
• Take notes of all the necessary information.
• Don’t make the conversation too lengthy
• Do not prepare too many questions to ask.
• The interview paper and minutes are always useful for you and your
successor
• It’s important to open and close the interview carefully
• When opening the interview, try to do it in a trustful, respective way
with your good will.
• When closing the interview, you should recap the main points of the
interview, make arrangement for the following cooperation and
leave the issues open for discussion between both sides.
Interviewing …
• Advantages
• Rich collection of information
• Good for uncovering opinions, feelings, goals, as well as
hard facts
• Can probe in depth, & adapt follow up questions to what the
person tells you
• Disadvantages
• Large amount of qualitative data can be hard to analyze
• Hard to compare different respondents
• Interviewing is a difficult skill to master
4. Requirements reuse
• Reuse involves taking the requirements which have been
developed for one system and using them in a different
system.
• Requirements reuse saves time and effort as reused
requirements have already been analyzed and validated in
other systems.
• Currently, requirements reuse is an informal process but
more systematic reuse could lead to larger cost savings.
• =//=
Reuse possibilities
• Where the requirement is concerned with providing
application domain information.
• Where the requirement is concerned with the style of
information presentation. Reuse leads to a consistency of
style across applications.
• Where the requirement reflects company policies such as
security policies.
4. Requirements analysis
C Requirements-:
• Customer wants and needs;
• Expressed in language understood by the customer.
• Write C-requirements, review with customer, and update when
necessary.
• They are expressed using…..
• Use cases with a use case diagram. A use case specifies a collection of
scenarios.
• Data flow diagram explains the flow of data items across various
functions. Useful for explaining system functions.
• State transition diagram explains the change of system state in
response to one or more operations.
C and D Requirements
D Requirements
• For the developers; may be more formal.
• Obtain D-requirements from C-requirements and
customer.
• Write D-requirements; check to make sure that there
is no inconsistency between the C and the D
requirements.
• Organize the D-requirements. as Functional, Non
Functional
• Create sequence diagrams for use cases:
• Outline test plans
• Inspect
• Validate with customer & Release
The Requirements Model
What Is System Behavior?
• System behavior is how a system acts and reacts.
• It is the visible and testable activity of a system
• System behavior is captured by use cases.
• The most important aspect is to capture the dynamic behavior.
• Dynamic behavior means the behavior of the system when it is
running/operating.
What Is a Use-Case Model?
• A model that describes a system’s functional
requirements in terms of use cases
• Represents
– system’s intended functionality (use cases) and
– its environment (actors)
Purposes of use case diagrams
• Used to gather the requirements of a system.
• Used to get an outside view of a system.
• Identify the external and internal factors influencing the system.
• Show the interaction among the requirements are actors.
• When we are planning to draw a use case diagram, we should have
the following items identified.
• Functionalities to be represented as use case
• Actors
• Relationships among the use cases and actors.
• Use case diagrams are drawn to capture the functional requirements
of a system.
What Is an Actor?
• Actors are not part of the system. Actors are EXTERNAL.
• Actors represent roles a user of the system can play.
• An actor represents anything that interacts with the system
• They can represent a human, a machine, or another system.
• They can actively interchange information with the system.
• They can be a giver of information.
• They can be a passive recipient of information.
• Useful Questions in Finding Actors?
• Who will supply, use, or remove information?
• Who will use this functionality?
• Who is interested in a certain requirement?
• Where in the organization is the system used?
• What are the system’s external resources?
• What other systems will need to interact with this one?
What is an Use case.
• A use case is
– a sequence of actions a system
performs that yields an observable
result of value to a particular actor.
• Use Cases and Actors
• A use case model: a dialog between actors and the system.
• A use case is initiated by an actor to invoke a certain functionality in
the system.
• guidelines to draw an efficient use case diagram
• The name of a use case is very important. The name should be
chosen in such a way so that it can identify the functionalities
performed.
• Give a suitable name for actors.
• Show relationships and dependencies clearly in the diagram.
• Do not try to include all types of relationships, as the main purpose
of the diagram is to identify the requirements.
• Use notes whenever required to clarify some important points.
E.g. diagram representing the order management system. Hence, if
we look into the diagram then we will find three use cases
(Order, SpecialOrder, NormalOrder) actor which is the customer.
The SpecialOrder and NormalOrder =>extended from Order use case.
System boundary, which is shown in the picture.
The actor Customer lies outside the system as it is an external user of
the system.
use-case diagram Rules
use-case diagram Rules
use-case diagram Rules
UML Class Diagram
Class diagram is a static diagram. It represents the static
view of an application.
Class diagram is not only used for visualizing, describing,
and documenting different aspects of a system but also for
constructing executable code of the software application.
Class diagram describes the attributes and operations of a
class and also the constraints imposed on the system.
The class diagrams are widely used in the modeling of
object oriented systems because they are the only UML
diagrams, which can be mapped directly with object-
oriented languages.
UML Class Diagram components
•The main symbols shown in class diagrams are:
•Class: A class represents the blueprint (template) of its
objects.
•Fields (Attributes, Variables or Constants)
•A field represents the state of the class and its instances.
•Behavior (Operations or Methods)
•A behavior represents an operation performed by the class
and its instances.
•Associations
•An association represents a relationship between two
classes.
•Generalizations
•A generalization groups classes into an inheritance hierarchy.
Contd..
• The following points should be remembered while drawing a class diagram −
• The name of the class diagram should be meaningful to describe the
aspect of the system.
• Each element and their relationships should be identified in advance.
• Responsibility (attributes and methods) of each class should be clearly
identified
• For each class, minimum number of properties should be specified, as
unnecessary properties will make the diagram complicated.
• Use notes whenever required to describe some aspect of the
diagram. At the end of the drawing it should be understandable to the
developer/coder.
• Finally, before making the final version, the diagram should be drawn
on plain paper and reworked as many times as possible to make it
correct.
Eg. Order Management
• First of all, Order and Customer are identified as the two
elements of the system.
• They have a one-to-many relationship because a customer
can have multiple orders.
• Order class is an abstract class and it has two concrete
classes (inheritance relationship) SpecialOrder and
NormalOrder.
• The two inherited classes have all the properties as the
Order class.
• In addition, they have additional functions like dispatch ()
and receive ().
Eg. Order Management
UML Representation of Classes
• A class is simply represented as a box with the name of the class inside.
• The diagram may also show the attributes and/or operations (fields and
behaviour).
* 1..*
Secretary Manager
Company BoardofDirectors
0..1 *
Office Employee
0, 3..8 *
Person BoardofDirectors
LEGEND
x..* (the range from x to many).
x..y (the range from x to y).
Each association can be labelled, to make explicit
the nature of the association:
Association Association
Role Association Name Role
Class1 Class2
* Works for →
Employee Company
Company BoardofDirectors
0..1 isAllocated *
Office Employee
0, 3..8 isMember *
Person BoardofDirectors
Contd..
* Works for →
Employee Company
Many-to-one
– A company has many employees.
– An employee can only work for one company.
• This system is not capable of processing information about more
than one company per employee.
* 1..*
Secretary Manager
Many-to-many
– A secretary can work for many managers.
– A manager can have many secretaries.
– Secretaries can work in pools.
– Managers can have a group of secretaries.
– Some managers might have zero secretaries.
– It is not possible for a secretary to have zero managers.
Contd..
Company BoardofDirectors
One-to-one
0, 3..8 isBoardMember *
Person BoardofDirectors
Many-to-many