Fundamentals: Application-domain R Requirements Speci catio Product Vision and Project Scope

A requirement
Derived from the application domain -> requires domain expertise. Describe system • The invention and de nition of the behavior of a new system (solution domain) such Product Vision: describes what the product is about and what it could
• Captures the purpose of the system
characteristics and features that re ect the domain. May be new functional Rs, that it will produce the required effects in the problem domain
eventually become • Aligns all stakeholders in a common direction

• Is an expression of the ideas to be embodied in the system/application under constraints on existing Rs, or de ne speci c computations. If domain Rs are not • Rs Analysis has de ned the problem domain and the required effects
satis ed, the system may be unworkable
Project Scope: identi es what portion of the ultimate long-term
development.
• A precise speci cation document is produced • A document that clearly and
Problems
precisely describes, each of the essential Rs (functions, performance, design product vision the current project will address • Draws boundary
• Is a statement about the proposed system that all stakeholders agre in order
for the customer’s problem to be adequately solved.
• Understandability - Rs are expressed in the language of the application domain -> between what is in and what is out

constraints, and quality attributes) of the software and the external interfaces • Each
• Short & concise information. Says something abt the system
often not understood by software engineers developing the system
R being de ned in such a way that its achievement is capable of being objectively Vision Statement
• All the stakeholders have agreed that it’s valid. Helps solve the customer’s • Implicitness / Tacit Knowledge
veri ed by a prescribed method (e.g., inspection, demonstration, analysis, or test) •
• Template: For [target customer] who [statement of the need or
problem
• Domain specialists understand the area so well that they do not think of Different guidelines and templates exist for Rs speci catio
opportunity] the [product name] is [a product category] that [key
• A statement which translates or expresses a need and its associated making the domain Rs explicit. People are often unaware of the tacit Requirements Veri cation and Validatio
knowledge they possess and therefore cannot express it to others
bene t, compelling reason to buy or use]. Unlike [primary
constraints and conditions [IEEE 29148-2011]
• Validation and veri cation • Both help ensure delivery of what the client wants •
Requirements Engineering: • Extract by not assuming, asking questions, observing, doing interviews/ Need to be performed at every stage during the process competitive alternative, current system, or current business process],
• A set of activities (performed throughout the development process) concerned with surveys, building models/prototypes.
• Validation: checks that the right product is being built (refers back to stakeholders – our product [primary di erentiation and advantages of new product]

eliciting, analyzing and communicating (communication is as important as analysis) Types of Rs main concern during RE) • e.g., For scientists who need to request containers of chemicals, the
the purpose (quality: tness-for-purpose, de ne quality after understanding Goal: (NOT yet a R)
• Veri cation: checks that the product is being built right • During design phase: refers Chemical Tracking System is an information system that will provide
purpose) of a (software-intensive) system, and the contexts (how and where) in • A goal is an objective/concern that guides the RE process. It can be used to back to the speci cation of the system or software Rs • During RE: mainly checking
a single point of access to the chemical stockroom and vendors. The
which it will be used. RE acts as the bridge between the real-world needs discover and evaluate veri able (all Rs must be) functional and non-functional Rs consistency between different Rs, detecting con icts
that can be tested objectively. A goal conveys the intention or objective of one or system will store the location of every chemical container within the
(unknown to the dev. team) of stakeholders (identify all stakeholders), a ected by • Techniques used during RE • Simple checks • Formal reviews • Logical analysis •
the system-to-be, and the capabilities and opportunities (what is possible? many stakeholders.
Prototypes and enactments • Design of functional test company, the quantity of material remaining in it and the complete
Unknown to the stakeholders) a orded by (software-intensive) technologies.
• e.g. The system should be easy to use by experienced controllers and should be Rs Managemen history of each container's location and usage. This system will save
• The activity of development, elicitation, speci cation, analysis, and management of organized in such a way that user errors are minimized. -> •  The system shall • Necessary to cope with changes to Rs the company 25% on chemical costs in the rst year of use by
the stakeholder Rs, which are to be met by a new or evolving system.
enable experienced controllers to use over 90% of the system functions after a • Rs change is caused by: • Business process changes • Technology changes • allowing the company to fully exploit chemicals that are already
• RE is the interdisciplinary function that mediates between the domains of the total of three hours of training. • The average number of errors using the system Better understanding of the problem
available within the company, dispose of fewer partially used or
acquirer and supplier to establish and maintain the Rs to be met by the system, made by experienced controllers shall not exceed two per day. • Assumption: An • Traceability (what we are doing can be traced back to high level R -> help assess
experienced controller has at least 2 years experience with the old system (as impact of change) is very important for effective Rs managemen expired containers and use a single standard chemical purchasing
software or service of interest

stated by the stakeholder)

Rs Documents process. Unlike the current manual ordering processes, our product
• RE is concerned with discovering, eliciting, developing, analyzing, determining
veri cation methods, validating, communicating, documenting, and managing Rs
Functional R: derived from goals
• Vision and Scope Document, Elicitation notes ((Raw) user Rs obtained through will generate all reports required to comply with government
Problems • De nes functions of the system under development. Describes what the system elicitation. Often unstructured, incomplete, and inconsistent), Rs document, regulations that require the reporting of chemical usage, storage, and
• Lack of the right expertise
should do. May be high-level statement but should describe a system service in System Rs document, Software Rs document (The software is normally part of a disposal.

• Initial ideas are often incomplete, wildly optimistic -> careful when presenting what detail. • What inputs the system should accept • What outputs the system should system that includes hardware and software
produce • What data the system should store other systems might use • What The Rs Analyst • The product vision may apply to many projects • Views of the
is possible

computations the system should perform • The timing and synchronization of the customer, of the enterprise • Evolves rather slowly

• Di culty of using complex tools and diverse methods -> negate the anticipated • Essential communication role
bene ts of a complete and detailed approach
above
• Talks to users: application domain • Talks to developers: technical domain • • The product scope focuses on one project • Important to the project
• Change management
• e.g. • The system shall provide access to a PDF viewer for the user to read Translates user Rs into functional Rs and quality goals manager • More dynamic than the vision • Can be part of a Rs
• Changing Rs
documents in the document store.
• Needs many capabilities document

Non-functional R: derived from goals, measurable (see table)

• R mismatch - customer’s needs has changed later

• Requirements focus on what is needed for the product to meet
• Interviewing and listening skills • Facilitation and interpersonal skills • Writing
• Analysis paralysis - try to accommodate for every change in the R docs -> • Describes a quality rather than a function of the system. Includes many kinds of Rs and modelling skills • Organizational abilit
business objectives • Many and rapid changes!

development process will not move further.

which are often categorized in sub-categories. If not met, system is useless.
The role of modelling in RE is best described by the Rs sandwich: one needs to
Project Viability – Scope
• Ways of mitigating the e ects of changing Rs
• Performance Rs re ecting: usability, e ciency, reliability, maintainability, and understand the “ oor” of one Rs layer to make it to the next “ceiling” of the next Rs
• Rs baseline
reusability (note: also security req.) • Response time, throughput • Resource usage layer; modelling helps analyze Rs and move to the next level of abstraction (from • Scope: product's purpose and the system's boundaries • How
• Good enough to proceed to design with an acceptable level of risk. • Reliability, availability • Recovery from failure • Allowances for maintainability and business to user to system to software Rs… much of the work will be done by the system-to-be-developed? •
Formally reviewed and agreed on. Subsequent changes managed enhancement • Allowances for reusability
Inception: How much of the work will be done by interacting systems?

through change-control process. Rough guide: limit changes to < • Design constraints: categories constraining the environment and technology of Problem Analysis • Information needed for cost and time estimates

0.5%/month (6%/year)
the system • Platform (minimal Rs, OS, devices…) • Technology to be used • To gain a better understanding of the problem being solved before development
(language, DB, …)
• De ne more precisely the problem to solve • List all the things the
• Business Rs: Identify the primary bene ts that a new system is expected begins. Identify root cause, stakeholders & their needs/problem, solution boundary.

system should have to do • Exclude as much as possible to reduce

to provide to its sponsors, buyers, and users
• Commercial constraints: Categories constraining the project plan and • Uses business Rs obtained from stakeholders

development methods • Development process (methodology) to be used • Cost the complexity of the problem • Establish broader goals if the
• Project scope
• Results in Product Vision and Project Scope

• Both allow new Rs to be vetted in, out, or in backlog

Business Requirements / Objectives: Can be modelled with goals (e.g., with GRL)
- 56% of defects introduced in R, 82% of e ort to x defect introduced in R
registration
and delivery date • Often put in contract or project plan instead
problem is too simple • Example: an automated system for university
• e.g. • Product R: It shall be possible for all necessary communication between the • Business Opportunity

- Not all agile projects actually follow agile practices, agility also allows projects to system and the user to be expressed in the standard ISO Latin 1 character set. • • Description of market opportunity, competing market, business problem being Context Diagram
fail (and restart) more quickly.
Process R: The system development process and deliverable documents shall solved/improved, advantage of proposed solution... Example: Exploit the poor
- Rs are captured by di erent means in agile process (user stories, acceptance conform to the process and deliverables de ned in MIL-STD-498. • Security R: The • A graphical representation of the boundary between the work and
security record of a competing product

system shall not disclose any personal information about customers apart from external entities & information ows between them

tests, wireframes…)
• Business Objective and Success Criteria

Levels of Rs their name and reference number to the operators of the system.
• Important business bene ts the product will provide in a quantitative and • Work = some combination of software/hardware/human components

• An application-domain R (sometimes called business rule) is a R derived from Emergent Properties: Properties of the system as a whole
measurable way, how success will be measured, factors that have great impact • External entities = users or interacting systems

business practices within a given industrial sector, or in a given company, or
de ned by government regulations or standards
(work) and its environment • Clear de nition is extremely important
• May lead to system Rs (can be functional or non-functional)
• Business Risks • Major risks associated with developing or not developing the
• E.g. library system must comply with standard Z39.50. health information
product (marketplace competition, timing, user acceptance, implementation
system must comply with Ontario’s personal health information protection act.
• Rs that cannot be addressed by a single component, but that depend for their on success... Examples: Achieve positive cash ow on the product within 6 • The system boundary de nes the separation between the system
satisfaction on how all the software components interoperate • Only emerge once all months; Get 50%+ of the market
individual subsystems have been integrated • Dependent on the system architecture.
• Movement of the system boundary often has a large e ect on what
e.g. • Reliability • Maintainability • Performance • Usability • Security • Safety
Main Rs Activitie issues…)

should be built • A common area of con ict between stakeholders

Seals shed every 9 months!
• Rs elicitation: process through which the acquirer and the suppliers of a system • Important for ensuring that all project participants work for the same reasons, and
arises when they assume di erent system boundaries, and hence
• A user R is a desired goal or function that a user and other stakeholders expect discover, review, articulate, understand, and document the Rs on the system and getting stakeholders agreement on Rs
refer to di erent systems!

the system to achieve. Does not necessarily become a system R

the life cycle processes • User/system/software Rs must align with the context and objective de ned by Vision and Scope Document
• A system R is a R for the system to be built, as a whole
• Gathering of information: About problem domain, problems requiring a solution, business Rs. Rs that do not help achieve business objectives should not be • Business Rs • Vision of the solution • Including major features and
• A system is a collection of interrelated components working together towards constraints related to the problem/solution. Questions that need to be answered • included
dependencies • Scope and limitation • For initial and subsequent
some common objective (may be software, mechanical, electrical and What is the system? • What are the goals of the system? • How is the work done Root causes: the problem behind the problem

releases • Business context • Including priorities and operating

electronic hardware, and be operated by people). Systems Engineering is a now? • What are the problems? • How will the system solve these problems? • How • Root cause analysis: nding underlying causes that may not be immediately
multidisciplinary approach to systems development – software is only a part will the system be used on a day-to-day basis? • Will performance issues, legal apparent
environment • Risks!!!
(but often the problematic part). In software system, software Rs are derived issues, or other constraints affect the way the solution is approached? • Sources • • Determine recursively what factors contribute to the problem

from the system Rs

Customers and other stakeholders • Existing systems • Documentation • Domain • Example: Our ecommerce site is not pro table, why? • Poor site design? • Bad
Business R -> experts • Techniques • Brainstorming • Interviews • Task observations • pricing? • Poor customer management after the sale? • Some or all of the above?

Questionnaires • Use cases / scenarios • Prototypin • Address Root Causes

• Rs validation: con rmation by examination that Rs (individually and as a set) • Root causes do not all have same impact, some may not be worth xing now

de ne the right system as intended by the stakeholders • Rs veri cation: • Estimate relative impact of root causes(Pareto): 20% of causes -> 80% of problems

con rmation by examination that Rs (individually and as a set) are well formed • Create problem statement for root cause problem identi ed as worth solving (and
• Rs management: activities that ensure Rs are identi ed, documented, maintained, with computer solution)

communicated and traced throughout the life cycle of a system, product, or service
• Software Rs speci cation: structured collection of the Rs (functions, performance,
design constraints, and attributes) of the software and its external interface
R Analysi
• The process of studying and analyzing the needs of stakeholders (e.g., customer,
Problem Statement
• The problem of [describe the problem] a ects [the stakeholders
a ected by the problem] the impact of which is [what is the impact of
the problem?]. A successful solution would be [list some key bene ts of
a successful solution]

user) in view of coming up with a “solution”, often linked to modellin
• Solution may involve: • A new organization of the work ow in the company • A new
system (system-to-be, also called solution domain) which will be used in the
existing or modi ed work ow • A new software to be developed which is to run
within the existing computer
system or involving modi ed
and/or additional hardware
• Restaurant Management Application • The problem of ine ciently
running a restaurant including waiting and kitchen sta a ects
customers of a restaurant, the impact of which is reduced levels of
service and lower food quality. A successful solution would be
supporting waiting and kitchen sta with up-to-date information on
pending orders and food inventory levels leading to improvements in
customer experience at the restaurant.

• Objectives • Detect and resolve • Hurricane Forecasting application which allows researchers to run
con icts between Rs (e.g., simulations and the general public to subscribe to warning messages •
through negotiation) • Discover The problem of disinformation in emergency situations caused by
the boundaries of the system / hurricane-force winds a ects the general public, the impact of which is
software and how it must a greater risk of loss to life and property. A successful solution would be
interact with its environment • providing timely warning messages to the general public based on
Elaborate system Rs to derive advanced scienti c simulations.

software Rs
ff
ffi
fi
fi
fi
fi
fi
fi
fi
fl
fi
fi
fi
fi
s

fi
ff
fi

fi

fl
t

fi
fi
s

fi
fi
fi
fi
fi
fl
fi
fi
fi
ff
fi

ff
ff

fi
fl

fi
fi
fi

ff

fi
ff
fi
ff
ff
fl

fl

fi
ffi
fi
y

ff
fi
n

ff
fi
)

fi
fi
fi
fl
fl
fl
fi
g

fi

fi
fi
s

ff
fl

ff
fi
ffi
n

fi
ff
g

fi
e­­­­­­
fi

fi
ff
s

Elicitation
User Requirements Notation (URN)
Goals: determine sources of information & appropriate techniques, get information
on domain, problem, constraints -> produce a rst document (user Rs and elicitation
notes)
Problems:
described in such a way that it is feasible and objectively veri able by a prescribed
scope: System boundaries inadequately de ned/de ned too soon, unnecessary
technical details
understanding: SHs not sure of what is needed/has trouble communicating needs,
UCM: focus on answering “what”
don’t understand capabilities & limitation of computing environment, don’t have full
understanding of domain, state con icting Rs.
Speci cations»: Describes the content and qualities of a good software requirements
volatility: SHs will not commit to a set of written Rs
reasoning about scenario interactions, performance, and architecture. UCM provide:
other: Experts not available, SHs lack motivation/resist to change, common
vocabulary missing. Need creative thinking.
Sources of Rs
Various SHs: Clients, customers, users (past and future), buyers, managers, domain
and completeness. Connections to goal models. Smooth transition to design models
experts, developers, marketing and QA people, lawyers.
Pre-existing/competing systems
Pre-existing documentation/documentation about interfacing systems
Standards, policies, collective agreements, legislation
SHs
scenarios and allow reasoning about potential undesirable interactions; Provide
Owner/Client/Champion: person paying for the software to be developed (ultimate
SH); has the last say in what the product does. represented by a proxy
Customer/Buyer: person who buys software after it is developed. May be the same
systems (requirements) analysts; developers, programmers to implement the
as the client/user; or an o ce manager who buys software for her sta . Active
participant in the project.
Model goals and other intentional concepts – mainly for non-functional requirements,
Domain Expert: knows the problem domain work involved. Familiar with the problem
that the software must solve, typical users and their expectations, the environment in
Basis for agreement between the customers and the suppliers; reduce
which the product will be used, know about standards relevant to the project
Software Engineer: knows the technology and process. Represents the rest of the
development team, determines if the project is feasible, estimates the cost & time of
product development
or new machines; basis for enhancement requests
User: Experts of the current system/future system or competitors’ products; provide
suggestions on features/design; may have special needs/Rs. Interest groups: Expert
users, or with disabilities.
Others: Inspector, Market research specialist, Lawyer, Expert of systems that interact
with the system to be built. Negative SH (understand why they do not want the
project to succeed.)
contribution types are used for these links • Dependency Link • An actor (the
User Classes: categorized by di erences
access privilege/security levels, tasks performed during business operations,
features used, frequency they use the product, application domain experience &
computer systems expertise, platforms (desktop, laptop…), cultural background,
interact with the system directly/indirectly. Disfavored users (who should not have
access for legal, security, or safety reasons). Software agents, or bots
Persona
useful when real users are not available or are too numerous to interview; Important
class of user (unique needs and characteristics), include enough details to make the
persona seem real to the team. Fictitious representation. Not outliers or unlikely
cases. Ideally created from real data/encounters/observations (Personalizes,
empathy). Describes: behavior patterns, objectives, problems, abilities, attitudes,
environment, culture, demographic info. typical activities, drivers, goals, pain points
Characteristics of Personas: Vivid, Actionable, Real, Identi able, Exact, Detailed.
Rs Elicitation Tasks
Planning for the elicitation (why, who, when how, risk), during the elicitation (con rm
the viability of the project, understand the problem from the perspective of each SH
(empathy), extract the essence of SHs’ Rs (Possibly build models. Gaps in the model
behavior may indicate unknown or ambiguous situations), invent better ways to do
user’s work (Ask why documented Rs are desired. The client/user’s view can be
limited by past experiences, brainstorm Rs the SHs haven’t yet though of)), following
the elicitation (Analyse results to understand obtained information, negotiate a
coherent set of Rs acceptable by all SHs and establish priorities, Record results in
the Rs speci cation), repeat as needed. Elicitation is incremental (Driven by
information obtained)
Elicitation Plan
Objectives: Validate market data, explore usage scenarios, develop a set of Rs. Set
elicitation strategies & processes: Approaches used (Surveys (questionnaires),
workshops, interviews). Resulting products: Usually set of rough Rs. Deliverables
depend on objective and technique. un-organized, redundant, incomplete
Elicitation Techniques
Techniques: interviewing, brainstorming & design thinking, analysis of existing
(documentation, task observation/ethnography), questionnaires, workshops,
prototyping (pilot system), use cases, scenarios, and user stories, usage data
analysis
Artifact-Based Elicitation: learn as much as we can by studying documentation,
systems, artifacts, etc. before asking for SHs’ time. Including document studies,
similar companies, domain analysis, R taxonomies…
Stakeholder-Based Elicitation: acquire detailed information about the system-to-be
that is problem speci c or stakeholder speci c. Including: SH analysis,
questionnaires & interviews, observation & ethnography, personas, ask suppliers,
domain workshop, task demo
Model-Based Elicitation: re-express the requirements in a di erent language, which
can raise new questions. Including: modeling, scenarios & stories, analysis patterns,
mockups & prototyping, pilot experiments
Creativity-Based Elicitation: to invent undreamed-of requirements that bring about
innovative change and gives competitive advantage. Including: brainstorming, design
thinking, creativity workshop, constraint relaxation.
Data-Based Elicitation: use data as much as possible to drive decisions related to
which requirements or features are relevant to stakeholders. Including: usage data
analysis
 develop. Variability = complexity.
Interviews: useful for asking targeted, stakeholder-speci c questions. Useful for
isolating and identifying con icts. Key points: open questions, good listening skills
(focusing on what the stakeholder is saying; giving the stakeholder some time to
articulate an answer), preparation & good communication management, interview as
many stakeholders as possible, ask problem-oriented questions (ask abt details but
don’t include details & solution speci c questions). Objectives: Record information
to be used as input to requirements analysis and modeling. Discover information
from interviewee accurately and e ciently. Reassure interviewee that his/her
understanding of the topic has been explored, listened to, and valued.
fl
ff
fi
ffi
ff
ff
fi
fi
fi
fi
fi
fi
ff
fi
fi
fi
ff
fi
fi
fi
fi
fi
fi
ffi
fi
fi
fl
fi
ff
ff
fi
ff
fi
Process: Planning and preparation: set goals and objective, acquire background Requirements Speci cation (IEEE 830 & IEEE 29148 Standards)
knowledge, prep questions. Interview session: be polite and respectful, interview Clearly & accurately describes the essential requirements (functions, performance, • modelling with URN as a whole, goals are operationalized into task/feature and
several people at once to create synergy. Consolidation of information: Revise & design constraints, and quality attributes) of the system/software and its external then elaborated in UCM path elements & scenarios. -> moving towards “how”
complete the elicitation notes after the interview, identify inconsistencies and interfaces (scope & boundaries of the system/software). Each requirement must be • Enables the elicitation/speci cation of systems, business processes and goals,
address them in a follow-up, be precise with terminologies… Follow-up.
standards, and products, as well as their analysis/validation from various angles
Pros: Rich collection of information and insights. Can probe in depth. Can adjust method. Basis for contractual agreements between contractors or suppliers and • Goal-oriented, feature-oriented, and scenario-based framework including analysis
format based on feedback. Allows for follow-up questions. Can assess nonverbal customers. Elaborated from elicitation notes. Intended for a diverse audience and reasoning about trade-o s and feature interactions at the requirements level
clues for opinions, feelings, motives, as well as hard-to-determine facts. Cons: Large (Di erent levels of detail & formality for each audience).
amount of qualitative data can be hard to analyze. Responses can be hard to IEEE 830-1998 Standard «IEEE Recommended Practice for Software Requirements Model scenario concepts • Causal relationships between responsibilities • Mainly for
compare and analyze. Relies on skillful interviewer
operational requirements, functional requirements, and business processes • For
Brainstorming & Design Thinking speci cation (SRS)
Brainstorming: invent new way of doing things or when much is unknown (little ISO/IEC/IEEE 29148:2018 «Systems and software engineering — Life cycle Visual description of behavior superimposed over entities (from stakeholders and
expertise, terrain, innovation needed), early in the project. Two main activities: storm: processes — Requirements engineering»: Provides a uni ed treatment of the users to software architecture to hardware). Easy graphical manipulation of scenario
generating as many ideas as possible; quantity over quality; look to combine processes and products involved in engineering requirements throughout the life descriptions. Single scenario view / combined system view. Enhanced consistency
suggested ideas; no criticism or debate. calm: ltering out (review, consolidate, cycle of systems and software
combine, clarify, improve) of ideas to keep the best ones-may require voting (with • Do IEEE 830 or IEEE 29148 o er standard templates for requirements (e.g., message sequence charts). Connections to performance models and testing
threshold/campaign speeches) -> Categorize into “maybe” and “no”; use ranking/ speci cations? If yes, for which types of requirements speci cations? • Yes, IEEE models. Why UCM? Bridge the modeling gap between abstract and informal
scoring methods. Objectives: hear ideas from everyone, especially unconventional 830 provides standard templates for software requirements speci cations and IEEE descriptions, useful at early stages of system development and more formal and
ideas, encourage creativity. Roles: Scribe: write down all ideas; may ask clarifying 29148 provides templates for business (BRS), stakeholder (StRS), system (SyRS), concrete descriptions useful at later stages of system development; integrate many
questions during rst phase but without criticizing. Moderator/Leader: cannot be the and software requirements speci cations (SRS).
scribe, enforces rules of order, but does not throw his/her weight around otherwise; • For whom are requirements speci cation documents meant? • For a diverse ability to model dynamic systems where scenarios and structures may change at
tra c cop plus more of a leadership role, comes prepared with wild ideas and throws audience: customers and users for validation, contract, capturing their needs; run-time
them out as discussion wanes. Participants: any SHs
Scenario Traversal Mechanism: Deterministic/non-deterministic
Joint Application Design (JAD): A more structured and intensive brainstorming system; quality assurance personnel to check that the requirements have been GRL: focus on answering “why”.
approach. Three phases: Customization, Session, Synthesis. Six (human) roles: met; project managers to measure and control the project.
Session leader, Analyst, Executive sponsor, User representatives, Information system • Discuss three bene ts of using a standard such as ISO/IEC/IEEE 29148:2018. • quality attributes, rationale documentation, and reasoning about alternatives and
representatives, Technical expert on information systems, Specialists
trade-o s. GRL is used to: Visually describe business goals, stakeholders’ priorities,
Design Thinking: creative strategy for solving problems, user-centered; divergent development e ort (forced to consider requirements early – reduces later redesign, alternative solutions, rationale, and decisions. Decompose high-level goals into
thinking, then convergent thinking. Tools: persona, user story map, oor plan, story recoding, retesting); basis for realistic estimates of costs and schedules; basis for alternative solutions called tasks (operationalization). Model positive/negative
board, 2*2 matrix, customer journey map, empathy map (perspective of one validation and veri cation; facilitate transfer of the software product to new users in uences of goals and tasks on each other. Capture dependencies between actors
stakeholder, related to persona: says, does, thinks, feels)
(i.e., stakeholders)
Analysis of Existing Systems:
Notation: • Achievement of softgoal is quali able but not measurable; it is
Useful when building a new improved version of an existing system. Important to quanti able for goals • Task is a proposed solution that achieves a goal or satis es
know: what is used, not used, or missing; what works well, what doesn’t work, how (satis ces) a softgoal • Belief captures rationale • Actors (Stakeholders) are the
the system is used and how it’s supposed to be used. Why analyze? To nd out holders of intentions • Contribution and Correlation Links • Contribution describes
which legacy features can/can’t be left out; to catch obvious possible improvements; desired impact, correlation shows side e ects • Qualitative or quantitative
to appropriately consider real usage patterns, human issues, common activities.
Observation: get into the trenches and observe specialists in the wild; session depender) depends on another actor (the dependee) for something (the dependum),
videotaping; shadow important potential users as they do their work, silent e.g. the business owner depends on the online shopper for payment (the dependum
approach/ask user to explain everything she’s doing. Pros: Highly skilled users may is optional) Why GRL? Goals become an important driver for requirements
do complex things without having to explicitly think about the individual steps, some elaboration. GRL expresses and clari es tentative, ill-de ned, and ambiguous
tasks are complex and have many subtle facets -> hard to articulate -> watch & requirements (Supports argumentation, negotiation, con ict detection & resolution,
learn. Cons: Observed people can be conscious of the presence of external and in general decisions. Captures decision rationale and criteria (documentation!)).
observers and change their behaviour accordingly
GRL identi es alternative requirements and alternative system boundaries; provides
Apprenticeship: Learn the job with a master by observation, asking questions, doing clear traceability from strategic objectives to technical requirements; allows reuse of
some of the job under supervision
stable higher-level goals when the system evolves
Ethnography: attempts to discover social, human, and political factors, which may Goal Model Semantics: • AND decomposition: minimum of satisfaction values of
also impact Rs. Focus on existing solutions; subtle but important nuances; may child elements (e.g., –50 is less than 80 and 0) • IOR and XOR decomposition:
clarify disagreements among SHs; take months; only observations (ask for puzzling maximum of satisfaction values of child elements (e.g., 80 is more than 0 and –50)•
phenomena)
Standard propagation in GRL models: dependencies • Dependency links constitute
Questionnaires:
the maximum, allowed satisfaction value (a source can never have a higher
Pros: Can reach large number of people, possibly in an anonymous way; Cheap, satisfaction value than a target connected with a dependency link; e.g., –75 is less
asynchronous, distributed, and can be quick to answer. Cons: preparation time, than 0 and 100 (the result of the contribution)) • Std. propagation in GRL models:
open-ended/closed; validity of questions; choice of answer scale (avoid centralist/ contributions • Weighted sum of child satisfaction values (e.g., [(–50x50) + (80x100) +
left-choice). Questions: demography, attitudinal (what do you think of …?), open (0 x –50)] / 100 = 55), limited to the range of [–100, 100] for GRL satisfaction values
question.
Strategies and Evaluation Mechanism
Prototyping
• The goal model allows a particular con guration of intentional elements to be
Sketch the essence of a solution and use it to bait stakeholders into providing new de ned in a strategy (i.e., one possible solution) • Sets of user-de ned initial
requirements details, thus helping to clarify and complete requirements; A software satisfaction values for elements, captured separately from the goal model •
requirements prototype is a mock-up or partial implementation of a software system; Strategies can be compared with each other for trade-o analyses
is e ective in resolving uncertainties early in the development process. Evolutive: • In order to analyze the goal model and compare solutions with each other, a
turned into a product incrementally, gives users a working system more quickly. customizable evaluation mechanism executes the strategies • Propagating levels to
Throw-away: less precise, thrown away, focusing on the less well understood the other elements and to stakeholders shows impact of proposed solution on high
aspects of the system to design, designed to elicit or validate Rs. Forms: paper level goals for each stakeholder • Propagation starts at user-de ned satisfaction
prototypes, screen mockups, interactive prototypes, models. Fidelity: the extent to levels of intentional elements (usually bottom-up) • Takes into consideration: initial
which the prototype is real and (especially) reactive; may vary for throw-away satisfaction levels of intentional elements, links and contribution types, and
prototypes, high- delity (Applications that "work" – you press a button and importance de ned for intentional elements • Qualitative or quantitative
something happens, involves programming/executable modelling languages. Pros: interpretation
provides an understanding of functionality, reduce design risk, more precise verdicts • Bottom-up analysis • Typically propagates satisfaction values of low-level tasks
about Rs; Cons: takes time to build, more costly to build, sometimes di cult to (i.e., selected solutions) to those of high-level stakeholder goals
change, false sense of security), low- delity (not operated, static. Pros: easy and • Top-down analysis • Searches for the optimal result taking the structure of the goal
quick to build, cheaper to develop, excellent for interfaces, encourage creativity. model and the relationships between nodes in the goal model into account • Can
Cons: may not cover all aspects of interfaces, are not interactive, may seem non- be formulated as a planning problem • Is akin to a constraint solving approach
professional in the eyes of some SHs). • Full feedback loop with the help of GRL variables • Shared with UCM models •
Used for conditions in UCM models • May be changed in UCM models to trigger a
Feature Modelling di erent GRL evaluation result
Software Product Lines (SPL): Software-intensive systems come in many •Quantitative Approach • Contribution types: [-100, 100] • Importance: [0, 100] •
variants. Families of Software Products: A set of programs is considered to Quantitative satisfaction levels: [-100, 100]
constitute a family, whenever it is worthwhile to study programs from the set by rst •Qualitative Approach • Contribution types: from Make to Break • Importance: High,
studying the common properties of the set and then determining the special Medium, Low, or None • Qualitative satisfaction levels
properties (variability) of the individual family members. SPL engineering: Factoring •Mixed (Hybrid) Approach also possible • Qualitative contribution types •
out commonalities for reuse. • Managing variabilities for software mass Quantitative importance and satisfaction levels
customization. Variability: « the ability of a system to be e ciently extended, •Relative Approach • Contribution types: any number • Quantitative satisfaction
changed, customized or con gured for use in a particular context ». Bene ts: levels: [0, 100]
Improve product reliability, usability, consistency across products. • Reduce Indicators:
production costs, certi cation costs. Shorten time-to-market. Production cost •measure functional and non-functional properties in terms of the domain units.
reduced by 75%. Development time reduced by 33%. Reported defects reduced •Conversion Function: convert real world value provided either manually or by BI
by 96%. Challenges: family of software systems is much more challenging to tool to satisfaction values, extensible. Types: Linear interpolation. Mapping of
qualitative real-world values to qualitative or quantitative GRL values.
Feature Model:
Describes the commonalities and variabilities of members in a SPL. De ne product
space.
Domain Requirements Engineering: Elicit requirements and scope the software
product line. Variability modeling: determine commonalities and variabilities usually in
terms of features.
Domain Engineering: build the infrastructure for the whole product family
Application Engineering: build one particular product
Con guration: feature selection (valid / invalid, complete / incomplete)
ffi
fl
fi
fi
fi
fi
ff
fi
fi
fi
fi
fi
fi
ff
fi
fl
fi
fi
ffi
fi
fi
fi
ff
fi
fi
fi
fl
ff
fi
ffi
fi
fi
fi
fi
fi
 Requirements Modeling with UML Software Quality: goes beyond functional Rs; Most de nitions require compliance Rs Management
Model Analysis: by construction (questioning and describing the system), by with Rs
Rs Volatility: The number of Rs changes (addition, deletion, modi cation) in a
inspection (Execute/analyze the model, reliable?), by formal analysis (Requires formal Quality measures:
speci ed time interval. Stable Rs: concerned with the essence of a system and its
semantics and tools, reliable but expensive), by testing (Execution, simulation, test; Quanti cation: Non-functional requirements need to be measurable. A t criterion application domain. Derived from the client’s principal business activities or the
More reliable than inspection for certain aspects, Requires well-de ned semantic s quanti es the extent to which a quality requirement must be met (values must have domain. Volatile Rs: speci c to the instantiation of the system in a particular
and execution tools)
rationale; stakeholders must understand trade-o s; important to rank & prioritize the environment for a particular customer at a particular time.

Qualities of a good model: • Abstract • Understandable • Accurate • Predictive • Rs; unlikely to be known at the beginning).
Problems: Rs/feature creep: Rs changing towards the end of development without
Inexpensive
Metric: mean time between failures; measurement: 23 days between failures (speci c any impact assessment. Unmatched/outdated Rs speci cations causing confusion
The act of re-expressing the owner’s work or requirements as models in di erent observation)
and avoidable rework

languages often reveals “holes” in our understanding

Confusion matrix: precision = TP/test outcome positive; accuracy = TP+TN/total; Rs Management: A systematic approach to eliciting, organizing, and documenting
Types of UML diagrams: • Structural: Class, object, composite structure, recall = TP/condition positive
 the requirements of the system, and a process that establishes and maintains
component, and use case diagrams • Dynamic: State machine, activity, sequence, Performance measures: Response time, number of events processed/denied in agreement between the customer and the project team on the changing
communication, timing, and interaction overview diagrams • Physical: Deployment some interval of time, throughput, capacity, usage ratio, jitter, loss of information, requirements of the system.

diagrams • Model Management: Package diagram
 latency... (Usually with probabilities, con dence interval). Can be modeled and Requirements Management Activities: Manage changes to agreed requirements •
UCM and Activity Diagrams comparisons: • Responsibility <-> action, start/end simulated (at the architectural level) – performance prediction: • Queueing model Manage changes to baseline (increments) • Keep project plans synchronized with
points, alternatives, concurrency • Stub / plug-in <-> action / sub-activity diagram • (LQN), process algebra, stochastic Petri nets • Arrival rates, distributions of service requirements • Control versions of individual requirements and versions of
Association between elements and components / partition • Unique to Activity requests • Sensitivity analysis, scalability analysis
requirements documents • Manage relationships between requirements • Managing
Diagrams • Data ow modeling, with rich data • Integration with UML (including class Performance Rs: • The system shall be able to process 100 payment transactions the dependencies between the requirements and other documents/artefacts
diagrams and OCL) • Unique to UCM • Dynamic stubs with several plug-ins • Plug- per second in peak load. • In standard workload, the CPU usage shall be less than produced in the systems engineering process • Track requirements status

ins can continue in parallel with their parent model • 2D graphical layout of 50%.
Expectations: identi cation, traceability (from highest level Rs to implementation),
components • De nitions of scenarios (integrated testing capabilities) • Integration Reliability Measures: Measure of the degree to which the system performs during a impact assessment, controlled assess, change control

with Feature Models and GRL in URN

request: Ability to perform a required function under stated conditions for a speci ed Identi cation techniques: Dynamic renumbering, Database record id, Symbolic id
• Is formal logic always better than natural language? • Although formal languages period; important for critical, continuous, or scienti c systems • Can be measured (giving them a symbolic name which is associated with the requirement itself, e.g.,
may be analyzed automatically including formal proofs, formal languages are also using defect rate, degree of precision for computations. E.g., The precision of SEC1)

more di cult to learn and understand • In contrast, natural language speci cations calculations shall be at least 1/106. • The system defect rate shall be less than 1 Rs attributes: • Creation date, Last update • Author, Stakeholders (Owners / Source)
are more accessible to stakeholders with any kind of background
failure per 1000 hours of operation.
• Version number • Status, Priority/Importance, Stability, Con dence/Certainty, Risk •
• Why do we need domain models in requirements engineering? • Why must class Availability Measures: Percentage of time that the system is up and running correctly. Rationale, Comments • Acceptance criteria, Test result, Veri cation method •
diagrams be sometimes supplemented by constraints? • To capture concepts and Can be calculated based on Mean-Time between Failure (MTBF) and Mean-Time to Subsystem / Product release number

their relationships (i.e., the domain vocabulary) in an unambiguous way • Not Repair (MTTR) • MTBF: Length of time between failures • MTTR: Length of time Rs Statuses: Help manage the requirement lifecycle (depends on process in place). •
everything can/should be expressed with class diagrams • Constraints typically allow needed to resume operation after a failure • Availability = MTBF/(MTBF+MTTR) • Proposed: by some stakeholder • Approved: part of baseline, committed to
for a simpler class diagram while at the same time capturing richer domain-speci c architectural requirements: Redundant components (backup); Modi ability of implement • Rejected: after evaluation • Implemented: designed and implemented •
rules
components. Special types of components (e.g., self-diagnostic). E.g., • The system Veri ed: Relevant tests have passed • Deleted: Removed from list

• Why are Hierarchical State Diagrams useful? • Why spend time documenting shall meet or exceed 99.99% uptime. • The system shall be available at least 999 Traceability:
lifecycles of documents and objects? • Hierarchical State Diagrams often simplify a hours per 1000 hours of operation. • The system shall need less than 20 seconds to Refers to the ability to describe and follow the life of a requirement, in both forwards
state model, because one group transition replaces multiple occurrences of the restart after a failure 95% of the time. (This is an MTTR requirement)
and backwards direction, helps assess the impact of changes to requirements,
same transition • A clear understanding of the lifecycle of documents and objects Security Measures: 1. The ability to resist unauthorized attempts at usage 2. connecting these requirements as well as requirements for other representations of
may clarify requirements that are important for the domain under discussion Continue providing service to legitimate users while under denial of service attack. the system

Measurement methods: Success rate in authentication. Resistance to known attacks Challenges: accessing & integrating data (distributed, heterogeneous data).
(to be enumerated). Time/e orts/resources needed to nd a key (probability of Knowing what we want. Connecting artifacts (interrelate SE artifacts, maintain links,
Use Cases and Scenarios nding the key). Probability/time/resources to detect an attack. Percentage of useful and use resulting network to answer questions of both the software product & its
Scenario: an instance of a use case, it expresses a speci c occurrence of the use services still available during an attack. Percentage of successful attacks. Lifespan of dev. process). Querying the data

case (a speci c path through the use case). Many scenarios may be generated from a password, of a session. Encryption level. architectural requirements • Planning traceability: who are the stakeholders? Their needs? De nition of links and
a single use case description. Each scenario may require many test cases.
Authentication, authorization, audit • Detection mechanisms • Firewall, encrypted attributes. Process (who collects and when to collect traceability information).
Types of scenarios: As-is scenario: Used in describing a current situation, usually communication channels. E.g., • The system shall identify a client application before Factors: • Number of requirements • Expected system lifetime • Maturity level of
used in re-engineering projects, the user describes the system. Visionary scenario allowing it to use system capabilities. • The application shall detect at least 99% of organization • Size of project and team • Additional constraints from customer

(To-be): Used to describe a future system, usually used in green eld engineering and intrusions within 10 seconds
Tracing mistakes: 1. Failure to plan: Most projects do not include a TIM 2. Ill-
reengineering projects. Can often not be done by the user or developer alone Usability measure: concerns ease of use and ease of training end users (learnability, de ned trace granularity leads to unacceptably high/low or mismatched links 3.
Evaluation scenario: User tasks against which the system is to be evaluated. Training e ciency, memorability, error avoidance, error handling, user satisfaction). Ex. The Redundant Trace Paths 4. Lack of unique project-wide IDs 5. Missing trace links 6.
scenario: Step by step instructions that guide a novice user through a system
system shall enable at least 80% of users to book a guest within 5 minutes after a 2- The DOORS dump – i.e., massive unstructured dumps of trace data 7. Traceability as
Use Case: Description of a sequence of interactions between a system and external hour introduction to the system.
an after-thought

actors to achieve user goals

Maintainability measure: Measures ability to make changes(add/removing Bene ts: Impact analysis. Change control. Process monitoring. Improved software
Actors: any agent that interacts with the system to achieve a useful goal. A subset of functionality) quickly and cost e ectively. Measured in terms of: Coupling/cohesion quality. Reengineering (record knowledge). Risk reduction (retain knowledge).
all identi ed stakeholders
metrics, number of anti-patterns, cyclomatic complexity • Mean time to x a defect, Supports the veri cation process.

Use case model: consists of a set of use cases and a optional description/diagram mean time to add new functionality • Quality/quantity of documentation. Ex. Every Baselines:
indicating how they are related
program module must be assessed for maintainability according to procedure XYZ • Non-modi able (read-only) version of a document (Describes a moment in time.
Use case modelling with UML: use case diagram May include multiple documents at the same time). access control.

• Inclusion <<include>>: express commonalities btw several di erent use cases. Requirements veri cation: “Are we building the product right?”
• Enables document comparison and management

Base use case explicitly references the included use case as needed at a location Requirements validation: “Are we building the right product?”
• Comes with a change history for the document • Information on objects, attributes,
in the base (e.g., with a hyperlink). Base use case cannot exist without the included Requirements V&V vs. Requirements Analysis: and links created, deleted, or edited since the creation of the baseline • Often also
use case. When included use case is done, control returns to base use case. 

Common: Reading requirements, problem analysis, meetings and discussions...
contains information on user sessions (when the document was opened, by whom…)

Disadvantage: must look in multiple places to understand use case

Rs analysis: works with raw, incomplete requirements as elicited from the system Change Management
• Extension <<extend>>: used to make optional interactions explicit/to handle stakeholders -> a software requirements speci cation document
Concerned with the procedures, processes, and standards which are used to
exceptional cases. By creating separate use case extensions, the description of Requirements V&V: works with a software requirements speci cation and with manage changes to requirements. Can have status. Cover: change requests, impact
the base use case remains simple • The extension adds new interaction steps to negotiated and agreed (and presumably complete) domain requirements. Check that assessment, traceability.

the base use case • Note: the base use case can still be executed without the use these speci cations are accurate
Tools:

case extension
Various Requirements V&V Techniques • Simple checks (tracing, verify Rs are well • Document (e.g., Word) • Easy to use, easy to access, simple training •
User stories: Pattern: As a <role>, I want <goal/desire> so that <bene t>.
written) • Prototyping • Functional test design (derive tests from Rs speci cation, Requirements are all stored in the requirements document • It is easy to produce the
• Ex. As a user, I want to indicate folders not to backup so that my backup drive is test-driven dev.) • Formal V&V (• Simulation • Testing • Completeness checking • nal requirements document • But: Traceability? Status reports? Granularity of
not lled up with things I do not need saved.
Consistency checking • Re nement checking • Model checking • Theorem proving) • requirements? Search and navigation facilities? Change management? Version
• Ex. As a manager, I want to browse my existing quizzes so I can recall what I have Reviews and inspections (semi-outsider, look for problems, widely used)
control? Analysis? Simultaneous access control?...

in place and gure out if I can just reuse or update an existing quiz for the position I Requirements Inspection Checklist • Database (e.g., DOORS) • Good for management, controlled access, links,
need now.
1. Do requirements exhibit a clear distinction between functions and data? 2. Do analysis, reports • Good query and navigation facilities • Support for change and
• Independent, negotiable, valuable, estimable, small, testable
requirements de ne all the information to be displayed to users? 3. Do requirements version management • But: hard (and costly) to con gure, manage, and use; link
Acceptance criteria(verify that): can include functional, performance and other address system and user response to error conditions? 4. Is each requirement stated between the database and the requirements document must be maintained ( nal
non-functional criteria.
clearly, concisely, and unambiguously? 5. Is each requirement testable? 6. Are there requirements document must be generated)

Negative scenarios: a scenario whose goal is undesirable from the business ambiguous or implied requirements? 7. Are there con icting requirements? 8. Are Wiki: • Requirement types description with con gurable statuses & attributes •
organization’s viewpoint. Desirable from a hostile agent’s viewpoint (not necessarily Writting Rs: there areas not addressed in the SRS that need to be? 9. Are performance Bidirectional links • Con gurable requests, ltering, reports • Access control and
human; negative stakeholder). Threaten. Mitigate. Bene ts: Elicitation of security and requirements (such as response time, data storage requirements) stated? 10. If the version management (showing di erences) • Change management (again with forms,
• Pitfalls: never describe how. No let-outs/escapes(if, but, when except, unless,
safety requirements • Early identi cation of threats, mitigations, and exceptions that although). Avoid ambiguity (or, etc, so on, user-friendly, highly versatile, exible, to requirements involve complex decision chains, are they expressed in a form that process, etc.) • Discussions, attachment of documents/images • Export (HTML) •
could cause system failure • Documentation of rationales. Risks: Get into premature the maximum extent, approximately, as much as possible, minimal impact). Do not facilitates comprehension (i.e., decision tables, decision trees, etc.)? 11. Have Scripting language (Perl) • Graphical view of traceability? • Editable tables (à la Excel/
design solutions in step 3 (mitigation) - Goal should be to nd requirements (safety, make multiple requirements and keep it short (and, or, with, also). Do not speculate requirements for performing software upgrades been speci ed? 12. Are there Word)? • Baselines? Tool integration? Imports? Analysis? …

security…) • Missing misactors and threats

(vague subject type and generalization words such as usually, generally, often, requirements that contain an unnecessary level of design detail? 13. Have the real- Suspect links:
• When are use cases more appropriate than user stories?1 • Many distributed normally, typically). Do not express suggestions or possibilities (may, might, time constraints been speci ed in su cient detail? 14. Has the precision and indicates that element may have been a ected by a change -> Proactively know
stakeholders with divergent/con icting interests (especially for “green- eld” should, ought, could, perhaps, probably). Avoid wishful thinking (100% reliable, accuracy of calculations been speci ed? 15. Is it possible to
developments) • Changes in one set of requirements cause changes to another set of safe, handle all failures, fully upgradeable, run on all platforms)
develop a thorough set of tests based on the information contained
requirements (no independence) • Third party (outside organizations) need to in the SRS? If not, what information is missing? 16. Have
understand your requirements • Regulations / certi cations Assumptions and Dependencies been clearly stated? 17. Does the
document contain all the information called out in the outline for the
SRS?
fi
fi
ffi
fi
fi
fi
fi
fi
fi
fi
fi
ffi
fi
fi
fi
fi
fi
fi
fl
fi
fi
fi
fi
fi
fi
fi
ff
fi
ff
fl
fi
ff
fi
ffi
ff
fi
fi
fi
fi
ff
fi
fi
fi
fl
fi
fi
fi
fi
fi
fi
fi
fi
fi
ff
fi
fi
fi
fi
fi
fi
fi
fi
fi
fl
fi
fi
fi
ff
fi
fi
fi
fi
Requirements Negotiation
Possible con icts: Con icts related to subjects, interests, values, relationships,
structure. • Between supplier and customers about costs, bene ts, risks • Power
struggle within customer organization • Con icts with other projects about resources
• Con icting goals, features, requirements. • Potential resolution strategies •
Agreement • Compromise • Voting • De nition of variants • Overruling • Mediation
(involves neutral third party that facilitates) • Arbitration (involves neutral third party
that judges) • Goal analysis (think GRL!)

Process:
• First, detect when requirements are inconsistent

• Then, convince all stakeholders to understand each other’s essential point of view •
Have each party explain what they believe the other party wants and why

• Reach an agreement on a coherent set of requirements that meets the needs of as

many stakeholders as possible • Analyze each party’s goals, nd solutions that do
not con ict but ideally support everybody’s goals

• Finally, document resolution • Stakeholders, alternatives considered, decision...

Rationales and GRL!

Requirements Triage and Prioritization

Di culties: There are too many requirements (more than can be implemented) from
many di erent sources. Limited resources. Con ict btw stakeholders.

Requirements Prioritization and Triage: • Rs prioritization = triage • Need to decide

which requirements really matter or on those that need to be implemented in the
current release à minimum viable product • Need for compromise, negotiation,
priorities • Prioritization is needed because there will almost always be the need for
trade-o s (e.g., required functionality vs. time and resources) – balance. • Must help:
• Make acceptable trade-o s among bene ts, cost, time-to-market • Allocate
resources based on importance of requirements to the project as a whole (project
planning) • Determine when a requirement should become part of the product • O er
the right product!

Techniques: Priority Ranking (Each requirement is assigned a unique rank, not

possible to see the relative di erence between ranked requirements). 100-Dollar Test
(In cumulative voting, or the 100-dollar test, stakeholders are given 100 prioritization
points to distribute among the requirements, most points win). Prioritization Scales
(Determine criteria, granularity, scale dimensions -> grouped requirements. Urgency,
importance.). Kano Surveys (a method for grouping requirements based on customer
perception, in order to select the requirements that deliver the greatest customer
satisfaction. Basic: requirements that the customer takes for granted Excitement:
requirements that the customer does not request or expect Performance:
requirements that the customer speci cally asked for Indi erent: requirements that
the customer does not care about Reverse: “requirements” that the customer hates).
Wiegers’ Prioritization (Semi-quantitative analytical approach to requirements
prioritization based on value, cost, and risk. Relies on estimation of weighted relative
priorities (bene t, penalty, cost, risk…) of requirements. priority = (value %) / ((cost %
* cost weight) + (risk % * risk weight)) ). Volere Prioritization (editable excel le, similar
to wieger’s technique)

Analytic Hierarchy Process (AHP): Useful for requirements triage and release
planning. • Analyzes stakeholders’ pairwise comparisons of requirements and
produces a relative ranking of requirements • Apply AHP’s pairwise comparison to
estimate the relative value of candidate requirements • Experienced software
engineers use AHP’s pairwise comparison to estimate the cost of candidate
requirements • Use cost-value diagrams to analyze and discuss candidate
requirements. Pairwise comparison: bene ts: • Indicates what is important to the
client • Identi es requirements of high value and low cost (priority!) • Identi es
requirements of low value and high cost (likely to be removed) • Has already been
used to assist numerous corporate and government decision makers. Problems:
large number, dependencies between Rs, complexity handle by grouping Rs per
features.
Functional Requirements:
di erent Stakeholders are grouped and weighted
Risk:
VaBeMaS shall allow HR Personnel to update the position of an
the e ect of uncertainty on objectives, probabilities. • Identify, characterize employee by providing the employee ID, the new position, and the
uncertainty (threats / opportunities) • Assess susceptibility of critical assets to start date of the position.

speci c threats / opportunities • Determine risks (i.e., potential damage / gain + VaBeMaS shall set the end date of the new position to null if no future
likelihood of occurrence) • Identify ways to reduce negative risks (mitigation) • employment exists that starts after the new position.

Prioritize risk reduction measures based on a strategy

VaBeMaS shall set the end date of the new position to the day before
Risk exposure (RiEx) is an expression of the degree of risk RiEx = prob(occurrence) X
cost(consequences)
the next future employment if future employment exists.

VaBeMaS shall set the end date of the previous employment to the
day before the start of the new position.

Problem Descrip on The Vaca on Bene ts Management System (VaBeMaS) is used by VaBeMaS shall reduce the unused vacation days of the previous
hundreds of thousands of government employees in various countries around the world. It employment by the prorated amount (e.g., if an employee receives 10
allows employees to indicate their desired vaca on requests, managers to approve or deny vacation days per year and the period of the previous employment is
such requests, and human resources (HR) personnel to enter informa on about bene ts now not a full year anymore but only half a year, then the unused
packages and compile company-wide sta s cs. To log into VaBeMas, a user enters her vacation days need to be reduced by 5 vacation days).

employee ID and password. When an employee is hired or changes posi on within the
Non-Functional Requirements
company, HR personnel update the bene ts package of the employee, which speci es the
number of vaca on days allowed per calendar year. For example, posi ons for a manager Specify one well-written security requirement, one well-written
may range from junior to mid-level to senior. A change in posi on may lead to a readjustment availability requirement, and one well-written usability requirement for
of available vaca on days. From me to me, bene ts packages are renego ated for some the proposed Vacation Bene ts Management System (VaBeMaS).

posi ons by the company and its employees, leading to new rules for all employees. Unused Security: VaBeMaS shall identify an employee before allowing the
vaca on days may be carried over to the next year up to a maximum number of accumulated employee to use the system. Availability: VaBeMaS shall meet or
vaca on days. The maximum number is also de ned by the bene ts package of an employee.
exceed 99% uptime.

A vaca on day counts as 7.5 hours by default, but this can be customized by the company's
HR personnel as a global se ng a ec ng all employees. When an employee enters a vaca on Usability: VaBeMaS shall enable at least 90% of employees to request
request, she speci es the start date and me and the end date and me. The mes are only vacation days within 3 minutes after a 15 minute introduction to the
required for par al vaca on days (e.g., half a day or three hours out of a 7.5 hour work day). system.

The system does not allow vaca on requests to be entered that exceed the available number
of vaca on days. All vaca on days for a calendar year are added to the available vaca on days
of an employee on January 1. Given the start date/ me and end date/ me of a vaca on
request, the system determines the actual number of vaca on hours taking holidays into
account and the employee's required work hours per day. The required work hours per day,
standard start me of a work day, lunch hour, and end me of a work day are all speci ed by
the employee's bene ts package. Once an employee has entered a request, the manager can
then either approve or deny the request. If the request is denied, a reason has to be given by
the manager. Who has approved or denied a request and why needs to be recorded by
VaBeMaS. A vaca on request may be cancelled before its start date or shortened before its
end date. Not all companies require the complete sta s cs module of VaBeMaS, which
reports on company-wide averages per month: vaca on days received, approved vaca on
requests, and denied vaca on requests. Furthermore, some companies do not allow vaca on
days to be carried over, while others do not require manager approval for vaca on requests.
ff
ffi
ti
ti
ti
ff
fi
fl
ti
ti
ff
fl
ff
fi
ti
fl
ti
ti
fi
ti
ti
ti
fi
fi
ti
ti
ti
fl
tti
ff
ti
ti
ff
ti
ff
ti
fi
fi
ti
ti
ti
fi
fi
fi
ti
fi
fi
fi
ti
fl
ti
fi
ti
fl
ti
ti
ti
ti
ti
ff
fi
fi
ti
ti
fi
ti
ti
ti
ti
ti
ti
fi
fi
fi
ti
ti
fi
fi
ti
ti
ff
ti