113 quiz 2

What are some examples of non-functional goals? (quality goals)

What are some examples of non-functional goals? (quality goals)

- security
- safety
- accuracy
- performance

What are some non-functional process goals?

- cost
- deadline
- scope

What are the 3 main information sources for requirements elicitation?

Documents, stakeholders, existing systems

What is requirements elicitation?

• activities involved in discovering the requirements of the system, including exploring the problem world

• Determine stakeholder desires and needs

• Elicit info from all available sources and consolidate it into well-documented requirements

• Make stakeholders happy, not just satisfy them

• Every elicited and documented requirement must be validated and managed

• Work value-oriented and risk-driven

Which types of requirements do stakeholders frequently neglect?

• Process requirements

• functional requirements

• quality requirements

• UI requirements

• constraints

quality requirements and constraints

What are some signs that requirements elicitation is "done" (or, good enough to proceed at an acceptable level of risk)? 

• stakeholders can't come up with anything new

• stakeholders repeat themselves

• new features are out of scope

• current requirements and functionalities don't have any gaps

In which types of situations are full-fledged, detailed, thorough requirements specifications typically needed?

• work is being done for an external client

• development/testing will be outsourced

• project team members are geographically dispersed

• System testing will be based on requirements

• Accurate estimates are needed

When should you use less detail on requirements?

• Work is being done internally

• Customers are extensively involved

• Developers have considerable domain knowledge

• Precedents are available, as weh n a previous application is being replaced

Which two qualities are most important for requirements?

correctness and understandability

What is the most commonly used template for user stories?

As a [role], I want [activity], so that [business value]

What words should you avoid when writing requirements?

Use/shall/will

You should avoid _________ terminology

imprecise

User stories should be INVEST. What does INVEST stand for?

• Independent

• Negotiable

• Valuable

• Estimable

• Sized appropriately (5-15 stories per sprint)

• Testable

What are some common user story pitfalls?

• Activity part is not an activity that can be done within the system

• Role is not an actual user of the system

• Acceptance criteria not detailed enough

• Missing a “so that” (business value)

• Trying to make non-functional requirements user stories

What are the major problems with natural language specs?

ambiguities, misinterpretation, incompleteness, contradictions

How can requirement templates help mitigate the pitfalls of natural language?

add structure

The most common way to express requirements in agile processes are….

user stories

Process

 a set of interrelated activities performed in a given order to process info or materials

What are the principal tasks of requirements specification?

• Elicitation + analysis

• Documentation

• Validation

What are the principal tasks of requirements management?

• Identification and metadata

• Requirements prioritization

• Change and release management

• Traceability

Requirements is/is not one-size-fits all

is not

The three process facets are

Time, purpose, and target

Different time process facets are…

linear and iterative

Different purpose process facets are…

prescriptive and explorative

Different target process facets are…

customer-specific and market-oriented

Linear time is when

requirements are specified up front in a single phase

you should select linear time if

• System development process is plan-driven and mostly linear

• Stakeholders can specify requirements up front

• Comprehensive requirements specs required as a contractual basis for outsourcing design and implementation

• Regulatory authorities require a requirements specification

iterative time is when

Requirements specified incrementally, starting with general goals then adding/modifying requirements in every iteration

Select iterative time if

• System development process is iterative and agile

• Evolving requirements – not known up-front

• Stakeholders are available; short feedback loops are established for mitigating risk

• Duration of project allows for more than 1-2 iterations

• Ability to change requirements easily is important

prescriptive purpose is when

Requirements specs is a contract – requirements binding, must be implemented

select prescriptive purpose if

• Customer requires a fixed-price contract

• Functionality determines cost and deadlines

  • Design and implementation tendered or outsourced

Explorative purpose is when you…

Only know high-level goals, concrete requirements have to be explored

Select explorative purpose when…

• Stakeholders only have a vague idea of their requirements

• Stakeholders  strongly involved, provide continuous feedback

• Deadlines and cost take precedence over functionality

• Customer is satisfied with framework contract

• Not a priori clear which requirements shall actually be implemented and in which order

Customer-specific target is when…

System is ordered by a customer and developed by a supplier for this customer

Select customer-specific target if …

• System will be mainly used by organization that has ordered the system + pays for development

• Important stakeholders are mainly associated with customer organization

• Individual persons can be identified for the stakeholder roles

• Customer wants a requirements spec that can serve as a contract

Market-oriented target is when the system is..

developed as a product/service for a market

Selected market-oriented target if…

• Developing organization or one of its clients intends to sell the system as a product or service in some market segment

• Prospective users not individually identifiable

• Requirements engineers have to design the requirements so that they match envisaged needs of targeted users

• Products owners, marketing people, digital designers, and system architects are primary stakeholders (e.g., social media sites)

Linear RE processes only work if…

there’s a sophisticated process for changing requirements is in place

Linear RE processes imply _______ feedback loops

long

Market oriented RE processes depend on ________ feedback from pilot users

fast

In an agile setting, a(n) iterative/linear and explorative/prescriptive work best? (select which two apply)

iterative, explorative

Common facet combos are:

• Linear + prescriptive

• Explorative + iterative

Market oriented does not mesh well with…

linear, prescriptive

The “participatory” combo is …

iterative + explorative + customer-specific

Participatory process’ main application case is when

supplier + customer closely collaborate; customer stakeholders strongly involved in both specification and development processes

The “contractual” combo is…

 typically linear but sometimes iterative + prescriptive + customer-specific

The main application case for contractual combos is when…

there’s a contractual basis for sys dev by people NOT included in specification, little stakeholder interaction after requirements phase

The “product oriented” combo is…

iterative + explorative + market-based

Product-oriented main application case is…

when an organization specifies and develops software in order to sell/distribute it as a product or service

Examples of typical participatory combo work products are

•  product backlog

• user stories and/or task descriptions

• visions

• prototypes

• use cases

• various models

(same as product-oriented!)

An example of typical contractual combo work products is..

classic system requirements specification, consisting of textual requirements and models

Example of a typical product-oriented work product is..

• product backlog with user stories and/or task descriptions

• visions

• prototypes

• user feedback

• use cases

• various models

(same as participatory!)

Use case model consists of…

Use case diagram(s) + use case descriptions

Use cases…

• Define system

• Find actors/use cases

• Describe use cases

• Define relationships between use cases

• Validating model

Actors represent…

external entities that interact w system (human, hardware, or external software)

Use case is defined as a set of actions that…

define interactions between actor and system to achieve a goal

Use cases are…

Actor-initiated, invokes a certain functionality

Scenarios are…

story of use with new product (use has certain motivations and goals in mind) that shows user goal, usage setting, some steps

why should we use scenarios?

Humans easily understand and relate to stories

Associations show…

which actors the use case communicates with, including actor that initiates use case execution

Use case descriptions are …

textual description of a set of actions defining interactions between actor and system to achieve goal

Use case descriptions should include

• Basic functionality/goal

• Preconditions if applicable

• Event flow

• Post conditions if applicable

• Any error conditions and/or alternative flow

• Does NOT include specific UI interactions

Flows are

 sequence of steps describing interaction between user and system

Basic flow describes a ________ scenario, where everything works well and the goal is reached as designed

happy day

Alternative flow describes a scenario where the goal is reached in an ______________ way

alternative

Exception flow describes a scenario where the goal is/is not reached

is not

Actors are discovered by…

• Reading sys docs

• Talking with customers and domain experts

To build a use case, you should first

name the use case

To build a use case, you should first name the use case, then…

describe the basic flow

To build a use case, the last step you should take is

add variations onto the basic flow if applicable (alternative and exception flows)

Use cases are used for

• Deciding and describing system’s functional requirements

• Clearly and consistently communicate requirements to a wide variety of stakeholders

• Serve as basis for further design modeling/development and traceability between req and actual classes and operations in system

• Provide a basis for performing system tests later

What are some example of audiences for use cases?

• Customer and/or end user

• Developers

• Testers

• Anyone involved in functionality-related activities

  • Marketing

  • Sales

  • Support

  • Documenters

Use cases show…

dynamic interactions between system and context from user POV

When the customer wants a contractual requirements doc, which type of RE process is appropriate? (mark all that apply)

• Explorative

• Linear

• Prescriptive

• Customer-specific

Linear, prescriptive, customer-specific

In an agile setting, a linear and prescriptive RE process fits best.

False

Explorative RE processes are typically also:

iterative

Which typical RE process configuration is iterative, explorative, and customer-specific?

• Participatory

• Product-oriented

• Contractual

Participatory

In which typical RE process configuration is the information flow primarily from stakeholders to requirements engineers?

• Product-oriented

• Participatory

• Contractual

Contractual

Use case diagrams consist of…

actors/agents, use cases, relationships, system boundary

Glossary provides an…

unambiguous and agreed-upon common terminology

Product and sprint backlogs manage…

a list of work items, including requirements

Story maps are a __________ arrangement of user stories

visual

Glossaries should define

• Context-specific terms

• Everyday terms that have a special meaning in the given context (business, application domain)

• Abbreviations and acronyms

Prototypes are

preliminary, partial realization of certain characteristics of a system

Prototypes help to…

• Specifying requirements by example

• Validating requirements

• Supporting stakeholder communication and shared understanding

What four aspects should you document in requirements, regardless of language/method/documentation style?

1. Functionality

2. Quality

3. Constraints

4. Context/boundary

Functionality describes…

data, function and flow, state and behavior (both normal and abnormal cases)

Qualities describe..

performance (data volume, reaction time, processing speed, specific measurable values when possible), specific qualities (“-ilities”)

Constraints include…

 technical, legal, organizational, cultural, environmental, physical, solutions/restrictions demanded by important stakeholders

Context/boundary describes…

domain requirements, domain assumptions (within context), embedding of a system in its context, interaction between system and actors in the context

Documentation can be…

Informal, semi-formal, or formal

Informal documentation is based on…..

plain, natural language/narrative text

Semi-formal language uses….

structured natural language (using templates or forms) and graphic models

Disadvantages of formal specifications

• Requires training to use/understand

• Other techniques may be more cost effective

You should quantify requirements with………………

small, identifiable units whenever possible

Metadata should be recorded when writing requirements (source, author, date, status)

True

The ideal RE process is…

• Interactive: iterative + explorative

• Close and intensive collab between stakeholders (know domain and problem) and requirements engineer (know how to specify)

• Very short feedback cycles

• Risk-aware and feasibility-aware (technical + deadline risks/feasibility)

• Careful negotiation / resolution of conflicting requirements

• Focus on establishing shared understanding

• Strives for innovation