Requirements Elicitation and Analysis
Requirements Elicitation and Analysis
Requirements Elicitation and Analysis
Use Case
Model
Cont.
Expressed in
terms of
Expressed in Structured
terms of by
Expressed in Structured
Realized by
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 of the general area
where the system is applied.
• Example 1 : understand the Application Problem to
requirements for a cataloguing Domain be solved
system, you must have a general
knowledge of libraries and how Stakeholder
Business
libraries work. Needs and
constraints
context
• 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.Interviews.
• 2.Scenarios.
• 3.Observations and social analysis.
• 4.Soft systems methods.
• 5.Requirements reuse.
2.1.Interviews
• 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.
Interviewing essentials-two
• 1.Interviewers must be open-minded and should not
approach the interview with pre-conceived designs about
what is required.
• 2.Stakeholders must be given a starting point for discussion.
This can be a question, a requirements proposal or an
existing system.
• Interviewers must be aware of organizational politics many
real requirements may not be discussed because of their
political suggestions.
Interviews
• Requires preparation and good communication
management
• Achieve interview objectives without preventing the
exploration of promising leads
• Interview as many stakeholders as possible
• Not just clients and users
• Ask problem-oriented questions
• Ask about specific details, but…
• Detailed and solution-specific questions may miss the
stakeholder’s real requirements. Example:
• Would you like Word 2007, Excel 2007 or both?
vs.
• Would you like to do word processing, computations, or both?
Interviews – Objectives and Process
• Three main objectives:
• Record information to be used as input to requirements
analysis and modeling
• Discover information from interviewee accurately and
efficiently
• Reassure interviewee that his/her understanding of the
topic has been explored, listened to, and valued
• Process consists of four important steps:
• Planning and preparation
• Interview session
• Consolidation of information
• Follow-up
• Many strategies for questioning
Interviews – Planning and Preparation
I See.
Tell Me Why I Don’t Think So.
You Feel They I Think You Have an
Are Too Slow. Elevator Throughput
Problem, not a Speed
Problem
Interviews – Start Up Questions (1)
Functional requirements
• What will the system do?
• When will the system do it?
• Are there several modes of operations?
• What kinds of computations or data transformations
must be performed?
• What are the appropriate reactions to possible stimuli?
• For both input and output, what should be the format of
the data?
• Must any data be retained for any period of time?
Interviews – Specific Questions (2)
Design Constraints
Physical environment
• Where is the equipment to be located?
• Is there one location or several?
• Are there any environmental restrictions, such as temperature,
humidity, or magnetic interference?
• Are there any constraints on the size of the system?
• Are there any constraints on power, heating, or air
conditioning?
• Are there constraints on the programming language because of
existing software components?
Interviews – Specific Questions (3)
Design Constraints
• Interfaces
• Is input coming from one or more other systems?
• Is output going to one or more other systems?
• Is there a prescribed way in which input/output need to be
formatted?
• Is there a prescribed way for storing data?
• Is there a prescribed medium that the data must use?
• Standards
• Are there any standards relevant to the system?
Interviews – Specific Questions (4)
Performance
• Are there constraints on execution speed, response time, or
throughput?
• What efficiency measure will apply to resource usage and
response time?
• How much data will flow through the system?
• How often will data be received or sent?
Interviews – Specific Questions (5)
Security
• Must access to the system or information be controlled?
• Should each user's data be isolated from data of other
users?
• Should user programs be isolated from other programs and
from the operating system?
• Should precautions be taken against theft or vandalism?
Interviews – Specific Questions (7)
Maintainability
• Will maintenance merely correct errors, or will it also
include improving the system?
• When and in what ways might the system be changed in
the future?
• How easy should it be to add features to the system?
• How easy should it be to port the system from one
platform (computer, operating system) to another?
Interviews – Specific Questions (9)
• Questionnaire
• Consider it as pre-work to a personal interview
Various approaches
• Text (informal, formal), diagrams (state, sequence ...),
video, animation, comics, storyboard, collaborative
workshops (pass the microphone or the ball)…
• There are specialized notation such as UML (sequence,
activity, use case, interaction, and collaboration
diagrams), Message Sequence Charts (MSC), Live
Sequence Charts, and Use Case Maps (UCM)
Representation of Scenarios (2)
System
System
prototype
prototyping
User
experiments
Ethnographic viewpoints
• The work setting viewpoint:
• This describes the context and the physical location of the work
and how people use objects to carry out tasks. Therefore, in a
study of a help desk (say), this would describe the objects which
the helper had to hand and how these were organized.
• Social and organizational perspectives:
• This tries to bring out the day-to-day experience of work as seen
by different people who are involved. Each individual typically sees
the work in a different ways and this viewpoint tries to organize
and integrate all of these perceptions.
• The workflow viewpoint:
• This viewpoint presents the work from a series of work activities
with information flowing from one activity to another.
2.4. Soft Systems methods
• These produce informal models of a social-technical system.
They consider the system, the people and the organization.
• Not techniques for detailed requirements elicitation. Rather,
they are ways of understanding a problem and its
organizational context.
• Software Systems Methodology (SSM) is probably the best
known of these methods.
• The essence of SSM is its recognition that systems are
embedded in a wider human and organizational context.
Stages of SSM
• Problem situation assessment.
• Problem situation description.
• Abstract system definition from selected viewpoints.
• Conceptual system modeling.
• Model/real-world comparison.
• Change identification.
• Recommendations for action
2.5. 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.
3. Prototyping
• A prototype is an initial version of a system which may be
used for experimentation.
• Prototypes are valuable for requirements elicitation because
users can experiment with the system and point out its
strengths and weaknesses. They have something concrete to
criticize.
• Rapid development of prototypes is essential so that they
are available early in the elicitation process.
Prototyping benefits
• 1.The prototype allows users to experiment and discover
what they really need to support their work.
• 2.Establishes feasibility and usefulness before high
development costs are incurred.
• 3.Essential for developing the ‘look and feel’ of a user
interface.
• 4.Can be used for system testing and the development of
documentation.
• 5.Forces a detailed study of the requirements which reveals
inconsistencies and errors.
Types of prototyping
• Throw-away prototyping:
• Intended to help elicit and develop the system requirements.
• The requirements which should be prototyped are those which
cause most difficulties to customers and which are the hardest to
understand. Requirements which are well-understood need not be
implemented by the prototype.
• Evolutionary prototyping:
• Intended to deliver a workable system quickly to the customer.
• Therefore, the requirements which should be supported by the
initial versions of this prototype are those which are well-
understood and which can deliver useful end-user functionality. It
is only after extensive use that poorly understood requirements
should be implemented.
Prototyping costs and problems
• Training costs - prototype development may require the use
of special purpose tools.
• Development costs - depend on the type of prototype being
developed.
• Extended development schedules - developing a prototype
may extend the schedule although the prototyping time
may be recovered because rework is avoided.
• Incompleteness - it may not be possible to prototype critical
system requirements
Approaches to prototyping
• Paper prototyping
• A paper mock-up of the system is developed and used for system
experiments.
• ‘Wizard of Oz’ prototyping
• A person simulates the responses of the system in response to
some user inputs.
• Executable prototyping
• A fourth generation language or other rapid development
environment is used to develop an executable prototype.
Executable prototype development
• Fourth generation languages based around database
systems.
• Visual programming languages such as Visual Basic or
Object Works.
• Internet-based prototyping solutions based on World Wide
Web browsers and languages such as Java.
4. Requirements analysis