423 Soft Req
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