HARAMAYA UNIVERSITY

College of Computing and Informatics

Department of Software Engineering
Target Group:- 3rd Year Software Engineering Students

Course Name:- Requirements Engineering

Compiled By: Shambel Adugna

3/07/2024
 CHAPTER -THREE

REQUIREMENT ELICITATIONAND
ANALYSIS

Compiled By:Shambel Adugna

 What is Requirements Analysis

The process of studying and analyzing the customer and the user
needs to arrive at a definition of the problem domain and
system requirements
• Requirement analysis is significant and essential activity after
elicitation.
• We analyze, refine, and scrutinize the gathered requirements to
make consistent and unambiguous requirements.

Compiled By: Shambel Adugna

 Cont…
• This activity reviews all requirements and may provide a
graphical view of the entire system.
• After the completion of the analysis, it is expected that the
understandability of the project may improve significantly.
• Here, we may also use the interaction with the customer to
clarify points of confusion and to understand which
requirements are more important than others.

Compiled By:Shambel Adugna

Compiled By:Shambel Adugna
 Cont…
Objectives
• Discover the boundaries of the new system (or software) and how it must
interact with its environment within the new problem domain
• Detect and resolve conflicts between (user) requirements
• Negotiate priorities of stakeholders
• Prioritize and triage requirements
• Elaborate system requirements, defined in the requirement specification
document, such that managers can give realistic project estimates and
developers can design, implement, and test
• Classify requirements information into various categories and allocate
requirements to sub-systems
• Evaluate requirements for desirable qualities
Compiled By:Shambel Adugna
 Requirement Priorities
• the most urgent requirements in the first release
• some would be performed very often and others just occasionally
or only by a few people
• resource limitations
• Prioritization helps the project manager
–resolve conflicts,
–plan for staged deliveries, and
–make the necessary trade-offs

Compiled By:Shambel Adugna

 Requirement Priorities…
• If all requirements are top priority,
– your project has a high risk of not being fully
successful
• When you evaluate priorities,
– look at the connections and interrelationships
among different requirements and their alignment with
the project's business objectives

Compiled By:Shambel Adugna

High, medium, and low approach
• subjective and imprecise
• stakeholders must agree on two dimensions: importance and
urgency
• High priority requirements:
–important (the user needs the capability)
–urgent (the user needs it in the next release).

Compiled By:Shambel Adugna

 Cont…
• Medium priority requirements:
– important (the user needs the capability)
–but not urgent (they can wait for a later release).
• Low priority requirements:
–not important (the user can live without the capability if
necessary) and
– not urgent (the user can wait, perhaps forever).

Compiled By:Shambel Adugna

 Requirements Analysis
• Problem analysis
• Development of product vision and project scope
• Analysis and elicitation feed each other

Elicitation
Elicitation Questions and points
Notes to consider

Analysis Requirements Specification

Compiled By:Shambel Adugna

 Inspection
• The requirements inspection isa formal meeting.
• It should be chaired by someone who has not been involved
in producing the requirements which are being validated.

• A formal requirements inspection should involve a team of

inspectors from different backgrounds who read the requirements
document and record problems with the system requirements.

• inspectionsinvolve the group making some decisions on

Compiled By:Shambel Adugna
actions to be taken to correct the identified problems.
 Cont…

• Actions that might be decided for each problem are as

follows:-
1 Requirements clarification.
2 Missing information.
3 Requirements conflict.
4 Unrealistic requirements.

Compiled By:Shambel Adugna

 Requirements Modeling
Elicitation/analysis and modeling are intermixed

Compiled By:Shambel Adugna

 Requirements Modeling
This is an essential task in specifying requirements
• Map elements obtained by elicitation to a more precise form
• Help better understand the problem
• Help find what is missing or needs further discussion
• Different modeling languages
• Informal:
natural language
• Goal-oriented modeling (GRL)
• Functional modeling:
UML (Unified Modeling Notation)
UCM (Use Case Maps)
...
Compiled By:Shambel Adugna
 Requirements Verification and Validation
• Need to be performed at every stage during the (requirements) process
• Elicitation
• Checking back with the elicitation sources
• “So, are you saying that . . . . . ?”
• Analysis
• Checking that the domain description and requirements are
correct
• Specification
• Checking that the defined system requirement will meet the user
requirements under the assumptions of the domain/environment
• Checking conformity to well-formedness rules, standards…
Compiled By:Shambel Adugna
 Requirements Classification –
Features
• A Feature is
• a set of logically related (functional) requirements that provides a
capability to the user and enables the satisfaction of a business
objective
• The description of a feature should include1
• Name of feature (e.g. Spell check)
• Description and Priority
• Stimulus/response sequences
• List of associated functional requirements
Compiled By:Shambel Adugna
The Use of Models

Compiled By:Shambel Adugna

 Models
• a model is a reduced representation (simplified, abstract) of (one
aspect of) a system used to:
• Help understand complex problems and / or solutions
• Communicate information about the problem / solution
• Direct implementation
• Qualities of a good model
• Abstract
• Understandable
• Accurate
• Predictive
• Inexpensive

Compiled By:Shambel Adugna

 Modeling Notations
Natural language (English) Semi-formal notation (URN, UML...)
+ No special training required + Syntax (graphics) well defined
- Ambiguous, verbose, vague, obscure ... + Partial common understanding,
- No automation reasonably easy to learn
Ad hoc notation (bubbles and arrows) + Partial automation
+ No special training required - Meaning only defined informally
- No syntax formally defined - Still a risk of ambiguities
- meaning not clear, ambiguous Formal notation (Logic, SDL, Petri nets,
- No automation
FSM ...)
+ Syntax & semantics defined
+ Great automation (analysis and
transformations)
- More difficult to learn & understand
Compiled By:Shambel Adugna
 Modeling notations …..
• Informal language is better
understood by all stakeholders
• Good for user requirements, contract
• But, language lacks precision
• Possibility for ambiguities
• Lack of tool support
• Formal languages are more precise
• Fewer possibilities for ambiguities
• Offer tool support (e.g. automated verification and transformation)
• Intended for developers

Compiled By:Shambel Adugna

 Modeling Structure
Concepts of Entities and their Relationships. Use one of the following
notations:
• ERD (Entity Relationship Diagram – the traditional version)
• UML class diagrams
• Relational tables
• Can bé used for the following
• Model of the problem domain (called “domain model”)
• The two versions: existing and to-be
• Model of input and output data structures of system-to-be
• Model of the stored data (database)
• not necessarily an image of the domain data
• Additional data is introduced (e.g. user preferences)
• Architectural design of the system-to-be
Compiled By:Shambel Adugna
 User Requirements Notation
(URN)

Compiled By:Shambel Adugna

 URN Overview
➢ URN is a semi-formal, lightweight graphical language for modeling and
analyzing requirements in the form of goals and scenarios and the links
between them
• Combines two existing notations
• Goal-oriented Requirement Language (GRL)
• (UCMs)
• Support Use Case Maps for the elicitation, analysis, specification, and
validation of requirements
• Allows systems, software, and requirements engineers to discover and
specify requirements for a proposed system or an evolving system,
and analyse such requirements for correctness and completeness

Compiled By:Shambel Adugna

 URN Overview …….

➢ URN models can be used to specify and analyze various types of

reactive systems, business processes, and telecommunications
standards.

Compiled By:Shambel Adugna

 Combination of Goals and Scenarios
➢ URN combines two complementary parts:
▪ The Goal-oriented Requirement Language (GRL)

➢ For modelling goals and other intentional concepts (mainly for non-
functional requirements, quality attributes, and reasoning about alternatives
and tradeoffs)

▪ The Use Case Map (UCM) notation

➢ For modelling scenario concepts (mainly for operational requirements,
functional requirements, and performance and architectural reasoning)
➢ URN offers concepts for the specification of stakeholders, goals, non-functional
requirements, rationales, behaviour, scenarios, scenario participants (actors), and high-
levelCompiled
architectural structure
By:Shambel Adugna
 URN – Main Objectives
• Focus on early stages of development with goals and scenarios
• From user requirements to functional and non-functional system
requirements
• No messages, components, or component states required
• Reusability
• of argumentations (goal patterns and analysis)
• of scenarios (patterns and architectural alternatives)
• Early performance analysis
• Traceability and transformations to other languages

Compiled By:Shambel Adugna

 Summary
• The User Requirements Notation (URN) is an ITU-T standard.
• Modeling with the Goal-oriented Requirement Language
• Focuses on answering “why” questions
• Intentions, functional / non-functional requirements, rationales
• Modeling with Use Case Maps
• Focuses on answering “what” questions
• Scenarios, services, architectures
• While modelling with URN as a whole, goals are operationalized into tasks,
and tasks
are elaborated in scenarios (mapped to UCM path elements)
• Moving towards answering “how” questions
• Can guide the selection of an architecture or scenarios
• Enables the elicitation/specification of systems, standards, & products, analysis
from
various angles,
Compiled By:Shambel& transformations
Adugna
Prototyping
 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.
❖Rapid development of prototypes is essential so that they are available
early in the elicitation process.
❖A prototype is a simulation of a final product which product teams use for
testing before committing resources to building the actual thing.
• The goal of a prototype is to test and validate ideas before sharing them
with stakeholders and eventually passing the final designs to
engineering teams for the development process.
 Prototyping …
❖ Prototypes are essential for identifying and solving user pain points with participants during usability
testing.
❖ Testing prototypes with end-users enables UX teams to visualize and optimize the user experience
during the design process.
❖ Engineering is expensive, and making changes to a final product is often not as straightforward as
teams anticipate.
❖ So, finding and fixing errors during the design process is critical.
❖ Prototypes have four main qualities:
❖ Representation :The prototype itself, i.e., paper and mobile, or HTML and desktop.
❖ Precision :The fidelity of the prototype, meaning its level of detail—low-fidelity or high-fidelity.
❖ Interactivity : The functionality available to the user during the testing phase, e.g., fully
functional, partially functional, or view-only.
❖ Evolution : The lifecycle of the prototype. Some are built quickly, tested, thrown away, and then
replaced with an improved version (known as “rapid prototyping”). Others may be created and
improved upon, ultimately evolving into the final product.
 Prototyping …
❖ Another common misconception about prototyping is that it only needs to be done once or twice
at the end of the design process—not true.
❖ One of our mottos that we believe at UXPin is “test early and test often.”
❖ According to Elementor’s Director of UX, the website building platform’s designers’ – average
four to five prototyping sessions, depending on the complexity of a given design.
❖You should prototype every possible iteration of your design even your early basic ideas for
solving a user need.
❖ Prototyping shouldn’t be reserved only for beta tests of the final version; you should test any and
every version of your product!
 Approaches to prototyping
❖ Paper prototyping
▪ a paper mock-up of the system is developed and used for system experiments.
▪ A paper prototype is a prototype that is drawn on a paper or a digital whiteboard.
▪ Such a prototype is used during the early design stages, like a design thinking workshop while
designers still brainstorm ideas.
▪ It works best during early design stages where design teams collaborate to explore many
concepts fast.
▪ Team members sketch ideas by hand using simple lines, shapes, and text.
▪ The emphasis is on lots of ideas and speed, not aesthetics.
 Approaches to prototyping …

▪ UX Teams lay paper screens on the floor, table, or pinned to a board to

simulate user flows. A common practice for testing these prototypes is to
have one person play “the product,” switching the sketches according to
how the real user behaves.
A low visual/low functional paper prototype.
 Approaches to prototyping …
▪ Advantages of Paper Prototypes:
✓ Fast :You can sketch a prototype in minutes, which is why paper works so well for testing lots of ideas..
✓ Inexpensive :You only need a maker pen and paper to create prototypes, making the process cheap and
accessible.
✓ Team-building : Paper prototyping is a collaborative effort, and often teams have fun coming up with
fresh ideas.
✓ Documentation : Team members can keep physical copies of paper prototypes, notes, and to do so for
quick reference during future iterations.
▪ Disadvantages of Paper Prototypes:
✓ Unrealistic — No matter how skilled the art or craftsmanship, paper prototypes will never be more than
hand-drawn representations of a digital product.
✓ False positives — Sometimes, paper prototypes don’t validate ideas properly.
✓ What seems like a good idea on paper might not work effectively in a digital wireframe.
✓ No gut reactions — Paper prototypes rely on the user’s imagination, adding a break between seeing the
stimulus and responding to it. That “gut” reaction is crucial for a successful UX.
 Approaches to prototyping

❖‘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.
 Types of prototyping
❑ Throw-away prototyping
✓ intended to help elicit and develop the system requirements.
✓The requirements that should be prototyped are those that cause most
difficulties to customers and which are the hardest to understand.
Requirements that 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 that 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 Benefits
• The prototype allows users to experiment and discover what they really
need to support their work.

• Establishes feasibility and usefulness before high development costs are

incurred.

• Essential for developing the ‘look and feel’ of a user interface.

• Can be used for system testing and the development of documentation.
• Forces a detailed study of the requirements which reveals inconsistencies
and omissions.
 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.
Compiled By:Shambel Adugna