423 Soft Req

Lakukan tugas rumah & ujian kamu dengan baik sekarang menggunakan Quizwiz!

Business requirement

the need that leads to the system to deliver a solution and the desired business outcomes.

Safety requirement

the need to protect the system or users of the system; also non-functional

business use cases

the processes of a business and their interactions with external parties (like customers and partners)

temporal event (system event type)

time-triggered

Requirements management

to anticipate and accommodate the very real requirement so as to minimize their disruptive impact on the project

Security

to block unauthorized access to system functions or data ensuring that the software is protected from malware attacks

Validation

to confirm that the correct set of requirements information enables developers to build a solution that satisfies the business objectives - reviewing the documented requirements to correct any problems before development - developing acceptance test and criteria to confirm that a product would meet customers' needs and achieve the business objectives

each user requirement leads to the implementation of functional requirements

true

A traceable requirement must be

uniquely + persistently labeled

Version control

uniquely identify versions - often in doc form - start when a requirement or doc is drafted so history is retained

Identify the quality attribute: "all functions on the File menu shall have shortcut keys defined that use the Control key pressed simultaneously with one other key"

usability (consistency of usage)

use case diagrams/behaviour diagrams

used to describe a set of use cases that the system can perform in collaboration with the actors - context of use case with other use cases - relationship between actors and use cases - actor: box if not human - use case: oval arrows: from each actor connect to uses cases with which actor interacts primary actor: arrow from primary actor to use case secondary actor: arrow from use case to actor, who participates somehow in successful execution of use case

Human-computer interaction specification

user interface details

Identify requirement type: I need to print a mailing label for each package

user requirement

Acceptance tests are derived from

user requirements

Verifiable

verify whether each requirement is properly implemented characteristics of complete, consistent, feasible, or unambiguous should be verifiable

Requirements management activities

version control, change control, requirements status tracking, requirements tracing

Examples of malware

viruses, worms, Trojan horses, ransomware

Feature tree

visual depiction of the product's features organized in logical groups hierarchically subdivide each feature into further levels of detail can show up to three levels of features, level 1 (L1), level 2 (L2), level 3 (L3)

Class diagram multiplicity

write on end of each line 1 1, only 1 0..1 0 or 1 M..N from M to N * zero to any positive int 0..* zero to any positive int 1..* one to any positive int

Class diagram role

write on end of each line above or below multiplicity eg. student, teacher, employer

Validation objectives

Accurate (description of system) Correct (derivation) Necessary Complete, feasible, and verifiable Consistent (with each other) Adequate (to proceed with design + construction)

Approaches to identify user classes

Ask project sponsor Brainstorm Use external entities of context diagram Analyze the organization chart

Requirements engineering

Bridge gaps between real-world needs of users/customers and real functionality of the developed systems; 15-30% of system development costs

Modelling tools

DFD, ERD, data dictionary, primitive process specification

Data dictionary template

Data element - Primitive data element + structure in the system Description Composition/data type - data type: integer, numeric, alphabetic characters Length - size of data element Values

System requirements

Define what a system is required to do and the constraints under which it is required to operate.

Requirement analysis

Determine the needs or conditions to meet new/altered projects, taking account of possibly conflicting requirements of stakeholders, analyzing/documenting/validating/managing software or system requirements Clear, complete, consistent, and unambiguous Specification is separate

Why scale matters for requirements engineering

Difficult to show in academic setting; many projects + systems in an undergraduate program can be built without formal requirements; many commercial systems can be (and are) built without formal requirements

Portability

Effort needed to migrate software from one operating environment to another

Customer developer partnership

Excellent software product (requirements, design, implementation, test, etc.) All parties know what they need to do All parties understand + respect what their collaborators need to do Common objective: to build a product that provides adequate business values and rewards to all stakeholders

Problem domain knowledge

Knowledge about the application for which the system is required

User persona simple layout 2

Name, photo, intro to personality, category 1 + description 1, category 2 + description 2

Requirements might describe

User level features General system properties Specific constraints Development constraints ...

Business requirements

a need that leads to one or more projects to deliver a solution and the desired ultimate business outcomes to display the business benefits, vision, and scope

actors

a role played by a person something or someone that exists outside the system

Requirement baseline

a set of requirements that has been reviewed and agreed-upon and serves as the basis for further development

When documenting business rules, best practice is to include:

a unique identifier rule definition type of rule static or dynamic sources (e.g. document, expert, policy)

Scalability

ability of application to grow to accommodate more users, data, servers, ...

OOA Generalization

abstraction of common properties into a base class eg. account: checking, saving, credit

Trace links

allow developers to follow life of a requirement forward + backward one-to-one (1 element, 1 code module) one-to-many (1 req, >1 test) many-to-many (use cases <-> FRs)

Control frame

applies where system or machine will control some aspect of problem domain with behaviour rules variations: - required behaviour frame - commanded behaviour frame

To avoid an expectation gap

arrange frequent contact with suitable customer representatives

Peer deskcheck

ask a colleague to look over your work product

Identify the quality attribute: "The system shall be at least 95% available on weekdays between 6:00 AM and midnight Eastern Time, and at least 99 percent available on weekdays between 3:00 PM and 5:00 PM Eastern Time."

availability

Identify the quality attribute: "down time that is excluded from the calculation of availability consists of maintenance scheduled during the hours of 6PM Sunday Pacific Time, through 3AM Monday Pacific time"

availability

Commanded behaviour frame

behaviour commanded by user user spontaneous and biddable controlled domain has some behaviour, not autonomous behaviour rules constrain commands issued by user and resulting system behaviour

Assessing value, cost, risk looks at:

benefit: benefits to customers if feature is present penalty: penalty if feature is absent cost: consumed resources to implement risk: danger, harm, or loss to implement

atomic business rules

can't be decomposed don't use "or" logic on LH of an "if-then", avoid "and" logic on RH

Business rules

certain users can perform an activity under specific conditions

Business and scope document: 1.2 business opportunity

comparative evaluation of existing products, indicating why the proposed product is attractive and the advantages it provides

Identify requirement type: file submitted electronically cannot exceed 10 MB in size

constraints

Level 0 DFD

context diagram highest level of a data flow model

use case secondary actor

contributes behind the scenes to the use case execution; often other software systems

Concise way to document action-enablers with extensive logic

decision table

Correct

each requirement accurately describes a capability and clearly describes the functionality to be built - go to source of requirement to check correctness

user-centric and usage-centric approach

focusing on users and their anticipated usage

User requirement

general statements of user goals or business tasks that users need to perform

what type of constraint is this an example of: "airline pilots must receive at least 8 continuous hours of rest in every 24-hour period"

government regulation

Class diagram aggregation

if there is an empty diamond adornment, it's aggregation - more informal than composition, no special access privileges

Requirements management involves

keeping current project plans with the requirements evaluating the impact of proposed requirements changes negotiating new commitments based on the estimated impact of requirements changes tracing individual requirements to their corresponding design, source code, and tests tracking requirements status and change activity throughout the project

Availability

measure of planned up-time during which services are available (MTBF/(MTBF+MTTR) - MTBF: mean time between failures - MTTR: mean time to repair after failure encountered service providers may have to pay penalty if not satisfying service level agreements related to availability

Reuse mechanism

mechanism being used to perform reuse

Data dictionary: repeating group

multiple instances of a data element can appear in a structure examples: 1:10{Requested Chemical}: request must contain min. one chemical but no more than 10 3:n{Requested Chemical}: max # instances in repeating field is unlimited (indicated by "n") Repetition min{}max: no min means constant size e.g. {numeric}16 vs 3{numeric}6

Data entity

object in a data model eg. customer, address, book

Workpiece frame properties

operation requests: biddable workpiece: inert

following up after elicitation

organize + share notes for reviewing + updating classify customer inputs

Identify the quality attribute: "authorization of an ATM withdrawal request shall take no more than 2.0 seconds"

performance

Identify the quality attribute: "modifying the iOS version of the application to run on Android devices shall require changing no more than 10% of the source code"

portability

Identify the quality attribute: "the platform migration tool shall transfer customized user profiles to the new installation with no user action needed"

portability

Requirements validation outputs

problem lists, actions (not necessarily one to one)

Formal peer reviews

produce report that identifies material examined, reviewers, and review team's judgement as to whether requirements are acceptable follow well-defined process deliverables: summary of defects and issues raised during review best established type: inspection

Approaches to understanding user requirements

product-centric approach, user-centric and usage-centric approach

technique - questionnaires; pros and cons

pros: inexpensive can quickly collect info from large # people can be administered remotely cons: no context difficult to explore new domains

signal event (system event type)

registered when system receives a control signal, data reading, or interrupt from an external device or another system

Reusability

relative effort required to convert a software component for use in other applications

Required behaviour frame

required behaviour of controlled system is fully defined by predefined rules, no operator intervention needed cannot be autonomous controller is reactive, programmable, or biddable

Feasible

requirement must be possible to be implemented

"forward to requirements"

requirements affected if needs change requirements set address all stated customer needs

Identify the quality attribute: "if the text editor fails before the user saves the file, it shall recover the contents of the file being edited as of, at most, one minute prior to the failure the next time the same user launches the application"

robustness

OOA Association

semantic relationship between classes allow one object instance to cause another to perform action on its behalf eg. student enrols in course, prof writes book aggregation + composition

Change control

software change not bad thing, but has cost consistent change control prevents problems, rework, wasted time

Originator

submits change request

User class

subset of the product's users that is a subset of product's customers - access privilege/security levels (e.g. admin, guest) - tasks + goals they perform with the system - platforms they will use (desktop PC, tablet, smartphone) - native language - whether they will interact with the system directly or indirectly

Product vision

succinctly describe the ultimate product that will achieve the business objectives (so we all know where we're hoping to go) applies to product as a whole

Business and scope document: 1.1 background

summarize rationale and context for new product or for changes to an existing one

Business and scope document: 2.2 scope of initial release

summarize the capabilities that are planned for inclusion in the initial product release

Business and scope document: 1.3 business objectives

summarize the important business benefits the product will provide in a quantitative and measurable way

Business and scope document: 3.3 deployment considerations

summarize the info and activities that are needed to ensure an effective deployment of the solution into its operating environment - describe users (location, time zones) - describe infrastructure changes for capacity, network access, data storage - record knowledge needed for users (training)

Business and scope document: 1.6 business risks

summarize the major business risks eg. marketplace competition, timing issues, user acceptance implementation issues

Requirement attributes

supporting pieces of info associated with a requirement store in a document, requirements management tool, database, etc. - date created - current version number - author - priority - status - origin or source - rationale - release number or iteration - stakeholder to contact - validation method to be used or acceptance criteria

technique - questionnaires

survey large groups of users to understand their needs challenge: prepare well-written questions

Modelling tools for requirements engineering

swimlane diagram state-transition diagram (STD) state table dialog maps decision table + tree event-response table

Control system

system controls behaviour of part of problem domain required behaviour frame and commanded behaviour frame eg. anti-lock brakes, fly-by-wire, elevator control system

Information system

system provided information about problem domain eg. student record system, geographic info system, Google Map, info query system

User interface requirements

system requirement that involves an interaction with users

Requirements document

system requirements understandable to stakeholders

Transformation system

system transforms input data into output data in particular format eg. bank statements generation, compiler

business rules examples

"Contonso requires an annual refresher in the safe handling of hazardous chemicals" "No credit check is to be performed on return customers when they are applying for visa"

DFD constraints on data flow

* means and - on input: data item in both streams is required - on output: both data items are generated ⃞ means or - on input: data item from one stream or the other - on output: output is to one stream or the other

RA (requirement analyst) responsibilities

- Define business requirements - Plan requirement approaches - Identify the stakeholders and users - Elicit, analyze and document requirements - Communicate requirements - Lead requirements validation - Facilitate requirement prioritization - Manage requirements - Bridge communication between developers + stakeholders (users)

Responsibilities for customers

- Educate RAs and developers about the business - Dedicate the time it takes to provide and clarify requirements - Make timely decisions about requirements when asked - Set realistic requirement priorities in collaboration with developers - Review requirements and evaluate prototypes - Establish acceptance criteria - Promptly communicate exchanges to the requirements

Rights for customers

- Expect RAs to learn about the business objectives - Expect RAs to record requirements in an appropriate form - Change the requirements - Expect an environment of mutual respect - Describe characteristics that will make the product easy to use - Hear about ways to adjust the requirements to accelerate development through reuse - Receive a system that meets the functional needs and expectations

Avoid ambiguity

- Peer review - Avoid fuzzy words - Avoid A/B construct (slash is confusing) - Clearly phrase boundary values - Don't write negative requirements (telling what system will not do) - Symmetrical operations are common source of missing operations (eg. "user shall be able to save contract at any point during manual setup") - Avoid complex logic - Watch out for missing exceptions

Requirements engineering involves system development processes:

- Systematic and repeatable techniques - Requirements development - Requirements management

What threats do data need to be protected against:

- accidental loss or corruption - ostensibly identical data sets that do not match - physical damage to storage media - accidental file erasure - data overwriting by users

Scalability hardware implications

- acquiring faster computers - adding memory or disk space - adding servers, mirroring databases - increasing network capacity

Change control process entry criteria

- all necessary info included, received through approved channel - potential originators know how to submit change request - unique ID assigned to each request - all changes routed to requests receiver

Inspection participants

- author of work, peers of author - sources of info (eg user rep) - people who will work based on item under inspection (eg. developer, doc writer) - people responsible for interfacing systems that will be affected by it (limit to 7 or fewer inspectors)

Structured analysis cons

- confusion between modelling problem and modelling solution - model solution system - control information invisible - hard to describe complex interfaces - while useful for IT style system, not for many other types

Scalability has software implications

- distributing computations onto multiple processors - compressing data - optimizing algorithms - other performance-tuning techniques

Structured analysis pros

- easy to learn without software expertise - easy for customers to understand - clear definition of system boundary - abstraction + partitioning - some automated support

Inspection stages

- group reads + analyzes requirements and specification documents - requirements clarification - missing information (elicit) - conflicts (resolve) - unrealistic requirements (delete/modify) - satisfy exit criteria

Workpiece frame

- machine performs various operations on workpiece in response to requests - request source likely human or other machine - workpiece contained with machine - operation problem domain: - workpiece dynamic, inert - workpiece intangible - requests dynamic but spontaneously active and biddable - machine dynamic, active, programmable eg. draughting tools, computer-aided software engineering tools, office utilities like word processors, publishing and web production tools

Change control process

- meet entry criteria - evaluate change request - make change decision - implement change - verify change - meet exit criteria (status: rejected, closed, or canceled)

labeling requirements: hierarchical numbering

- starts with section number - more digits indicates lower-level pros: - simple, familiar - management tools support this numbering cons: - labels grow to many digits even in medium SRS - numbers tell nothing about intent - label changes disrupt references elsewhere

Labeling requirements: sequence number

- unique sequence number (requirement type + number) pros - easy to retain unique ID cons - no logical or hierarchical grouping - number doesn't imply ordering - labels don't indicate what it's about

Making requirement reusable

- well-written - right level of abstraction and scope - generic = broader applicability for reuse - BA elaborates details - balance easy reuse and reuse pay off (level of abstraction vs detail)

It's necessary to include more detail when

- work is being done for external client - development or testing is being outsourced - project team members are geographically dispersed - requirements traceability is needed

It's safe to include less detail when

- work is being done internally for your company - customers are extensively involved - developers have considerable domain experience - precedents are available, as when a previous application is being replaced - a package solution will be used

2 general sources of errors

1. Errors occur because the particular situation was not understood or expressed correctly (correctness) 2. Errors happen because the requirements do not mention the situation and the design and code does not plan for it (completeness)

Finding the voice of users

1. Identify the different classes of users 2. Select and work with individuals who represent each user class and other stakeholders

Prioritization techniques

1. In or out 2. Pairwise comparison and rank ordering 3. Three-level scale 4. MoSCoW 5. $100

Requirements process models have explicit validation steps:

1. Is the description of the problem domain accurate? 2. Are the requirements accurate? 3. Is the intended behaviour accurate? 4. Is the specification accurate?

Analysis approaches

1. Structured analysis (SA) 2. Object oriented analysis (OOA) 3. Problem domain oriented analysis (PDOA)

Traditional structured analysis steps

1. analyze current physical system (DFD) 2. derive logical equivalents - merge bubbles with same function - delete bubbles that don't transform data 3. model new logical system (modify DFD) 4. define # automation alternatives (each as DFD, select one to implement, write specification)

PDOA general procedure

1. collect basic info to develop problem frames to establish type of PD 2. guided by frame types, collect detail + develop description of relevant characteristics of the PD 3. in conjunction with above, collect and document requirements for new system

To create a DFD, identify:

1. data processes (activities that transform data) 2. collections/stores of data (passive, no transformation happening here) 3. data flows (between entities, represent data structure or element) 4. external entities (entity outside system, can only interact with processes) 5. data structure/group (cluster represented as single data flow; composed of more data groups or elements) 6. data elements: basic units of data

Assessing value, cost, risks, steps:

1. determine weight of benefit, weight, cost, and risk 2. list features, use cases, user stories, functional requirements 3. stakeholders estimate benefit + penalty, developers estimate implementing costs and tech risks (scale of 1-9) 4. total value = benefit x benefit_weight + penalty x penalty_weight, value%, cost%, and risk% 5. priority value = value% / (cost% x cost_weight + risk% x risk_weight) 6. sort list of features in descending order by calculated priority

Scope creep management

1. document business objectives, product vision, project scope, limitations 2. freeze requirements for specific release or development iteration Say "No!"

Model types

1. iconic: look-alike representation of some specific entity, eg photos, drawings 2. analogue: representation of entities by analogue entities pertaining to model, eg model airplane, charts 3. symbolic: representation of entities through symbols, eg mathematical logical symbols, math equations

Object oriented analysis steps

1. identify core objects and classes (eg library user, account, library item) 2. identify attributes (eg title, author) 3. construct object structures defining relationships between classes (eg generalization, association) 4. determine relevant operations for each object 5. define messages that may be passed between objects 6. refine object model

Two ways in which use cases and tests work well together

1. if use cases for system are complete, accurate, and clear: process of deriving tests is straightforward 2. if use cases are not in good shape, attempt to derive tests will help debug use cases

Single requirements elicitation session flow

1. prep for elicitation 2. perform elicitation activities 3. follow up after elicitation

Michael Jackson says two things are known about requirements

1. they will change 2. they will be misunderstood

Requirements IEEE St Definition

A condition or capability needed by a user to solve a problem or achieve an objective. A condition or capability that must be met or possessed by a system or a system component in order to satisfy a contract, standard, specification, or other formally imposed document. A document representation of a condition or capability.

Requirement prioritization

Address most urgent requirements in first few iterations to get value from system as quickly as possible Dynamic, ongoing process

Fuzzy words

Adverbs introduce subjectivity + hence ambiguity eg. reasonably, appropriately, generally, approximately, quickly, optionally, at least, at a minimum, fast, depend on, efficient, maximize, ...

Inspection roles

Author: created or maintains work product Moderator: plans inspection with author, coordinates, facilitates Reader: paraphrases requirements and model one at a time Recorder: uses standard forms to document issues raised and defects found

Modern structured analysis

Avoid modelling current system, skip to logical model (desired behaviour) Start with context diagram Use DFD or ERD to capture complex data Use two models: environmental model (external entities, devices, systems), behavioural model (behaviours of system)

CCB roles

CCB chair CCB Evaluator Modifier Originator Request receiver Verifier person

Evaluator

CCB chair asks them to analyze impact of proposed change

Traditional structured analysis

Centred on modelling pre-existing system by developing logical models Model only useful as basis Development goes directly from structural model of old system to modifying it to provide internal design for new system

Scope representation technique selection

Choose scope representation techniques that provide most useful insight for each project Scope change not a bad thing Determine which features or user requirements have most value for business objectives Schedule most important features for early releases

Ways to discover business rules

Common knowledge collected from individuals Business process modelling, looking for rules affecting steps Analyze data Find stakeholders in the know Analyze documents

Characteristics of requirement collections

Complete Consistent Modifiable (unique labels expressed separately) Traceable (link to origin and to consequent requirements, code, etc)

Characteristics of requirement statements

Complete Correct Feasible Necessary Prioritized Unambiguous Verifiable

Scope representation techniques

Context diagram Ecosystem map Feature tree Event list

Technique - interview

Conversation where one participant asks questions, others provide answers Discuss with different stakeholders Structured/closed: agenda of predefined questions, fairly open questions Open: no pre-set agenda, free wheeling discussion, adaptive questions Start: questions, next: discussion

Input sources of vision and scope document:

Customer Organization's senior management Product visionary Product manager Subject matter expert Marketing department members

Sources for RA to identify problem/opportunity

Customer specifications Documentation for existing systems Users of existing systems Potential users of new system Predecessor products Competitors' products Domain experts Documents for interfacing systems Standards and legislation

Data modelling

Data flow definitions are one-dimensional - show single data flow - not show relation between data or what data means For IT systems (has database): - add ERD to structured analysis - add data dictionary

Ways to specify data requirements

Data flow diagram (DFD) Entity relationship diagram (ERD) Data dictionary

Using feature tree to define scope

Define the scope by selecting a specific set of features and sub-features to be implemented - feature can be implemented in a specific release entirely - feature can be implemented in multiple releases

Technique - workshop

Encourages consensus Gather several stakeholder types Short intensive period (1-2 days) Facilitator: guide to successful outcome Output: preliminary system definition at feature level Minimum size: 7

Semantic data model

Entities that exist in the application environment Classifications and groupings of entities Structural interconnections among them Relational/entity relationship/object-oriented - model logical form of data in system - model data elements of problem domain - bridge to design

Context diagram

Establish the boundary and connections between the system and the environment - Entire system: single circle (no visibility into system) - External entities: rectangles (user classes, organizations, other systems, or hardware devices) - Data flow: arrows (between external entities and the system)

Requirements engineering process; inputs

Existing system info (what systems to replace, what systems it interacts with) Stakeholder needs Organizational standards (for product dev, testing, quality management, etc.) Regulations (imposed by government agencies, management act (FISMA)) Domain info (application domain info)

Elicitation techniques

Facilitated activities Independent activities

business rules taxonomy

Facts Computations Constraints Action enablers Inferences

Requirements reuse pros

Fast delivery, low dev costs, consistency, reduce rework Less review time, accelerate approval cycle + testing Improve ability to estimate of implementation effort Improve functional consistency

Business rules have influence on

Government regulations Privacy policies Company policies Quality attributes

Requirement prioritization challenges

Hard for customer to decide which req'ts are top priority Achieving consensus can be hard People not wanting to compromise

Requirement prioritization: three level scale

High priority: (important+urgent) must be included, compelling reason t implement properly Medium priority: (important, not urgent) customers need capability, but can wait Low priority: (not important, not urgent) customers can live without it and can wait Requirements (not important, but urgent): low priority or scrub entirely Prioritize iteratively

Requirements vs design

Ideal world: requirements happen before design, specify what not how (req't specifies problem, design is solution), never change Real world: pressure to get things done the first time, req'ts always change, difficult to add requirements later, not all issues can be foreseen or understood, users cannot express all we know (real life analogues: contracts, house renos)

Using personas

Identify features and functionality Determine if one UI will meet goals of all others, or if we need more than one Make design decisions about how functionality will work Represent behaviour patterns not job descriptions

RA must

Identify the problem/opportunity: - which problem needs to be solved - where is the problem (context) - whose problem (stakeholders) - why does it need solving (stakeholders' goals) - how might software help (collect scenarios) - when does it need solving (constraints) - what might prevent us solving it (feasibility/risk)

Business objectives examples (financial)

Increase market share in country W from X% to Y% within Z months Save $X per year currently spent on a high-maintenance legacy system

Importance of requirements

Increased reliance on software, eg consumer products Software now the biggest cost element for many mission critical systems High consequence of failure, eg Ariane 5, Mars Observer, Beagle 2 Factors, eg certification costs, defect removal, changing requirements

Traditional structured analysis cons

Increasing problem sizes = projects getting bogged-down in modelling pre-existing system; function may not even be same or relevant

Reviewing requirements

Informal reviews Formal reviews

Modelling techniques

Internal model External model

When to use DFD

Interviewing customers Identify missing data requirements Give context to functional requirements re. how user performs specific tasks

Relational data model

Isomorphic to ER - basis of relational databases - model data handled by system (e.g. IT system) - 2D tables - some tables represent entities + attributes - some tables represent relationships

List possible stakeholders for a library cataloging system

Library users Cataloging staff Library manager Help desk Book publishers (indirect) Systems developers Managers of other library automation systems ...

Essential skills of RA

Listening Interviewing + questioning Think on your feet Analytical System thinking Learning Facilitation Leadership Observation Communication Organization Modeling Creativity

Requirement prioritization: pairwise comparison and rank ordering

Make pairwise comparisons between requirements by judging which member of each pair has higher priority Assign unique priority sequence number to each requirement Group requirements into features or small sets of requirements with similar priority

Requirement prioritization: MoSCoW

Must: must satisfy to consider success Should: important, include if possible, not mandatory to success Could: desired, could be deferred/eliminated, implement if resources permit Won't: not now, could in future releases

User persona layout 3

Name, photo, scenario, needs, feature, behaviour (break down into table)

User persona simple layout

Name, photo, summary of persona, multiple paragraphs Tends not to be useful as the information tends to be disorganized

Modelling primitives

Objects: - has states/attributes/services - problem-domain objects - nearly anything, except procedures (print, calculate tax) or attributes (blue, 50Mb) Class: group w similar attributes Attribute: property of object Relationship: association between classes allowing one to cause another to do an operation - "has-a", "part-of" Method (service, function): operation all objects in class can do Message passing: objects invoke services of others Use cases/scenarios

Problem systems for requirements engineering

Outsourced and contracted development (government, military) Very large systems (billions of dollars, 10s of 1000s of developers) Risk systems (fly by wire systems, nuclear safety, ICU medical systems)

Important quality attributes for embedded systems

Performance, efficiency, reliability, robustness, safety, security, usability

Roadblocks to acceptance

Personas != market segments Personas are not serious enough A set of personas = user population?

Requirements elicitation difficulties

Problem domain knowledge is spread over many sources Tacit knowledge Limited observability Ignorance Bias

Dimensions of requirements elicitation

Problem understanding Business understanding Understanding needs of stakeholders

Tracking requirements status

Proposed: requirement has been requested In progress: an RA is actively working on crafting the requirement Drafted: initial version written Approved: analyzed, impact estimated, allocated to baseline Implemented: code is designed, written, and unit tested Verified: satisfied acceptance criteria Deferred: approved requirement is now planned for implementation in later release Deleted: approved requirement is removed from baseline Rejected: not planned for implementation in any upcoming release

Informal review pros and cons

Pros: - catch glaring errors, gaps - spot statements that don't meet high-quality Cons: - hard to catch all ambiguous requirements

Technique - interview; pros and cons

Pros: - rich collection of info - users usually happy to talk about tasks Cons: - large amounts of qualitative data - hard to compare different responsdents - interviewing is a hard skill - unrealistic expectations

Facilitated activities (elicitation)

RAs interact with stakeholders to elicit requirement Focus on discovering business and user requirements Interviews, workshops, focus groups, observations, questionnaires

Independent activities (elicitation)

RAs work on their own to discover information Present and reveal needed functionality that users might not be aware of System interface analysis, user interface analysis, document analysis

Types of requirement issues

Requirement question Missing requirement Incorrect requirement Implementation question Duplicate requirement Unneeded requirement

tracing tool support

Requirements Management IBM rational - Rose - RequisitePro (AnalystStudio) IBM Telelogic - DOORS - DOORSnet - DOORSrequireIt Both integrate with WORD and dev tools

Requirements problems

Requirements don't reflect the real needs of the customers Requirements are inconsistent and/or incomplete Expensive to change requirements once everyone has agreed on them Misunderstandings between customers and developers

Why requirement prioritization

Reveal competing goals, resolve conflicts, control scope creep, ... Help deliver max business value quickly within constraints Help distinguish core functionality

Ecosystem map

Show all the systems related to the developing system that interact with one another and the nature of those interactions - all systems that interconnect and that might need to be modified to accommodate the new one - other systems that have a relationship with the system (may not have direct interfaces) bold box: primary system boxes: other systems that interconnect lines: interfaces between systems lines with arrows and labels: data flow from one system to another

Class diagram

Shows relationships between object classes - generalization - association (aggregation, composition) Class: rectangle subdivided into 3 compartments: name, attributes, operations Abstract details in several layers

Structured analysis

Software engineering technique that uses graphical diagrams to develop and portray system specifications Describe steps + data required to meet design function of a software DFD are central to this method Mainly for info systems (banks, insurance, retail)

Common reuse scenarios

Software product lines Re-engineered and replaced systems Distributed deployments Interfaces + integration Security Standards, regulations, legal compliance

Requirements engineering process; outputs

Software requirements specification (SRS): - Requirements document - System specifications - Human computer interaction (HCI) specification

List possible stakeholders in student course registration database

Students (interact thru SOLUS) Registrar's office Faculty admin staff Department admin staff ITS developers ITS system admin Professors ...

What happens if requirements are wrong

System may be late and over budget System doesn't meet needs, may even be discarded System may be unreliable 75-85% of errors found in software can be traced back to requirements and design

Writing requirements: system/user perspective

System perspective: [optional precondition] [optional trigger] the system shall [expected response] User perspective: The [user class or actor name] shall be able to [do something] [to some object] [qualifying conditions, response time, or quality statement]

Incompleteness

TBD - flag knowledge gaps lacking piece of info about specific requirement - risk developer or tester making errors and having to do rework - record in an issues list

Technique - workshop; pros

Team building All stakeholders get a say Achieve agreement Output is available immediately

Analysis

To reach a richer and more precise understanding of each requirement and represent sets of requirements in multiple ways - Analyzing the info from users to distinguish their tasks - Decomposing high-level requirements into an appropriate level of detail - Deriving functional/data requirements - Understanding the importance of quality attributes - Negotiating implementation priorities - Identifying gaps in requirements or unnecessary requirements

Specification

To represent and store the collected requirements information in a persistent and well-organized fashion - Translating the collected user needs into written requirements and diagrams suitable for review and use

Level of detail tips

Use consistent granularity Write individually testable requirements (requiring small # test cases to verify correct implementation of requirement)

Problem frame types

Workpiece system Control system Information system Transformation system Connection system

ERD cardinality/multiplicity

a number or letter on the lines that connect entities and relationships - one-to-many - one-to-one - many-to-many vertical line indicates cardinality of 1 (or 1) crow's foot indicates cardinality of many (or M)

solution ideas

a specific way to interact with the system to perform some action probe the surface of a solution idea to get to the real requirement repeatedly asking "why" the user needs it "then I select the state where I want to send the package from a drop-down list" "the phone has to allow the user to swipe with a finger to navigate between screens"

How to approach multi-frame problems

abstract problem domain (subdomain, domain interactions, characteristics, problem context diagrams) recognize relevant standard frames fit frames to problem use problem domain (kovitz's) tables to guide analysis and documentation

Business objectives examples (non-financial)

achieve a customer satisfaction measure of at least X within Y months of release receive no more than X service calls per unit and Y warranty calls per unit within Z months after shipping

business event (system event type)

action by a human user that stimulates a dialog with the software

what type of business rule is this an example of: "if the chemical stockroom has containers of a requested chemical in stock, then offer existing containers to the requester"

action enabler

what type of business rule is this an example of: "if the customer ordered a book by an author who has written multiple boos, then offer the author's other books to the customer before completing the order"

action enabler

Data process

activities that transform data eg. enter address, change address, delete address, ...

Requirement management

all activities that maintain integrity, accuracy, and currency of requirements agreements throughout project

State table

all possible transitions between states in form of a matrix ensure all transitions are identified states in first column, repeated across first row cells indicate whether transition from state on left to state at top is valid and identifies transition event the two rows in which values are all "no" are termination states

business rules (business logic)

an extensive set of policies, laws, standards, and government regulations operated for an organization must be enforced by software applications, but is a property of the business

Two-way traceability matrix

arrow indicates certain functional requirement is traced from a particular use case links between use cases and FRs

For the vision and scope document, RA does:

articulate the business requirements and writes the vision and scope document

Important quality attributes for internet and corporate applications

availability, integrity, interoperability, performance, scalability, security, usability

Data flow diagram (DFD)

big-picture view of how data moves through a system shows data process taking place in a system

Security requirement

block unauthenticated or unauthorized access to system functions or data; also non-functional

Business and scope document: 2.3 scope of subsequent releases

build a release roadmap that indicates which functionality chunks will be deferred and the desired timing of later releases

three classes of system events

business event signal event temporal event

Identify requirement type: the system can help to increase the market share in Kingston by 10% within 6 months

business requirement

Identify requirement type: the system can save $1000 per year on electricity now wasted by inefficient units

business requirement

Identify requirement type: a new client must pay 30 percent of the estimated consulting fee and travel expenses in advance

business rules

Identify requirement type: time-off approvals must comply with the company's HR vacation policy

business rules

Requirement prioritization: $100

cast money in terms of actual resource 100 imaginary dollars, allocate to "buy" items team members would like to implement from full set of requirements higher-priority indicated by allocating more dollars add up total dollars for each requirement and rank a list

Requirements validation

certify that documentation is an acceptable description of the system to be implemented validate final draft of requirements against: - incompleteness + inconsistency - in-conformance to standards - requirements to conflicts - technical errors - model errors - ambiguous requirements

Requirements tracing

changes cause modification to system, so find all system elements that may be affected by an altered requirement, dependencies, logical links, etc. perform impact analysis

External quality attributes

characteristics discernible through execution of the software primarily important to users availability, installability, integrity, interoperability, performance, reliability, robustness, safety, security, useability

Internal quality attributes

characteristics not discernible through execution of the software indirectly contribute to customer satisfaction by making product easier to enhance, correct, test, and migrate efficiency, modifiability, portability, reusability, scalability, verifiability

Entry criteria

clear expectations document to be inspected should follow - standard template - spelling, grammar, format - line numbers or other unique identifiers - open issues marked clearly as TBD or in issue-tracking tool - moderator found no more than 3 major defects in 10 minute examination of representative sample

Performing elicitation activities

collect info from stakeholders educate stakeholders; teach approach + explain why take good notes (assign someone)

Data dictionary

collection of detailed information about data entities feed into design in the form of database, tables, and attributes

Identify the business rule influence type on this functional requirement: if an invoice is received from an unregistered vendor, the Supplier System shall email the vendor editable PDF versions of the supplier intake form and the W-9 form

company policy

Data elements - data structure

composed of multiple data elements with plus (+) signs eg. chemical request, delivery location, requested chemical

What type of business rule is this an example of: "the domestic ground shipping charge for an order that weighs > 2 lbs is $4.75 plus 12 cents per ounce or fraction thereof"

computations

What type of business rule is this an example of: "the total price for an order is the sum of the price of the items ordered, less any volume discounts, plus state and county sale taxes for the location to which the order is being shipped, plus the shipping charge, plus an optional insurance charge"

computations

What type of business rule is this an example of: "the unit price is reduced by 10 % for orders of 6-10 units, by 20% for orders of 11-20 units, and by 30% for orders of more than 20 units

computations

connection frame properties

connection device: programmable reality: programmable, biddable, or autonomous

external interface requirements

connections between the developing system and the rest of the universe "must read signals from..." "must send messages to..." "must be able to read files in <format>" "user interface elements must conform to <a standard>" "the manufacturing execution system must control the wafer sorter" "the mobile app should send the check image to the bank after I photograph the check I'm depositing"

Identify requirement type: the margin for each side of a document (top, right, bottom, and left) cannot exceed 1.5 inch

constraints

Control frame properties

controlled domain: reactive, programmable, or biddable

In value, cost, risk assessment, benefit + penalty ratings provided by:

customer reps, PM, or product owner provides:

use case diagrams actor generalization

define abstract + concrete actors and specialize them using generalization descendent inherits all use cases of ancestor descendent has 1+ use cases specific to that role

use case diagram generalization

define abstract + concrete use cases and specialize them using generalization relationship child use case inherits structure + behaviour + relationships of parent use case they have common behaviour and each has specialized behaviour specific to it

Functional requirement

defines part of system's functionality

Product-centric approach

defining the features to implement in the software

Robustnesss

degree to which system continues to function properly when confronted with: - invalid input - defect in connected software or hardware components - external attack - unexpected operating conditions checkpoints, autosave, default values

Walkthrough

describe deliverable and solicit comments on it

Composition

describe relationship between whole and its existential parts if composite is deleted, associated are too eg. person contains head, heart, legs, ...

Aggregation

describe relationship that a class is part of/subordinate to another dependent object remains even if source is destroyed eg. car (parent) and wheel (child), class (parent) and student (child)

system use cases

describe what the actor achieves interacting with the system

Business rules: facts

describes associations or relationships between important business terms a statement that is true about the business at a specified point in time

User personas

description of a representative member of the user class help you understand the requirements design the user experience to best meet the needs of specific user communities, before RA contacts a user representative fictitious stand-ins for real user classes focus on users' goals rather than formal requirements

constraints

design + implementation constraints legitimately restrict the options available to the developer devices with embedded software often must respect physical constraints such as size, weight, and interface connections "must be written in <language>" "cannot exceed <limit>" "must use <specific UI control>" "files submitted electronically cannot exceed 10MB in size" "browser must use 256-bit encryption for all secure transactions"

Constraints

design and implementation restrict the options available to the developers

Specifying data requirements

determine what data is required for building the model input + output flows on context diagram create, modify, display, delete, process, and use data Includes: data entity, data attributes, data process

"forward from requirements"

determine whether each is satisfied which design components and code elements address each one

Verifier person

determines whether change was made correctly

In value, cost, risk assessment, cost + risk ratings provided by:

development reps

Business and scope document: 3.1 stakeholder profiles

different categories of customers and other key stakeholders major value or benefits, major features or characteristics, attitudes

Problem context diagram

different from context diagram because it models problem context not system context relations between domains - could be data flow - shared phenomena - values or events shared dot on end of a connecting line: one domain contained within another (dot end is the one containing the other) arrow: constraint on phenomena within the subdomain

use case diagram <<include>>

directed relationship between two use cases which shows that behaviour of the included use case is inserted into that of the including (base) use case can: - simplify large use case by splitting into several - extract common parts of behaviours of 2+ use cases dashed arrow with open arrowhead from base to included use case

use case diagram <<extend>>

directed relationship that specifies how and when the behaviour defined in the extending use case can be inserted into the behaviour defined in the extended (base) use case dashed line with arrow from extending use case to extended use case with label <<extend>> defines optional behaviour

Problem domain analysis

document, measure, test, trace, identify business needs or opportunities problem domain and problems that exist within it

Requirement validation inputs

documents, org standards, org knowledge

MoSCoW cons

doesn't offer rationale for making decision about priority ratings ambiguous "won't"

Business and scope document: 2.4 limitations and exclusions

e.g. the new system will not provide mobile platform support

Complete

each requirement contains all the info necessary - provide info developer needs - use TBD as standard flag to highlight lacking info

Informal reviews

educate other people about project and collect unstructured feedback peer deskcheck, passaround, walkthrough

Identify the quality attribute: "at least 30% of the processor capacity and memory available to the application shall be unused at the planned peak load conditions"

efficiency

Identify the quality attribute: "the system shall provide the operator with a warning message when the usage load exceeds 80 percent of the maximum planned capacity"

efficiency

Usability

effort required to prepare input for a system, operate it, and interpret its outputs - ease of use - ease of learning - memorability - error avoidance handling - efficiency of interactions - accessibility conflicts may arise between categories

Data dictionary: optimal

element is optional if value doesn't have to be supplied by the user or system

Requirements development

encompass all the activities involved with exploring, evaluating, analyzing, documenting, and confirming the requirements for a product: elicitation, analysis, specification, validation

Requirement statement

every individual business, user, functional, and NFR would exhibit the quality metrics

"backward to requirements"

explain why each element was createdq

Extent of reuse

extent of assets being reused

Extent of modification

extent to which item must be modified for use in new setting

Requirement reuse

external goal for those seeking increased software productivity copy and paste it from existing specification not free; presents its own risks (time + effort to make reusable requirements)

True/False: this is an atomic business rule: "you can check out a DVD or blu-ray disc for one week, and you may renew it up to two times for three days each, but only if another patron hasn't placed a hold on it"

false

CCB chair

final decision-making authority if CCB not reach agreement identifies evaluator + modifier for each change request

Business requirements

financial, marketplace, or other business benefit that either customers or the developing organization wish to gain from the product "reach a sale volume of X units or revenue of $Y within Z months" "increase market share in region X by Y percent within Z months" "receive no more than X service calls per unit and Y warranty calls per unit within Z months after shipping"

names of use cases

form of a verb followed by an object

Identify requirement type: if the pressure exceeds 40 psi, the high-pressure warning light shall come on

functional requirement

Identify requirement type: the system shall allow the user to specify the telescope position given by Right Ascension and Declination or by the stored coordinate of a stellar object

functional requirement

System tests are derived from

functional requirements

use cases develop

functional requirements, testing metrics

Business requirements are from multiple sources:

funding sponsors, corporate executives, marketing managers, product visionaries, ... might conflict! decision makers must resolve (not software team)

user requirements

general statements of user goals or tasks that users need to perform "I need to <do something>" "as the lead machine operator, I need to calibrate the pump controller first thing every morning" "I need to print a mailing label for a package"

Decision tables + trees

governed by (often) complex logic decision table list values for all factors influencing behaviour, indicates expected action to different conditions

Identify the business rule influence type on this business requirement: the Chemical Tracking System must enable compliance with all federal and state chemical usage and disposal reporting regulations within 5 months

government regulations

Change control board (CCB)

group decides which proposed changes and new requirements to accept, accept with revisions, or reject represents all groups that need to participate in making decisions

technique - observations

hard to precisely describe complex tasks and remember details; observe exactly how users perform their tasks time consuming limit to 2 hours each select important or high-risk tasks and multiple user classes can be silent/interactive

During business requirements conflict, RAs can

help surface potential areas fo conflict and differ assumptions flag conflicting business objectives note when requested features don't achieve those objectives facilitate conflict resolution

Entity-relationship diagram (ERD)

high-level view of data entities in a system depict relationship between data entities define logical or physical structure of system database includes: entities, attributes, and relations rectangles: entities (physical items or data groups), named as singular nouns, has multiple attribute values oval: attribute of an entity, data dictionary contains definitions of them diamonds: relationships linking pairs of entities ("doing")

Modifiability

how easily the software designs and code can be understood, changed, and extended can measure: - average time required to add a capacity or fix a problem - % of fixes made correctly

Installability

how easily the system performs the following operations correctly: mean time to install, reinstall, uninstall

Interoperability

how readily system can exchange data and services with other software systems how easily it can integrate with external hardware devices

Decision rules

how they will arrive at decisions - decision leader makes the choice - group votes and majority rules - group votes, but result must be unanimous to approve - group discusses and negotiates to reach consensus

Non-functional requirements (NFR)

how well product will work - quality attributes (quality factors, quality requirements, quality of service requirements) - design and implementation constraints - user interface requirements

Verifiability

how well software components or the integrated product can be evaluated demonstrate whether the system functions as expected

quality attributes

how well the system does describe desirable system characteristics: fast, easy, user-friendly, reliable, secure "the mobile software must respond quickly to touch commands" "the shopping cart mechanism has to be simple to use so my new customers don't abandon the purchase"

Data dictionary pros

identify data validation criteria avoid mistakes that can result when project participants have different understandings of the data help developers write programs correctly minimize integration problems

Event list

identify external events that trigger behaviours in system - business events triggered by users - time-triggered (temporal) events - signal events received from external components complements context diagram and ecosystem map (external entities and systems) as it specifies behaviours triggered by external entities and systems

event-response tables

identify external events to which system must respond great for specifying real-time control systems - system event - system state before event - system response - event frequency - data elements needed to process event - state of system after responses

Project scope

identify what portion of the ultimate product vision that the current project will address (so we are all talking about the same thing for the immediate project) applies to specific release that will implement the next increment of product's functionality

Requirements baseline involves:

identifying the decision makers (select a leader and decision rule) reaching agreement on requirements (customers, developers, testers, managers, ...)

Class diagram composition

if there is a filled-diamond adornment, it's composition - every part belongs to only one whole; if whole is deleted so are parts

Relational data model cons (as requirements model)

implicit typing does not model difference between entities and relations

success metrics (measurable factor) examples

increase market share in country W from X% to Y% within Z months receive no more than X service calls per unit and Y warranty calls per unit within Z months after shipping

document analysis

independent elicitation technique - RA examine existing documentation for software requirements - get up to speed on existing system or new domain - watch for documents being out of date

System interface analysis

independent elicitation technique - examine systems to which system connects - context diagrams + ecosystem maps are starting points - reveal FRs regarding exchange of data + services between systems - identify functionality in other systems that may lead to requirements for the developing system

User interface analysis

independent elicitation technique - study existing systems to discover user + FRs - identify complete list of screens to help discover potential features - learn common steps users take - understand how existing system works - don't assume functionality is needed because of old system

Customers

individual or organization that derives either direct or indirect benefit from a product could request, pay for, select, specify, use, or receive the output generated by a software product subset of stakeholders

Requirement analyst

individuals who have the primary responsibility to elicit, analyze, document, and validate the needs of all the entities involved in requirements engineering business analyst, systems analyst, requirements engineer, requirements manager, application analyst dedicated specialists perform the role; team members who have other roles in project (e.g. project manager)

what type of constraint is this an example of: "mortgage loan applicants must satisfy the Federal Housing Authority qualification standards"

industry standards

What type of business rule is this an example of: "if a payment is not received within 30 calendar days after it is due, then the account is delinquent"

inference

What type of business rule is this an example of: "if the vendor cannot ship an ordered item within 5 days of receiving the order, then the item is considered back-ordered"

inference

Business rules: inferences

inferred knowledge/derived fact, creates a new fact from other facts "if/then" pattern, but "then" provides piece of knowledge (not an action to be taken)

When to use ERD

information modelling simple, easy to use used in many contexts (represent data in a system) express relationships between data flows in different data stores check if relationships are correct identify missing entities or relationships

Request receiver

initially receives newly submitted change requests

use case primary actor

initiates the use case and derives the main value from it

transformation frame properties

input: static output: inert

Identify the quality attribute: "an untrained user shall be able to successfully perform an initial installation of the application in an average of 10 minutes"

installability

Identify the quality attribute: "the installation program shall verify the correctness of the download before beginning the installation process"

installability

Identify the quality attribute: "after performing a file backup, the system shall verify the backup copy against the original and report any discrepancies"

integrity

Identify the quality attribute: "the Chemical Tracking System shall confirm that an encoded chemical structure imported from third-party structure-drawing tools represents a valid chemical structure"

integrity

Identify the quality attribute: "the system shall protect against the unauthorized addition, deletion, or modification of data

integrity

Interface specification

interaction between application domain and system (interface)

Design

internal working of system (solution domain)

Identify the quality attribute: "the Chemical Tracking System shall be able to import and valid chemical structure from the ChemDraw (version 13.0 or earlier) and MarvinSketch (version 5.0 or earlier) tools"

interoperability

Identify the quality attribute: "the Chemical Tracking System shall be able to import any chemical structure encoded using the SMILES notation"

interoperability

Passaround

invite several colleagues to examine deliverable concurrently

Requirements tracing procedure

know concepts + importance of reqt tracing select link relationships choose type of traceability matrix identify portion of product to maintain traceability info for (i.e. high risk parts) identify people who will supply each type of link info and who will coordinate tracing + manage the data modify dev procedures so links are updated define labeling conventions for unique identifiers developer provide requested trace info as small parts get completed audit trace info periodically

Testing activities

late stage activity begin in parallel with corresponding dev activities acceptance tests, system tests, integration tests, unit tests

In value, cost, risk assessment, PM or RA provides:

leads process, arbitrates conflicts, adjusts prioritization

Business and scope document: 2.1 major features

list product's major features or user capabilities, emphasizing those that distinguish it from previous or competing products

features

logically related system capabilities (provides value to user + is described by set of functional requirements) each can encompass multiple user requirements

Modifier

makes changes in work product in response to approved change request

Quality attributes

measurable or testable property of a system that is used to indicate how well the system satisfies the needs of its stakeholders

Efficiency

measure of how well system utilizes processor capacity, disk space, memory, or communication bandwidth

Performance requirement

minimal acceptable performance; speed, delay, capability; non-functional

Behavioural modeling

model abstraction of system behaviour abstraction can be: - functional (function statements, use cases, decision tables) - state-based (finite state machines, state transition diagrams)

Representation modelling

model appearance of system - static representational modelling (often screenshots, simple, effective) - dynamic representational modelling (screens often change with time, animation, story-board, paper-prototype)

Internal model

model decomposes system into sub-domain Process oriented, data oriented, or coombo

External model

model does not decompose system into sub-domain - representation modelling - behavioural modelling

Object Oriented Analysis (OOA)

modelling tool of software requirements; modelling domain objects, not design of new system may view as direct extension of ER model ER has type relationships, inheritance; OO adds: - encapsulation - services (methods) - aggregation relationships Grew from OO-design - OOA -> OOD more seamless - poor fit going SA -> OOD Objects: - reps of individuals/objects in real world

Identify the quality attribute: "a maintenance programmer experienced with the system shall be able to modify existing reports to conform to revised chemical-reporting regulations from the federal government with 10 hours or less of development effort"

modifiability

Identify the quality attribute: "function calls shall not be nested more than 2 levels deep"

modifiability

System specifications

more details for some of the system functionality (may need explaining to stakeholders)

Use case long format

name 1. brief description 2. actors 3. preconditions (option?) 4. basic flow of events 5. alternative flows 6. exceptions 7. post-conditions (option?)

Unambiguous

natural language is prone to two types of ambiguity: writer + reader think of >1 way to interpret requirements, ask people to read it, formal peer review

Data dictionary: hyperlinks

navigation links in a data dictionary useful if it spans many pages or documents

"backward from requirements"

needs are traced to identify origin of each software requirement

Problem frame

new model of problem domain description of a recognizable type of problem domain separates requirements from properties inherent in problem domain depends on type of problem domain

Data elements - primitive element

no further decomposition is possible or necessary eg. quantity, ID

labeling requirements: both

number major sections hierarchically, then identify functional requirements in sections with short text code + sequence number pros: - doesn't solve sequence number problem fully cons: - short labels, more meaningful, less positionally dependent

functional requirements

observable behaviours the system will exhibit under certain conditions and the actions the system will let users take "if the pressure exceeds 40 psi, the warning should come on" "the user must be able to sort the project list in forward and reverse alphabetical order"

Business rules

only certain users can perform an activity under specific conditions derive some functional requirements to enforce the rules "must comply with..." "if <some condition is true> then <thing happens>" "must be calculated according to..." "a new client must pay 30% of the estimated consulting fee and travel expenses in advance" "time off approvals must comply with the company's HR vacation policy"

what type of constraint is this an example of: "a library patron may have a max of 10 items on hold at any time"

organizational policy

what type of constraint is this an example of: "a loan applicant who is <18 yrs old must have a parent or legal guardian as cosigner on the loan"

organizational policy

labelling requirements: hierarchical textual tags

parent requirement as a title, heading, or feature name children requirements deliver capability described in parent pros: - good to label business rules - structured, meaningful, no effect from adding/deleting/moving cons: - long, more thinking - uniqueness tough

Generalization expresses a ____ relationship among related classes

parent/child

Problem domain

part fo universe within which problem exists - area of expertise/application to examine - info defining problem and constraining solution - customer goals - problem context - rules defining functions; user requirements, user stories, use cases

Solution domain/system

part of world within which new solution will operate + produce required effects - architecture + development of software/hardware/network - tools used to achieve solution to set of requirements

Identify the quality attribute: "the anti-lock braking system speed sensors shall report wheel speeds every 2 milliseconds with a variation not to exceed 0.1 millisecond"

performance

Identify the quality attribute: "webpages shall fully download in an average of 3 seconds or less over a 30 MB/s Internet connection"

performance

Identify requirement type: the authorization of an ATM withdrawal request shall take no more than 2.0 seconds

performance requirement

Important quality attributes for desktop and mobile systems

performance, security, usability

Stakeholders

person/group/organization actively involved in the system people directly/indirectly affected by the process or outcome people directly or indirectly influencing system requirements internal or external to the project team and to the developing organization

Preparing for elicitation

plan session scope and agenda prep resources (equipment, participants) learn about stakeholders (cultural, regional preferences) prep questions (phrase to avoid leading customers down unintended path)

Identify the quality attribute: "the user shall be able to port browser bookmarks to and from Firefox, Internet Explorer, Opera, Chrome, and Safari"

portability

safety

prevent injury to people or damage to property gov't regulations/other business rules, legal/certification issues, written in form of conditions or actions system must not allow

Integrity

preventing information loss and preserving correctness of data accuracy and proper formatting

Prioritized

prioritize business requirements according to which are most important to achieving desired value assign implementation priority to each functional requirement, user requirement, use case flow, or feature

Identify the business rule influence type on this user requirement: only laboratory managers are allowed to generate chemical exposure reports for anyone other than themselves

privacy policies

Reliability

probability of software executing without failure for a specific period of time improper inputs, errors in software code itself, components not available when needed, hardware failures measuring: - % operations completed correctly - MTBF - max acceptable probability of failure during given period

Requirements elicitation

process of identifying the needs and constraints of the various stakeholders for a product collaborative + analytical process that includes activities to collect, discover, extract, and define requirements use to discover business, user, data, functional, and nonfunctional requirements, along with other types of info

DFD conventions

processes must communicate through data stores, not directly data cannot flow directly between external entities + data stores data flow must pass through process bubble name each process with "verb plus object" convention don't show >8-10 processes on one diagram

User representatives

provide voice of users involved throughout development life cycle will be actual users that represent the members of a user class RA talks with them instead of guessing the needs of users

Identify the business rule influence type on this quality attribute: the system must maintain safety training records, which it must check to ensure that users are properly trained before they can request a hazardous chemical

quality attribute

Information frame properties

reality: static, autonomous requests: biddable outputs: inert

Organization chart

reduce likelihood that an important class of users is overlooked help judge how many user representatives you need to work with

Example of business benefits

reduce monthly support costs from $X to $Y within Z months

use case pros

relatively easy to write focus on users easy for users to understand engage users useful later for design+testing help with documentation

Problem Domain Oriented Analysis (PDOA)

relatively new less emphasis on modelling, more on description (whereas SA and OOA move away from text) focus on problem domain

Identify the quality attribute: "no more than 5 experimental runs out of 1000 can be lost because of software failures"

reliability

Identify the quality attribute: "the mean time between failures of the card reader component shall be at least 90 days"

reliability

Identify requirement type: the mean time between failures of the card reader component shall be at least 90 days

reliability requirement

Three-level scale pros

relies on analysis of two dimensions of importance + urgency crisper way to think about priorities than MoSCoW is

Dialog maps

represent a UI design at a high level of abstraction show dialog elements in the system and navigation links in flowchart style rectangle: dialog element as a state arrow: navigation option as a transition text label: condition, triggers UI navigation use to verify navigations

Requirements traceability matrix

represent links between requirements and other system elements how each FR is linked backward to a specific use cases and forward to 1+ design, code, and test elements

Swimlane diagram

represent steps involved in business process or operations of proposed software system cross-functional diagrams variation of flowchart what happens inside process bubbles from DFDs rectangles: process steps arrows: transitions between steps diamonds with branches: decisions text on arrows leaving diamond: decision choices vertical lines: swimlanes subdividing process by roles

State transition diagram (STD)

representation of states of an object or system state changes when well-defined criteria are satisfied termination states: have transition arrows coming in, none out; only present if there's a defined life cycle rectangles (circles): possible states arrows: allowed state change/transition text on arrows: events/conditions causing transition

Technique - focus groups

representative group of users to generate input + ideas on a product's functional and quality requirements interactive; allows all users chance to voice thoughts - explore user attitudes, needs, etc. select members carefully be facilitated, keep on topic document session

Business benefits

represents a true value for sponsors and customers e.g. increasing revenue and decreasing costs

Necessary

requirement describes a capability that provides stakeholders with the anticipated business value, differentiates the product in marketplace, or is required for conformance to an external standard, policy, or regulation - every requirement should come from a source - trace functional + NFRs back to specific voice of user input - relate requirements to business objectives

Performance

responsiveness of the system to various user inquiries and actions - response time (# seconds to display webpage) - throughput (transactions processed per second) - data capacity (max # records stored in a database) - dynamic capacity (max # concurrent users of a website) - latency: time delays - behaviour in degraded modes or overloaded conditions (natural disaster -> many emergency calls)

Identify the quality attribute: "at least 30% of the application architecture shall be reused from the approved reference architectures"

reusability

Identify the quality attribute: "the chemical structure input functions shall be reusable at the object code level in other applications"

reusability

Identify the quality attribute: "the pricing algorithms shall be reusable by future store-management applications"

reusability

Reengineered and replacement systems

reuse some requirements from original incarnation, even if never written down

Identify the quality attribute: "all plot description parameters shall have default values specified, which the graphics engine shall use if a parameter's input data is missing or invalid"

robustness

Business rules: action enablers

rule that triggers some activity if specific conditions are true "if <some condition true or event takes place> then <thing happens"

Identify the quality attribute: "the system shall terminate any operation within 1 second if the measured tank pressure exceeds 90% of specified max pressure"

safety

Identify the quality attribute: "the therapeutic radiation machine shall allow irradiation only if the proper filter is in place"

safety

Identify the quality attribute: "user shall be able to see a list of all ingredients in any menu items, with ingredient highlighted that are known to cause allergic reactions in more than 0.5 percent of the North American population"

safety

Identify requirement type: the telescope shall never be pointed closer than 5 degrees from the sun

safety requirement

Identify the quality attribute: "the capacity of the emergency telephone system must be able to be increased from 500 calls per day to 2500 calls per day within 12 hours"

scalability

Identify the quality attribute: "the distribution system shall be able to accommodate up to 20 new warehouse centers"

scalability

Identify the quality attribute: "only users who have auditor access privileges shall be able to view customer transaction histories"

security

Identify the quality attribute: "system shall lock a user's account after four consecutive unsuccessful logon attempts within a period of 5 minutes"

security

Identify the quality attribute: "system shall log all attempts to access secure data by users having insufficient privilege levels"

security

Identify the quality attribute: "users of e-commerce systems want their credit card information to be secure"

security

Identify the quality attribute: "websites should be protected against denial-of-service or hacking attacks"

security

Identify requirement type: the data transmission shall be encrypted to prevent the eavesdropping of an attacker

security requirement

Software product lines

set of products in a family that have a lot of functionality in common

Requirement collection

sets of requirements grouped into a baseline for specific release or iteration should exhibit the characteristics

Requirement prioritization: In or Out

simplest method group of stakeholders work down list of requirements and make binary decision: is it in or out? - refer to business objectives - pare list down to bare minimum for first release - go back to previously "out" requirements - go through process again for next release

Modelling

simplified representation of essential/relevant entities of system and their features

Data attributes

single descriptor for a data object eg. customer: age, gender weight, occupation, ... eg. address: apartment number, street, postal code, ...

Business and scope document: 1.4 success metrics

specify the indicators that stakeholders will use to define + measure success identify the factors that have the greatest impact on achieving that success and measure the success

Business rules: constraints

statement that restricts the actions that the system or its users are allowed to perform "must, must not, may not, only by certain people/roles" types: - schedule/staff/budget limits - product design + implementation constraints - constraints on way business operates: -> organizational policies -> government regulations -> industry standards

Domain types

static (read-only data, eg. CD-ROM-based encyclopaedia) inert (dynamic, only changed by outside agency, eg. files) reactive (self modifying, need external stimulus, eg. abstract data type) programmable (spontaneous, behaviour predictable, eg. software application) biddable (spontaneous, behaviour partially predictable, eg. human users) autonomous (spontaneous, completely independent, beyond control, eg. stock market index or weather) tangible (physical existence, eg. human users, hardware) intangible (no physical existence, eg. software or set of rules or CD-ROM-based encyclopaedia)

Business and scope document: 1.5 vision statement

summarizes the long-term purpose and intent of the product a balanced view that will satisfy the expectations of diverse stakeholders

Connection system

system maintains some correspondence between two unconnected systems eg. video conference system

Workpiece system

system performs operations (directed by user) on objects that only exist within system eg. word processor, spreadsheet, video game

Integration tests are derived from

system's architecture

use cases

tasks users perform with the system user-system interactions bring a valuable outcome for some stakeholders define a sequence of interactions between a system and an external actor the interactions enable the actor to achieve some outcome of value

The set of all requirements form

the basis for subsequent development of the system or system component

Unit tests are derived fromm

the designs

data requirements

the format, data type, allowed values, or default value for a data element; the composition of a complex business data structure; or a report to be generated "the ZIP code has 5 digits, followed by an optional hyphen and four digits that default to 0000" "an order consists of the customer's identity, shipping info, and products each of which includes product number"

Software requirement specification (SRS)

the functions and capabilities that a software system must provide, its characteristics, and the constraints it must respect

Reliability requirement

the probability of the software executing without failure for a specific period of time; also non-functional

Business and scope document: 3.2 project priorities

to determine the priorities to adjust the degrees of freedom to achieve the project's success within the limits imposed by the constraints

Elicitation

to encompass the activities involved with discovering requirements eg. interviews, workshops, document analysis, prototyping, and others - understanding user tasks and goals and the business objectives - identifying the product's expected user classes and other stakeholders - working with individuals (representatives) to understand their functionality needs and their quality expectations - learn about the environment in which the new product will be used

Scope representation

to represent project scope; foster clear + accurate communication among the project stakeholders

Business rule: computations

transform existing data into new data by using specific mathematical formulas or algorithms computations follow rules that are external to the enterprise, i.e. income tax withholding formulas

True/False: each process that appears as a separate bubble on the high-level DFD can be further expanded into a low-level DFD

true

True/False: inheritance is a required feature of object orientation

true

True/False: this is an atomic business rule: "DVD discs and blu-ray discs are video items"

true

True/False: this is an atomic business rule: renewing a checked-out video item extends the due date by three days

true

Requirement development process may not be in a simple linear or one-pass sequence

true activities are interwove, incremental, and iterative

Identify the quality attribute: "95% of chemists who have never used the Chemical Tracking System before shall be able to place a request for a chemical correctly with no more than 15 minutes of orientation"

usability (ease-of-learning)

Identify the quality attribute: "trained user shall be able to submit a request for a chemical from a vendor catalog in an average of 3 minutes, and in a max of 5 minutes, 95% of the time"

usability (measurable)

Quality function deployment

use a technique to ensure a definitive, rigorous way to relate customer value to proposed product features

Use case brief format

use case title + describe in a short paragraph the use case

Identify requirement type: as the lead machine operator, I need to calibrate the pump controller first thing every morning

user requirement

Identify the quality attribute: "a tester shall be able to configure which execution results are logged during testing"

verifiability

Identify the quality attribute: "developer shall be able to set the computational module to show the interim results of any specified algorithm group for debugging purposes"

verifiability

Identify the quality attribute: "the development environment configuration shall be identical to the test configuration environment to avoid irreproducible testing failures"

verifiabiliy


Set pelajaran terkait

Abnormal Psy 3, Abnormal Psychology, Abnormal Psychology 2

View Set

Investment Analysis Midterm Agapova Fall 2019

View Set

MGT 3830 Chapter 1 Gur Test Bank

View Set

Adult Health Tutoring - Fluids & Electrolytes

View Set

SOC 170 Reading Quizzes Part 2: Population Health

View Set

Microsoft Cert Testing Questions

View Set