RE: Sheet Cheat : Version 1.0.

Copyrights: @ZzLouaizZ

• Most projects require a short initial step in which the following kinds of questions are explored

• What is the vision for this project?

• Feasible?
• Should we proceed or stop?
• Do the stakeholders have basic agreement on the vision of the

project?

• A short, quantified statement of what the product is intended to do, and what bene t it brings to the
business.

• This statement of purpose is an explanation of why the business is investing in the project, along
with the business bene t it wants to achieve.
• This justifies the project and serves as a focus for the requirements discovery process.
• • Definition of solution system boundaries
• • Scope of initial release
• • Major features planned for initial release
• Acceptable quality characteristics of initial release
• • Scope of subsequent releases

• Clients: pay for the software to be developed

 Stakeholders:

• Customers: buy the software after it is developed

• Users: use the system
• Domain experts: familiar with the problem that the software must automate
• Market Researchers: conduct surveys to determine future trends and potential customers
• Lawyers or auditors: familiar with government, safety, or legal requirements
• Software engineers or other technology experts

Risks:

• Possibly a short risk analysis to reveal the main risks faced by the project.

Go/No decisions:

• Decide whether it makes good business sense to press the button and launch the requirements project

• Consider your deliverables:

• Is the product goal clear and unambiguous? Or • Does it contain fudge words?

Needs Finding:

Framing design:

What’s in and what’s out: Frame describes aspects of the design problem the designer considers to be
important and will focus on.

Design space:

what can vary in how you are thinking about the problem?

Ideation:

Goal: Generate a lot concepts from which you can generate a high-quality solution.

Requirement Elicitation:

“Yes, but ...” syndrome

• “Wow, this is so cool and nice; we really want to use this.”

• “Yes, but, hmmm,

• What about this part ...?

• “Yes, but ...” solution

• Get the “buts” out AE(earlier)AP • Elicit the “buts” response early //To shows users the prototypes or demos earlier
and regularly //

“Undiscovered requirements” syndrome

• “The more you nd, the more you need to know”

“Undiscovered requirements” syndrome • “The more you nd, the more you need to

know”

• “Undiscovered requirements” solution

• Scoping your system

• Identify the stakeholders in three worlds

12

“User and developer”

• “User and developer” syndrome
• Communication gap between user and developer
• From di erent world
• Speak di erent language
• Di erent background, motivations, objectives

13

“User and developer”

• “User and developer” syndrome
• Communication gap between user and developer

• From di erent world

• Speak di erent language
• Di erent background, motivations, objectives

• “User and developer” solution

• Better communication to mitigate the risk

• Role playing
• User observation • Storyboarding
• Prototypes
•...

Apprenticing
• This technique is also known as ”job shadowing”

• Based on the old idea of masters and apprentices

• the requirements analyst is the apprentice

• the user assumes the role of master craftsman

• Is a way to observe and learn the work as it really happens

• The analyst sits with the user at the user’s place of work, learning the job by:

• making observations
• asking questions
• doing, sometimes, some of the work under supervision

Apprenticing
3

Apprenticing
• If you want to get an accurate explanation of the work:

1. Go to the work
2. Sit beside the user in the normal workplace
3. Get a running commentary on the work as it happens

• While he is working, the user can describe his task precisely and tell you why he is doing things.

• If the explanation is not clear, the apprentice asks questions:

• “Why did you do that?”

• “What does this mean?”
• “How often does this happen?”
• “What happens if this piece of information is not here?”

Apprenticing
• Can not expect users to have the presentation and teaching skills needed to present their work e
ectively to others.

• Conversely, almost everyone is good at explaining what they are doing while they are doing it.

Nobody can talk better about what they do and why they do it than they can while in the middle of doing
it.

—Hugh Beyer and Karen Holtzblatt. Contextual Design

Apprenticing
• The requirements analyst learns the work while sitting at the user’s desk, sometimes building models of
the work while learning it
6

Apprenticing
• Apprenticeship can be combined with modeling.
• As you observe the work and the user explains it, you sketch a model

of the tasks and their connections with the other tasks

• As you build your models, feed them back to the user and con rm that they are correct.

When Should You Use Apprenticing

• Apprenticing is very useful when :

• the analyst is inexperience with the domain,

• the users have di culty in explaining their actions.

Interviews

Interviews
• Interviews are a traditional source of requirements
• One of the most frequently-used methods for understanding your

users.

• Variety of di erent types of interviews you can conduct, depending on your constraints and needs

Interviews
• Who
• User/potential user
• ”Typical” member of group you are interested in

• Where
• Where participant normally uses product or service (or might do so) • Where participant feels comfortable

• When
• Scheduled in advance
• Mutually convenient time
• When participant normally uses product or service (or might do so)

10

Interviews
• Types of Interviews
• Group vs. individual • Remote vs. in-person

• Degree of structure • Structured

• Semi-structured • Unstructured

11

Structured Interviews
• Structured interview is a verbal questionnaire.
• The interaction is limited by a script and a xed set of questions.
• Every participant is generally asked the same questions in the same order.
• Closed question.
• Pre-coded responses, limited range of responses is elicited.
• Example: Do you think that health services in this area are excellent, good, average or poor?

12

Structured Interviews
• Can be conducted in person, over the phone, or through collaboration technologies such as chat.
• Can last from several minutes to several hours with dedicated participants.
• Can be used throughout the development cycle but are most useful when:

• the goals and major issues of a project are well understood, and
• you know enough to generate a list of expected response categories.

13

When Should You Use Structured Interviews?

• Asking speci c questions after you understand the broad issues of a particular domain, product,
or project.
• Collecting uniform data from a large sample of participant and organizations.
• Comparing results across di erent groups of users on a xed set of responses.
• Collecting detailed and consistent information about speci c issues.

14

Advantages of Structured Interviews?

• Untrained interviewers can more easily conduct these interviews than semi-structured or
unstructured interviews.
• Responses are more reasonably comparable than less structured interviews because all
interviews are based on the same set of questions and response categories.
• Structured interviews can be done face-to-face, over the telephone, or through video
conferencing systems like Skype.
• Data analysis is relatively easy given that most questions have structured responses.

15

Disadvantages of Structured Interviews?

• Creating valid and reliable structured questions and responses requires solid background in
questionnaire design.
• Possibility to end up with precise answers to the wrong questions.
• Interviewers can become less consistent as they get tired or start to anticipate answers.

16
Semi-Structured Interviews
• Combines some structured questions with some unstructured exploration

Balance between...

• Researcher interests and focus • Open, free-form discussion

• Script, or interview protocol

17

Semi-Structured Interviews
• Alternative Names: Focused interview, qualitative research interview

• It is useful when you know something about a topic, but want to give users an opportunity to raise new
issues

• Goal: Gather systematic information about a set of central topics, while also allowing some exploration
when new issues or topics emerge.

18

When Should You Use Semi-Structured Interviews?

• Gather facts, attitudes, and opinions

• Gather data on topics where the interviewer is relatively certain that the relevant issues have been
identi ed

• Understand user goals.

19

Advantages of Semi-Structured Interviews?

• May uncover previously unknown issues (in contrast to a structured interview)
• Address complex topics through probes and clari cation
• Provide a mechanism for redirecting conversations that digress

too far from the main topic

• Provide some exibility for interviewers and also allows some broad comparisons across
interviews
• Require less training time than unstructured interviews because the interviewer has a set of
speci c questions available as a starting point

20

Disadvantages of Semi-Structured Interviews?

• The mixture of quantitative and qualitative data that results can be time-consuming to analyze

• Too much exibility among interviewers might make comparisons di cult

• The ndings of semi-structured interviews might be hard to generalize because di erent interviewers
may ask some di erent questions

21

Unstructured Interviews
• An unstructured interview is the most similar to a normal conversation
 • ”Unstructured” does not mean unprepared
• Interviewers need to de ne the goals of the interview clearly during

planning and proceed with an agenda of the main topics

• Unstructured interviews often last from one-half to two hours

22

Unstructured Interviews
• Unstructured interviews can be done at any time during the development cycle but they are
most useful during the early stages
• The questions or topics for discussion are open-ended
• Generate rich data
• No predetermined interview format or speci c questions

23

Advantages of Using Unstructured Interviews

• Gather rich, in-depth data imposing restrictions on what they can express.
• Allow greater freedom to ask question
• Methods provide exibility according to situation
• Explorative and qualitative studies
• Can ensure questions are fully understood

24

Disadvantages of Using Unstructured Interviews

• Interviewer requires great deal of knowledge and skill in order to analyse the data
• Information cannot be compared
• Data analysis will be di cult
• Time wasting
• Hard to replicate study

25

Reading existing documents

Reading existing documents

Sources of project information

• Company reports (business context)

• Organization charts (potential stakeholders)
• Policy manuals (regulations)
• Job descriptions (potential requirements, problems, and business process)
• Existing systems documentation (reusable requirements)

26

Business context example

“Intellibuild wants to o er a pioneering product that will revolutionize the market of infotainment. These
services will replace the existing model, e.g. going to the information desk or getting the information
before reaching the location. Furthermore, it will implement new services that have not been o ered
before, e.g., real-time noti cation of schedule changes.”

27

Elicited requirement info from business context

• Business goal
• To provide infotainment product

• Risk
• To be a pioneering product is a risk in market

• Problem
• To replace the existing information broadcasting model

• Requirement
• To provide real-time noti cation of schedule change

28

”Hard Data” Example

• What dose this data tell you?

• What would the system do with this data?

29

Elicited Requirements From ”Hard Data”

• R1: The system should provide all the data concerning a ight ticket

• SR1: The system should provide the passenger information which can be used to uniquely identify a
passenger (e.g., passport No.)
• SR2: The system should provide the departure and arrival time and airport information
• SR3: The system should provide ght number information. •...

30

Reading existing documents

• Advantage
• Get understanding before real meeting

• More resource for fact nding • Discover reusable requirements

• Disadvantage
• Document is always not up-do-date
• Much irrelevant data results in wasting e ort

• Appropriate for
• When you are unfamiliar with the system background
Questionnaires
• Survey large groups
• Can be open-ended or closed-ended

• When should you use a Questionnaire?

• There are a large number of customers or users

• where logistics make it di cult to get together in person

• They are inexpensive

32

Things to Be Aware of When Using a Questionnaire

• Unfortunate reality of questionnaires: • Not everyone is going to respond

• Those that do choose to respond may be systematically di erent from those who do not. -> Response Bias

Remark

Experienced questionnaire researchers give response rate estimates of anywhere between 20% and
60%, depending on user type and whether incentives are o ered or not.

33

Creating and Distributing Questionnaire

• Number of Respondents

• Get a statistically signi cant response

• Sample is too small -> the data cannot be extrapolated to the entire

population
• Impossible to increase the sample size -> it becomes a feedback

form.
• Feedback form: does not o er everyone in the population an equal

chance of being selected to provide feedback

Example

• It may represent only people that are particularly angry about your customer service and seek out a way to contact you.

34

Creating and Distributing Questionnaire

• Identify the Objectives of your Study:

• Who do we want to learn about?

• What information are you looking for (i.e., what questions are you trying to answer)?
• How will you distribute the questionnaire and collect responses?
• How will you analyze the data?
• Who will be involved in the process?

35

Compose Questions
1. Identify Your Research Questions and Constructs • For each objective, you need to identify :

• Research question(s) and,

• The constructs to measure to answer those questions (e.g., satisfaction, frequency of use,...)

2. Keep It Short

• Every question should be tied to an objective and (ideally) be

actionable

• Use branching logic

• Do not ask questions that respondents cannot answer validly
• No essay questions

36

Building the Questionnaire

• Standard Items to Include:

• Title: Give every questionnaire a title. Keep it short

• Instructions: Include any instructional text that is necessary for your questionnaire. For example: ”Please
return the completed questionnaire in the enclosed self-addressed”
• Contact Information: You should include contact information on your questionnaires
• Purpose: Tell participants why you are conducting the questionnaire
• Time to Complete: People will want to know at the beginning how long it will take to nish the questionnaire
before they invest their time into it

37

Building the Questionnaire

• Standard Items to Include:
• Con dentiality: It means that the person’s identity will not be

associated in any way with the data provided.

• Anonymity: It is di erent from con dentiality. If a respondent is anonymous, it means that even you, the researcher,
cannot associate a completed questionnaire with the respondent’s identity.

• Example: Web questionnaires are typically con dential but not anonymous. They are not anonymous because you
could trace the questionnaire (via an IP address).

38

Questionnaires Tools
• Some basic questionnaires tools are free (e.g., Google Forms)

• Online questionnaires will most likely require the purchase of a license for an online survey tool

• However, Phone and e-mail surveys can be created cheaply.

39

Analyze the Data

• Thinking about your data analysis before you distribute your questionnaire

• What kind of analysis do you plan to perform?

• Are there questions that you do not know how to analyze? • Will the analysis provide you with the answers you
need? • Do you have the correct tools to analyze the data?
• How will the data be entered into the analysis tool?

40

Considerations when Choosing a Survey Method

• Interactivity

41

Considerations when Choosing a Survey Method

• More Intuitive Design

42

Data Analysis and Interpretation

• Descriptive Statistics
These measures describe the sample in your population. Key calculations for closed-ended questions.

• Mean: Average of the scores in the population.

• Median: The point that divides the distribution of scores in half. It’s

useful when your data are skewed.

• Mode: The score in the population that occurs most frequently.

• Maximum and minimum: The minimum is the smallest number in your data set and the maximum is the
largest.

43
Data Analysis and Interpretation
• Measures of Dispersion
These statistics show you the ”spread” or dispersion of the data around the mean.

• Range: The maximum value minus the minimum value.

• Standard deviation: A measure of the deviation from the mean. The larger the standard deviation, the more varied
the responses were that participants gave.

• Frequency: The number of times that each response is chosen. This is one of the more useful calculations for survey
analysis. It is nice to convert the frequencies to percentages

44

Data Analysis and Interpretation

• Measures of Association
Measures of association allow you to identify the relationship between two survey variables.

• Comparisons: Comparisons demonstrate how answers to one question are related to the responses to another
question in order to see relationships.

• Correlations: They are used to measure the degree to which two variables are related. Correlation analysis
generates a correlation coe cient, which is the measure of how the two variables move together.

45

Data Analysis and Interpretation

• Inferential Statistics

• Make inferences or predictions about the characteristics of our

population.

• Test how generalizable these ndings are to the larger population

• To do that, we need to do tests of signi cance (i.e., con rming that these ndings were not the result of
random chance or errors in sampling).

46

Data Analysis and Interpretation

Paradata
• Paradata is the information about the process of responding to the

survey.

• Example:

• How long it took the respondent to answer each question or the

whole survey

• If the respondent changed any answers to his or her questions or went back to previous pages
• If the respondent opened and closed the survey without completing it (i.e., partial completion)
• How the respondent completed it (e.g., smartphone app, web browser, phone, paper).

47

Advantages and Disadvantages of Surveys

• Advantages:
• Questionnaires can reach a large population

• They can focus the users on speci c topics • They can be used to prioritize requirements

• Disadvantages:

• It is sometimes hard to understand how to interpret an answer

without the ability to ask follow-up questions

• It may be di cult to get the questionnaires returned

Goal-Oriented Requirements Engineering (GORE)

• Goal has received much attention in RE research as a means of:

• Understanding the motivations for system requirements • Helping to ensure that the right system is
built

• Goal frameworks allow for:

• Representation of stakeholder goals

• Goals may be assigned to an agent (stakeholder or system)
• Goals may have relationships to other goals, often describing

achievement
Identifying Stakeholders’ Goals
• Focus on why a system is required
• Express the ’why’ as a set of stakeholder goals

• Use goal re nement to arrive at speci c requirements • Goal analysis

• document, organize and classify goals

• Goal evolution
• re ne, elaborate, and operationalize goals

• Goal hierarchies show re nements and alternatives

• Use goal re nement to arrive at speci c requirements

• Goal hierarchies: show re nement and obstacle relationships between

goals

De ne Goals
Where do goals come from?

• Conveyed by stakeholders
• Disclosed in requirements documents • Analysis of similar or current system • Elaborating other goals

Why use goal models?

• Give rationale for requirements • Identify stable information
• Guide requirement elaboration

Goal or Not a Goal?

Goal Examples

• Credit card information is kept private • Credit card information is accurate

• Safe transportation
• Highly reliability

Non-Goal Examples

• The system will be implemented in C++

• The paint colors for the cars will be yellow, orange, and red

Goal Exercise
Order the list of goals from high-level concern to low-level concern

• User receives a request for a timetable from a system • Collect timetables by system
• Schedule meeting
• System collect timetables from user

• Collect timetables

Goal Exercise
Order the list of goals from high-level concern to low-level concern

• Schedule meeting
• Collect timetables
• Collect timetables by system
• System collect timetables from user
• User receives a request for a timetable from a system

When to use goal models

Early requirements engineering

• Focus on identifying problems

• Exploring system solutions and alternatives • Done before UML modeling

Goal Orientation in RE
• Goal = prescriptive statement of intent the system should satisfy through cooperation of its
agents
 • ”prescriptive statement”: in optative mood
• e.g. “Loan periods shall be limited to 2 weeks”

• “Train doors shall be closed while the train is moving”

• “System must only be accessible to employees with SIPR access”

• formulated in terms of problem world phenomena

• ”system”: system-as-is, system-to-be

• software + environment

• ”agent”: active system component • responsible for goal satisfaction

10

Goal Satisfaction -> Agent Cooperation

• Agent = role, rather than individual

• must restrict its behavior to meet its assigned goals

• must be able to monitor/control phenomena involved in assigned

goals

• Agent types
• software (software-to-be, legacy software, foreign software)

• device (sensor, actuator, ...) • human

• e.g. TrainController, Passenger, SpeedSensor, TrackingSystem

• The more ne-grained a goal, the fewer agents required for its satisfaction
Goals vs Domain Properties
• Domain property = descriptive statement about environment • indicative mood: ”is”, ”are”, etc –not
prescriptive
• e.g. ”A borrowed book is not available for other patrons”

• The distinction between goals & domain properties • Goals can be negotiated, weakened, prioritized

• Domain properties cannot

• Both required in requirements documentation

15

Goal Granularity
• Goals -> di erent levels of abstraction
• Higher-level goals: strategic, coarse-grained • “50% increase of transportation capacity” • “E ective
access to state of the art”
• Lower-level goals: technical, ne-grained
• “Acceleration command sent every 3 secs”
• “Reminder issued by end of loan period if no return”
• Linked together by AND/OR re nement
• The ner-grained a goal → the fewer agents required for its satisfaction

16

Goal Types
Goal Types
• Two types of goals:

Behavioral goals : prescribe behaviors vs.

Soft Goals: state preferences among alternative behaviors

17

Behavioral Goal
• Prescribe intended system behaviors declaratively

• Implicitly de ne maximal sets of admissible agent behaviors

• Can be satis ed in a clear-cut sense: YES or NO

• Goal satisfaction, formal analysis

• Used for building operation models to meet them ”Worst-case stopping distance maintained”
“Reminder sent if book not returned on time”

18

Behavior Goals -> Desired Behaviors

19

Achieve Goals

• Achieve [TargetCondition]:
[if CurrentCondition then] sooner-or-later TargetCondition
• Achieve [BookRequestSatis ed]:
if a book is requested then sooner-or-later
a copy of the book is borrowed by the requesting patron

• Achieve [FastJourney]:
if train is at some plateform then, within 5 minutes, it is at next platform

20

Maintain Goals

• Maintain [GoodCondition]:
[if CurrentCondition then] always GoodCondition always (if SomeCondition then GoodCondition)

• Maintain [DoorsClosedWhileMoving]:
always (if a train is moving then its doors are closed)
• Maintain [WorstCaseStoppingDistance]:
always (if a train follows another then
its distance is su cient to allow the other to stop suddenly)

21

Avoid Goals
• Avoid [BadCondition]:
[if CurrentCondition then] never BadCondition

• Avoid [BorrowerLoansDisclosed]:
never patron loans disclosed to other patrons

22

Soft Goals
• Cannot be satis ed in clear-cut sense:
more satis ed in one option, less satis ed in another

• goal satis cing, qualitative analysis (Chung et al. 2000 ”Non-functional Requirements in Software Engineering)

• Used for comparing options to select preferred

• Form: Maximize/Minimize, Increase/Reduce, Improve,... ”Stress conditions of air tra c
controllers shall be reduced” ”The workload of library sta shall be reduced”
”The bibliographical search engine shall be usable by non-CS students”

• satis cing != Partial Degree of satisfaction

23

Soft Goals
• E.g. for a train system:
24

Soft Goals

25

Goal Modeling
Behavioral Goal

Describe functions that must be carried out. E.g.

• Satisfaction goal • Information goal

Also classi ed:

• Achievable/cease goals

• Reach some desired state eventually

• Maintain/avoid goals

• Keep some property invariant

Soft Goals

Cannot really be fully satis ed. E.g.

• Accuracy
• Performance • Security
• ...

26

Goal Analysis

Goal Elaboration:

• ”Why” questions explore higher goals (context) • ”How” questions explore lower goals (operations) •
”How else” questions explore alternatives

Relationships between goals:

• One • One • One

• One

goal helps achieve another (+)

goals hurts achievement of another (-)

goal makes another (++)

Achievement of goal A guarantees achievement of goal B

goal breaks another (–)

Achievement of goal A prevents achievement of goal B

• Precedence ordering

• must achieve goals in a particular order

Obstacle Analysis:

27

• Can this goal be obstructed, if so how?

Identi cation of goal con icts

28

Identi cation of goals

29

Identi cation of goals

30

Goal-based
• Advantage
• Reasonable intuitive
• Easy for business goal identi cation and decomposition

• Disadvantage
• Hard to cope with goals evolution
• Either very complex goal hierarchy or lack of details

• Appropriate for
• Initial business goal modeling

31

i* language: layout
Designed by Eric Yu in the early 90s as his PhD thesis

• SD (Strategic Dependency) models goal related dependencies between depender and dependee actors

• SR (Strategic Rationale) models how actors achieve goals, and their dependencies on other actors

32

The i* language : a chronology

33

Example
University travel reimbursement
• Students organize trips to conferences

• They rely on travel agencies and the university’s trip management information system

• Multiple alternatives exist to arrange a trip

34

i* language

• Actor

• an active, autonomous entity that aims at achieving its goals by exercising its know-how, in collaboration with
other actors
ex= Travel Agency

• Role

• characterization of the behavior of a social actor within some context

• Agent

• actor with concrete, physical manifestations, such as a human individual, an organization, or a department
35

Which one should I use?

• Can I identify a concrete individual or (sub)organization?

• Do I want to characterize an abstract class?

• I don’t know at this time, or I do not care

36

Actor association links

• is-a: represents the concept of generalization / specialization, and can be applied to (role to role) or
(actor to actor)

• Not apply to agents!

37

Actor association links

• participates-in: represents any kind of association, other than is-a, between two actors

• Di erent meanings depending on the linked elements, e.g.

• (agent to role) may represent the plays relationship

• (linking elements of the same type) may represent the part-of relationship
38

i* Intentional Elements

• Actor boundaries

• all of the elements within a boundary for an actor are explicitly desired by that actor
• to achieve these elements, an actor must depend on the intentions of other actors

• Goal (hardgoal)

• intentional desire of an actor

• Softgoal

• criteria for the goal’s satisfaction are not clear-cut

• judged to be su ciently satis ed from the point of view of the actor

39

i*

• Task

• actor wants to accomplish some speci c task, performed in a particular way

• Resource

• actor desires the provision of some entity, physical or informational

40

Goal
• A goal is a state of a a airs that the actor wants to achieve and that has clear-cut criteria of achievement

• “Paper published”
• “Tickets booked” ->There is a clear criterion to determine if

these are achieved

• Goals are represented as ovals

41

Qualities
• A quality is an attribute for which an actor desires some level of achievement
• Examples:

• “Performance (of a system)” • “Quick booking (of a trip)”

• Qualities guide the search for ways of achieving goals

• Represented as curved, cloud-like shapes

42

Tasks
• A task represents actions that an actor wants to be executed

• Usually within the purpose of achieving a goal

• Examples:

• “Pay for tickets” • “Take the train” • “Scan the receipt”

• Represented as diamonds

43

Resources
• A resource is a physical or informational entity that an actor requires in order to perform a task
• Examples:

• Credit card
• Server
• Personal details

• Represented as rectangles

44

Intentional elements inside actor boundaries

45

Dependencies
• Social relationships are represented as dependencies

• A dependency is a relationship with ve arguments:

• Depender: an actor that depends for something (the dependum) to be provided

• DependerElmt: an intentional element within the depender’s actor boundary where the dependency starts
from, which explains why the dependency exists
• Dependum: an intentional element that is the object of the dependency
• Dependee: the actor that should provide the dependum
• DependeeElmt: the intentional element that explains how the dependee intends to provide the dependum.

46

Dependencies, an example
47

Omitting dependency parts

• Omitting the dependerElmt implies not specifying why the dependency exists

• Omitting the dependeeElmt implies not specifying how the dependency will be ful lled

48

Intentional Element Links

• The elements within an actor boundary are interrelated.

• But we have seen no ways to relate them so far.

49

Intentional element links: overview

• Four link types:

• Re nement • NeededBy
• Contribution • Quali cation
50

Re nement
• Re nement is a generic relationship that links goals and tasks hierarchically

• Two types of re nement

• AND: the ful llment of all n children (n 2) makes the parent ful lled • Inclusive OR: the ful llment of at least one child
makes the parent

ful lled

51

NeededBy
• The NeededBy relationship links a task with a resource and it indicates that the actor needs the
resource in order to execute the task

52

Contribution
• Four types, expressing that “the source provides...”

• Make: su cient positive evidence for the satisfaction of the target

• Help: weak positive evidence for the satisfaction of the target
• Hurt: weak evidence against the satisfaction (or for the denial) of

the target

• Break: su cient evidence against the satisfaction (or for the denial)

of the target
53

Quali cation
• The quali cation relationship relates a quality to its subject: a task, goal, or resource

• Examples:

• the quality “Quick booking” refers to the goal “Trip parts booked”, elaborating on how this goal might be achieved

• the quality “No errors” refers to errors possibly created while ful lling the goal “Request prepared”

54

• Requirements are still ambiguous & open-ended after elicitation, which leads to:

• Developers make decisions, which leads to:

• User <-> Dev di erence: User not satis ed • Dev <-> Dev di erence: Inconsistent system

• Overall: Higher cost!

• BUT:
• Goal is ideal PRODUCT not ideal Req Doc! • Thus: Req Analysis to reduce Risks!

Requirements Elicitation vs Requirements Analysis

• Requirements Elicitation:
• Purpose: nding out what customers want

• Requirements Analysis:
• Purpose: produce a system model that is correct, complete,

consistent, unambiguous

Requirements Analysis: Goal

• Fully understand the user requirements, remove in-consistencies, anomalies, etc. from requirements

Requirements Analysis Goals

• The process of analyzing requirements to:

• Detect and resolve requirements problems

• Decompose (elaborate) requirements
• Discover system boundary and how system must interact with its

environment

• Discover interactions and overlaps between requirements

 • Gain a better understanding of the problem

• Includes the following main activities: • Requirements classi cation

• Requirements negotiation • Requirements prioritization

• Quality of analysis directly a ects product quality • More rigorous analysis leads to better software
quality

Requirements Analysis
• Analysis and elicitation feed each other

• Analysis goes hand-in hand with modeling

Requirements Triage

Requirements Triage
Definition : Requirements Triage

• Requirements triage is the art of selecting the right requirements to include in the next release of
your product.

Davis Alan

• The word triage has originated from a French verb ”trier” which means to sort
• Some requirements must be included
• Some requirements should de nitely be excluded
• Some requirements are nice-to-have

Note

• Before applying prioritization techniques: perform triage

10

Why Requirements Triage

• Just enough elicitation!

• The desired schedule and the available budget can be insu cient to address all the requirements.
• Balance the desired requirements, the available budget, and the desired schedule.

11

Activities of Triage
• Calculating the resources required and the time needed

• Selecting requirements which can bring pro t and success when the given product is marketed

12

Requirements Triage
• Not doing triage guarantees that your organization is taking huge risks:

• The risk of satisfying the wrong requirements,

• The risk of promising to meet a schedule,
• The risk of agreeing to satisfy requirements for a given budget.

13

Requirements Classification :

Structuring Requirements
In order to better understand and manage the large number of requirements, it is important to organize
them in logical clusters

• It is possible to classify the requirements by the following categories (or any other clustering
that appears to be convenient)

• Features
• Use cases
• User class
• Responsible subsystem

• This makes it easier to understand the intended capabilities of the product

• And more e ective to manage and prioritize large groups rather than single requirements

14

Requirements Relationships
• The requirements are independent!

• In reality, this is rarely the case.

• The relationships that may exist between requirements:

• Necessity Dependency • E ort Dependency
• Subset Dependency
• Cover Dependency

15

Requirements Relationships
Necessity Dependency

In this relationship, it makes sense to satisfy requirement A only if we are also satisfying requirement B.

Example:

• Requirement A: The stop button shall be red.

• Requirement B: The system shall provide a stop button.

16

Requirements Relationships
Necessity Dependency

In this relationship, it makes sense to satisfy requirement A only if we are also satisfying requirement B.

Example:

• Requirement A: The stop button shall be red.

• Requirement B: The system shall provide a stop button.

16

Requirements Relationships
E ort Dependency

In this relationship, requirement A will be easier to satisfy if we are also satisfying requirement B.

Example:

• Requirement A: The system shall provide reports of accounts receivable older than 60 days.

• Requirement B: The system shall provide a general-purpose report-generation utility

17

Requirements Relationships
E ort Dependency

In this relationship, requirement A will be easier to satisfy if we are also satisfying requirement B.

Example:

• Requirement A: The system shall provide reports of accounts receivable older than 60 days.
• Requirement B: The system shall provide a general-purpose report-generation utility

17

Requirements Relationships
Subset Dependency

If requirement A is satis ed, then requirement B will be satis ed. That is, requirement B is part of
requirement A.

18

Requirements Relationships
Subset Dependency

If requirement A is satis ed, then requirement B will be satis ed. That is, requirement B is part of
requirement A.

• Re ne the parent requirement into three child requirements.

• If you select all the children, then you may also select the parent if

you wish.
• However, if you select the parent, you must select all its children.

18

Requirements Relationships
Cover Dependency

This is a special case of subset dependency in which the union of the children’s functionality is the
parent’s functionality.

• If requirements B, C, and D are satis ed, then requirement A will be satis ed; and
• If requirement A is satis ed, then requirements B, C, and D will be satis ed.

That is, requirements B, C, and D represent a re nement of requirement A.

19

Requirements Relationships
Cover Dependency

This is a special case of subset dependency in which the union of the children’s functionality is the
parent’s functionality.
 • If requirements B, C, and D are satis ed, then requirement A will be satis ed; and
• If requirement A is satis ed, then requirements B, C, and D will be satis ed.

That is, requirements B, C, and D represent a re nement of requirement A.

Veri cation: Are we building the system right?

• Are we building the product in the right way?

• It concerns the product building process.
• Does our design meet the spec?
• Does our implementation meet the spec?
• Does the delivered system do what we said it would do?

Validation Are we building the right system?

• Are we building the product that the customer

wants?

• Checks the software requirements speci cation against stakeholders goals and requirements
• It concerns the correctness of the product being built.

Di erence between Veri cation & Validation

• Veri cation is usually more technical activity that uses knowledge about the individual software
artifacts, requirements and speci cation.
• Validation usually depends on domain knowledge; that is, knowledge of the application for which the
software is written.

Veri cation & Validation: Recapitulation

• Both are important

• A well-veri ed system might not meet the user’s needs.

• A system can’t meet the user’s needs unless it is wellconstructed.

Veri cation & Validation

Some distinctions:

• Domain Properties: things in the application domain that are true anyway
• Requirements: things in the application domain that we wish to be made true
• Specification: a description of the behaviours the program must have in order to meet the requirements

Two verification criteria:

• The Program running on a particular Computer satis es the Speci cation • The Speci cation, given the
Domain properties, satis es the Requirements

Veri cation & Validation

Two validation criteria:

• Did we discover (and understand) all the important Requirements?

• Did we discover (and understand) all the relevant Domain properties?

10

Veri cation and Validation

• V&V process has two principal objectives

• The discovery of defects in a system

• The assessment of whatever or not the system is usable in an operational situation.

11

Validation Techniques

Validation in Requirements
Are we building the right system?

Close to the users/stakeholders

• Early Validation Informal Methods

• Use scenarios and mock-ups and/or prototypes

• Present the mock-ups while going through the scenarios

• Late Validation Formal Methods

• Read a speci cation document in an organized way

• Try to nd errors, inconsistencies, incompleteness

12

Validation Techniques
Scenario

• Can validate scenarios with users using semi-structured interviews (other techniques possible too)

• Strategies
• Read scenarios aloud together with users

• Ask if they have anything to add or change • Ask Why

13

Validation Techniques
Prototyping

Experiencing requirements directly through prototypes is the most e ective method to identify errors in
requirements.
Excellent for validation by users and customers

• More accessible than speci cation

• Demonstrate the requirements and help stakeholders discover

problems
• Help clarify fuzzy requirements • Help elicit reactions, e.g.:

• Yes, but...
• Now that I can see it working, it comes to me that I also need... • etc.

Jones 1998

14

Validation Techniques
Prototyping

A software prototype is a partial implementation constructed primarily to enable customers, users, or

developers to learn more about a problem or its solution.

Davis 1990

• Important to choose scenarios or use cases for elicitation session

• Come in all di erent shapes and sizes

• From paper prototype of a computerized system to formal executable

models/speci cations • Horizontal, vertical • Evolutive, throwaway

15

Validation Techniques
•

Prototype: Throwaway
Frequently - horizontal
• Implements a large portion of the

functionality

• Purpose

• Learn more about the problem or its solution

• Discard after desired knowledge is gained

• Use
• Early or late

• Approach

• Horizontal - build only one layer (e.g., UI)

• ”Quick and dirty”

• Advantages

• Cheap, can have bugs

• Early delivery → early testing → less cost
• Successful even if it fails!

• Disadvantages

• Wasted e ort if requirements change rapidly

• Often replaces proper documentation of the requirements
• May set customers’ expectations too high

Validation Techniques
•

Prototype: Evolving

Frequently - Vertical
• Implements a few functions better

• Advantages

• Supports changing requirements

• Return to last increment if error is found
• Cheaper =you’re not throwing the effort away

• Disadvantages

• Can end up with complex, unstructured system that is hard to maintain

• Early architectural choice may be poor
• Optimal solutions not guaranteed
• Lacks control and direction

• Purpose

• Learn more about the problem or its solution...

 • ...and reduce risk by building parts

• Use
• Incremental, evolutionary

• Approach

• Vertical - partial implementation of all layers

• Designed to be extended/adapted

Validation Techniques
Evolutionary vs. Throwaway prototypes
• Throw-away prototypes are not maintained once they have been

used.
• Evolutionary prototypes are developed with the goal to be

developed further and improved in later steps.

⇒ E ort to create evolutionary prototypes is much higher.

18

Validation Techniques
Requirements Review Types Di erent types of reviews with varying degrees of formality exist

• informal: from meetings over co ee, to regular team meetings

• formal: scheduled meetings, prepared participants, de ned agenda,

specific format, documented output

Both for validation and verification!

• Reading the document

• A person other than the author of

the document

• Walkthroughs
• Informal, often high-level overview • Can be led by author/expert to

educate others on his work

• Reading and approval (sign-o ) • Encourage the reader to be more

careful (and responsible)

• (Fagan) Inspections
• Very structured and detailed review,

de ned roles for participants, preparation is needed, exit conditions are de ned

• Always formal

19

Validation Techniques
Reading

• Authors reads
• Go section by section

• Evaluators hear/read it
• Give time for evaluators to read it

• Have questions prepared to stimulate discussion in case you get a passive audience

• Ensure the meeting focus on requirements not on how to build them or on the process.

20

Validation Techniques
Walk-through

More organized, but still informal !

Less preparation by other participants than in inspection

• ad hoc preparation
• Select participants

• Set date and location

• Highlight the importance of the stakeholders

• Prepare the material

• Have some hard copies

• Send the Material to be reviewed to participants

21

Validation Techniques
Inspection: De nition

According to Wiegers & Beatty:

Inspection is a type of formal peer review that involves a trained team of individuals who follow a well-
de ned process to examine a work product carefully for defects.

Laitenberger and DeBaud 2000

• Originally developed by Michael Fagan at IBM (1976)

• Inspections are the most commonly used review techniques to

 verify/validate requirements.

• Requirements inspection involves creating a team of inspectors that

should represent di erent perspectives.

• They can take several forms: Focused inspection, QA inspections

with pre-de ned criteria, etc

Veri cation: Are we building the system right?

• Are we building the product in the right way?

• It concerns the product building process.
• Does our design meet the spec?
• Does our implementation meet the spec?
• Does the delivered system do what we said it would do?

Validation Are we building the right system?

• Are we building the product that the customer

wants?

• Checks the software requirements speci cation against stakeholders goals and requirements
• It concerns the correctness of the product being built.

Di erence between Veri cation & Validation

• Veri cation is usually more technical activity that uses knowledge about the individual software
artifacts, requirements and speci cation.

• Validation usually depends on domain knowledge; that is, knowledge of the application for which the
software is written.

Veri cation & Validation: Recapitulation

• Both are important

• A well-veri ed system might not meet the user’s needs.

• A system can’t meet the user’s needs unless it is wellconstructed.

Veri cation & Validation

Some distinctions:

• Domain Properties: things in the application domain that are true anyway
• Requirements: things in the application domain that we wish to be made true
• Specification: a description of the behaviours the program must have in order to meet the requirements
Two verification criteria:

• The Program running on a particular Computer satisfies the Specification • The Specification, given the
Domain properties, satisfies the Requirements

Veri cation & Validation

Two validation criteria:

• Did we discover (and understand) all the important Requirements?

• Did we discover (and understand) all the relevant Domain properties?

10

Veri cation and Validation

• V&V process has two principal objectives

• The discovery of defects in a system

• The assessment of whatever or not the system is usable in an operational situation.

11
Validation Techniques

Validation in Requirements
Are we building the right system?

Close to the users/stakeholders

• Early Validation Informal Methods

• Use scenarios and mock-ups and/or prototypes

• Present the mock-ups while going through the scenarios

• Late Validation Formal Methods

• Read a speci cation document in an organized way

• Try to nd errors, inconsistencies, incompleteness

12

Validation Techniques
Scenario

• Can validate scenarios with users using semi-structured interviews (other techniques possible too)

• Strategies
• Read scenarios aloud together with users

• Ask if they have anything to add or change • Ask Why

13

Validation Techniques
Prototyping

Experiencing requirements directly through prototypes is the most e ective method to identify errors in
requirements. //Excellent for validation by users and customers

• More accessible than specification

• Demonstrate the requirements and help stakeholders discover

problems
• Help clarify fuzzy requirements • Help elicit reactions, e.g.:

• Yes, but...
• Now that I can see it working, it comes to me that I also need... • etc.

Jones 1998

14

Validation Techniques
Prototyping

A software prototype is a partial implementation constructed primarily to enable customers, users, or

developers to learn more about a problem or its solution.
Davis 1990

• Important to choose scenarios or use cases for elicitation session

• Come in all di erent shapes and sizes

• From paper prototype of a computerized system to formal executable

models/speci cations • Horizontal, vertical • Evolutive, throwaway

15

Validation Techniques
•

Prototype: Throwaway

Frequently - horizontal
• Implements a large portion of the functionality

• Purpose

• Learn more about the problem or its solution

• Discard after desired knowledge is gained

• Use
• Early or late

• Approach

• Horizontal - build only one layer

• ”Quick and dirty”

• Advantages

• Cheap, can have bugs

• Early delivery → early testing → less cost
• Successful even if it fails!

• Disadvantages

• Wasted e ort if requirements change rapidly

• Often replaces proper documentation of the requirements
• May set customers’ expectations too high

Validation Techniques
Prototype: Evolving

Frequently - Vertical
• Implements a few functions better

• Advantages

• Supports changing requirements

• Return to last increment if error is found
 • Cheaper =you’re not throwing the effort away

• Disadvantages

• Can end up with complex, unstructured system that is hard to maintain

• Early architectural choice may be poor
• Optimal solutions not guaranteed
• Lacks control and direction

• Purpose

• Learn more about the problem or its solution...

• ...and reduce risk by building parts

• Use
• Incremental, evolutionary

• Approach

• Vertical - partial implementation of all layers

• Designed to be extended/adapted

Validation Techniques
Evolutionary vs. Throwaway prototypes
• Throw-away prototypes are not maintained once they have been

used.
• Evolutionary prototypes are developed with the goal to be

developed further and improved in later steps.

⇒ E ort to create evolutionary prototypes is much higher.

Validation Techniques
Requirements Review Types Different types of reviews with varying degrees of formality exist

• informal: from meetings over co ee, to regular team meetings

• formal: scheduled meetings, prepared participants, de need agenda,

specific format, documented output

Both for validation and verification!

• Reading the document

• A person other than the author of the document
• Walkthroughs
• Informal, often high-level overview • Can be led by author/expert to educate others on his work

• Reading and approval (sign-o ) • Encourage the reader to be more careful (and responsible)

• (Fagan) Inspections
• Very structured and detailed review,

de need roles for participants, preparation is needed, exit conditions are de need

• Always formal

Validation Techniques
Reading

• Authors reads
• Go section by section

• Evaluators hear/read it
• Give time for evaluators to read it

• Have questions prepared to stimulate discussion in case you get a passive audience

• Ensure the meeting focus on requirements not on how to build them or on the process.
Validation Techniques
Walk-through

More organized, but still informal !

Less preparation by other participants than in inspection

• ad hoc preparation
• Select participants

• Set date and location

• Highlight the importance of the stakeholders

• Prepare the material

• Have some hard copies

• Send the Material to be reviewed to participants
Validation Techniques
Inspection: Definition

According to Wiegers & Beatty:

Inspection is a type of formal peer review that involves a trained team of individuals who follow a well-
de ned process to examine a work product carefully for defects.

Laitenberger and DeBaud 2000

• Originally developed by Michael Fagan at IBM (1976)

 • Inspections are the most commonly used review techniques to

verify/validate requirements.

• Requirements inspection involves creating a team of inspectors that

should represent different perspectives.

• They can take several forms: Focused inspection, QA inspections

with pre-de need criteria…

Process Flow Elements