The previous chapters about requirements: elicitation, analysis.

In use-existing, in varying stages of development: proto, beta, operational release

Opportunity cost--by opting A you can't enjoy the benefits from choosing B and C

constraints on solutions: time, budget

Dependencies on other initiatives-about consideration

Sponsor: usually important decision maker

prioritisation: Must Could Should What

Identify improvement opportunities 

better access to information

identify additional capabilities

Requirement allocation-solution components / release

Determing solution approach-understanding of requirements , solution architecture

Design options: personnel, section, operational structures, policy, rules, relationships, aapplications

Mind mapping

RFI-information, RFQ-quotation, RFT-Tender, RFP-Prposal

Can adopt various formality based on differing needs of the stkhldrs

audit and security-non functional requirements

more than one viewpoints, interrelated with each other-tracing requirements

User stories or use case--functional requirements 

Elicitstion results-business analysis

Assumption 

Alignment with solution scope

Tracing requirements-new requirements, change requirements

Review 
Walkthrough-predictive-group

single issue review

ad hoc-temporary 

Atomic

Verify-quality check

Use case

Main success flow

Alternative and exception flow

1 sprint (1-4wks)

Synchronous 

asynchronous _signal

Metadata repository

Primitive data elements

Composite data elements

business policy, directive, broadly

business rule specific, testable directive

Definition rules (can only be misapplied)

Behavioral rules (can be violated)

override by authorised actor, with explanation, with no active enforcement

Business Rules Catalogue

Model

Mactrices

Diagram

People & roles

Rationale (scope model, root cause analysis)

Activity flow (use case, user stores, processes)

Capability (functions)

Data & information (Data dictionary, Glossary, interface)

attributes: prioritisation, value, source

Notations (UML, informal)

Requirements architecture:

use case or documentation-depending on requirements of stkhldrs

Verify (quality like typo, grammatical inconsistency, text elusive) & validate(value) could be done simultaneously

Chnage strategy

Business case

Business case

Cost & benefit

Need assess

Desired outcome

Assesss alternatives

Recommend solution

Decision analysis ( modeling)

Decision matrices

Decision node, chance node, terminator 

Also depending on other factors 

Trade-offs:

assign weights based on relative importance 

Functional decomposition   

WBS=Work Breakdown Structure   

Level: just enough     

Simplify measure and estimate   

Scope Model

In, out, both

Context diagram (Data Flow Diagram)

Reflects out of scope

Use case diagram

UML-defined

SMART=specific, measurable, achievable, relevant, time-bound

Tco=total cost of ownership

roi=return on investment

trade-off

Against source info

Against other-multiple elicitation

Any stkhldr